[SERVER-20466] Rollback and batch apply can each set minvalid independantly Created: 17/Sep/15  Updated: 08/Jan/16  Resolved: 08/Jan/16

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

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

Issue Links:
Duplicate
duplicates SERVER-21988 Rollback does not wait for applier to... Closed
Related
related to SERVER-20326 Record "apply" batch boundaries durin... Closed
Operating System: ALL
Participants:

 Description   

Due to the way sync_tail and bgsync interact while applying and fetching documents it is possible both, during a rollback, write to the minvalid collection with different values.

Since rollback will transition to a non-readable state, like rollback and the applier stops it should be safe but more investigation should be taken.

And we should probably disallow this race all together, by ensuring the batch completes before we enter rollback.



 Comments   
Comment by Scott Hernandez (Inactive) [ 08/Jan/16 ]

The comment from Eric was fixed with SERVER-20326 changes where we take the max(oldMinvalid, newBatchEnd) so minvalid is not met until we pass the old boundary.

Comment by Scott Hernandez (Inactive) [ 08/Jan/16 ]

Fixed with changes in SERVER-21988, which no longer allow these things to happen at the same time.

Comment by Eric Milkie [ 17/Sep/15 ]

This is a bug even if rollback is not involved. Say you are in the middle of a batch and crash. Minvalid is left set at a certain value. The node is restarted, and the first batch is smaller than the batch when the node crashed. After this first batch is applied, minvalid gets set to a value lower than the previous value.
Instead, we should not be setting minValid to a value lower than its current value, unless we are doing a wipe and resync, or are rolling back.

Generated at Thu Feb 08 03:54:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.