[SERVER-33602] Ensure that stable replication recovery begins at the timestamp of the stable checkpoint Created: 01/Mar/18  Updated: 27/Oct/23  Resolved: 22/Mar/18

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

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Gone away Votes: 0
Labels: rollback-optional
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

Right now the stable checkpoint can reflect data at a timestamp after the checkpointTimestamp/lastStableCheckpointTimestamp. This means we must relax idempotency constraints at startup and have no idea what time the data actually reflects. It also means that we cannot set the initial data timestamp until replication recovery ends which limits the time where snapshot reads can occur and makes replication recovery a slightly longer process. We should make sure that whichever mechanism we use to keep track of the stable timestamp at startup is correct.

Before 4.0 is released, we should ensure that whichever method we use, if not correct, has a path to correctness here to limit upgrade downgrade concerns in the future.



 Comments   
Comment by Spencer Brody (Inactive) [ 22/Mar/18 ]

This was fixed by other changes to WT

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