-
Type: New Feature
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
Mongodb replication applies writes in batches with a process that looks something like the following to go from timepoint A to B:
- Block out all readers
- Commit a write that indicates that we are invalid and that we must reach B before becoming valid
- Divide the writes in the batch to many threads. Each thread does its writes in arbitrary order in multiple WT commits.
- Commit a write that marks the data as valid
- Unblock readers
One downside to this approach is that if a server is killed at a random time, the probability of the wt log replaying to a point that is invalid is high on a system with a high throughput of writes. This is made worse by SERVER-24223.
It would be helpful if we could indicate to WT somehow when we are in a valid state, such that on startup, following log-replay we would always be valid. One (suboptimal) solution would be to create a named checkpoint with a fixed name at each valid point and roll back to that snapshot on startup.
- duplicates
-
SERVER-29211 Change to explicitly journal a subset of content in WiredTiger
- Closed
- is related to
-
SERVER-20328 Allow secondary reads while applying oplog entries
- Closed
-
SERVER-25071 Ensure replication batch finishes before shutdown
- Closed