[SERVER-41388] Truncate the oplog after the stable timestamp on startup if the oplogTruncateAfterPoint is earlier in time than the stable timestamp Created: 30/May/19 Updated: 29/Oct/23 Resolved: 21/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Execution Team 2019-06-17, Execution Team 2019-07-01 | ||||||||
| Participants: | |||||||||
| Description |
|
On startup, the checkpoint (stable) timestamp can be compared with the oplogTruncateAfterPoint value. If the oplogTruncateAfterPoint is behind the checkpoint timestamp, we will instead truncate after the checkpoint timestamp. We will start moving the oplogTruncateAfterPoint forward regardless of durability in the Replicate Before Journaling project. Primaries will be constantly updating the value. It is possible for the update thread to be slow for some reason, and the stable timestamp to jump forward in the meantime. Before the changes for the Replicate Before Journaling project, the oplogTruncateAfterPoint was quickly set and unset in a window such that stable timestamp could not move forward while it was set. Secondaries set and unset it during batch application. Rollback sets and unsets it to trim the oplog. Initial sync clears it upon finishing (when it unsets the initial sync flag). |
| Comments |
| Comment by Githook User [ 21/Jun/19 ] |
|
Author: {'name': 'Dianna Hohensee', 'username': 'DiannaHohensee', 'email': 'dianna.hohensee@10gen.com'}Message: |