[SERVER-34350] Properly initialize initial data timestamp Created: 06/Apr/18  Updated: 12/Apr/18  Resolved: 12/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-34279 Crash after upgrade before stable che... Closed
Operating System: ALL
Sprint: Repl 2018-04-09, Repl 2018-04-23
Participants:

 Description   

When replication startup determines the data is consistent with the top of oplog, replication must also set the initial data timestamp to the top of oplog.

Ideally speaking, an initial data timestamp of T implies:

  1. A snapshot at time T on this node is consistent with all other primary/secondary members of a replica set.
  2. Storage must not assume a snapshot at T-1 is consistent with any other replica set member.

However in practice, collection drops effectively "change the past". Until SERVER-34069 is done (optimistically assuming that fix is complete), a node must still play from T -> top of oplog before it has a consistent snapshot (at the "top of oplog" time) w.r.t other replica set members. The only relaxation of the the ideal properties is that the time between T and the prepare of the two-phase drop should contain data from the dropped collection, but that history was lost. The ideal property is only in violation on an unclean shutdown. This relaxation is only material for replication startup recovery.


Generated at Thu Feb 08 04:36:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.