[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: |
|
||||||||||||||||
| 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 |
| Comment by Scott Hernandez (Inactive) [ 08/Jan/16 ] |
|
Fixed with changes in |
| 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. |