[SERVER-21608] debug builds should track oplog ts discontinuities Created: 21/Nov/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
When readers see discontinuities in the oplog, they should check that they are valid (due to a change in the second field, rollbacks, etc.) and treat it as a fatal error when it isn't. This will help us catch bugs in oplog visibility rules. |
| Comments |
| Comment by Mathias Stearn [ 21/Nov/15 ] |
|
The storage engine knows when each optime is allocated, and when they are rolled back. It can keep track of cases where there are gaps. |
| Comment by Andy Schwerin [ 21/Nov/15 ] |
|
redbeard0531, how would you propose to track holes in the oplog generated by operations that fail to commit (storage engine rollback)? |
| Comment by Eric Milkie [ 21/Nov/15 ] |
|
How would an external reader know when there was a transaction rollback? |