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).
- is related to
-
SERVER-48934 Investigate replica set data mismatch from Jepsen testing
- Closed