[SERVER-55746] Validate inserts into the oplog of a standalone for stale timestamps Created: 02/Apr/21 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
It can be convenient to allow MDB nodes to allow inserts into the oplog (and is even necessary for some current restore procedures). But oplog entries being inserted with a bad (stale) timestamp trip this fassert. The fassert is important for correctness of the typical writes replication performs against the oplog (that are still on behalf of a user operation). But there is hopefully a path for validating these timestamps. Perhaps a strict validation that an oplog entry's ts field is larger than the current top of oplog? With an exception for an explicit `ts: Timestamp(0, 0)` as I expect the server to be choosing TopOfOplog + 1. |
| Comments |
| Comment by Daniel Gottlieb (Inactive) [ 02/Apr/21 ] |
|
I put this on storage as its their fassert, but I could just as easily see this being for replication to do. |