[SERVER-24223] Add hash to minvalid OpTime boundaries Created: 19/May/16  Updated: 06/Dec/22  Resolved: 06/Jan/20

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

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: PM617
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-25756 Replication should ensure that minVal... Closed
is related to SERVER-7200 use oplog as op buffer on secondaries Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

In the case there is a rollback after/during a failed apply batch it is possible to fetch new oplog entries with matching OpTimes but different hashes when recovering and applying the batch again – although very unlikely...

Oplog-as-a-buffer will address this since we will always have the oplog entries locally.



 Comments   
Comment by Judah Schvimer [ 06/Jan/20 ]

Went away with PV0 being removed.

Comment by Mathias Stearn [ 01/Dec/16 ]

This work will also need to pass the hash along with the opTime to the SyncSourceResolver to ensure it doesn't pick a host on the wrong branch of history in PV0 (already not possible in PV1).

Comment by Mathias Stearn [ 23/Aug/16 ]

Linking to SERVER-25756 as a separate ticket since the hash isn't actually needed in PV1. Note that oplog-as-buffer only addresses this at steady state, we'd need other mechanisms to fix this for other setters of minValid such as initial sync and rollback.

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