[SERVER-29212] Ensure WiredTiger checkpoints are created at valid timestamps Created: 15/May/17  Updated: 30/Oct/23  Resolved: 03/Aug/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.5.11

Type: Improvement Priority: Major - P3
Reporter: Alexander Gorrod Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-29892 Roll Back to Checkpoint: Make IDL fil... Closed
depends on SERVER-30310 Have WiredTigerKVEngine implement Sto... Closed
depends on SERVER-29210 Create a thread in MongoDB to manage ... Closed
depends on WT-3387 Add support for a stable timestamp Closed
is depended on by SERVER-29901 Roll Back to Checkpoint: Create an ev... Closed
is depended on by SERVER-29211 Change to explicitly journal a subset... Closed
is depended on by SERVER-29494 WT validate should wait for explicit ... Closed
Related
is related to SERVER-29900 Roll Back to Checkpoint: Control when... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-06-19, Storage 2017-07-10, Storage 2017-07-31, Storage 2017-08-21
Participants:

 Description   

Once MongoDB timestamps are available to a single node there are cases where MongoDB will need to more carefully control which timestamp a checkpoint is created from. There are two cosntraints:

1) A checkpoint should not be created later than the common durable point across all nodes in a replica set.
2) On a secondary a checkpoint should not be created in the middle of a batch of oplog entries being applied.

Common durable point

This is a requirement because it is possible for it to be necessary to recover a node to the oldest durable point after a replication election. If a checkpoint has been taken that is newer than that point in time, it's no longer possible to recover to the necessary earlier point in time.

Secondary batch boundary

MongoDB optimizes applying the operations from the oplog, by sharing them amongst threads. There are certain ordering constraints that need to be adhered to so MongoDB can guarantee identical data is present on each node. This is handled by grouping the operations together into batches, and splitting the works amongst threads with care to ensure the ordering constraints are adhered to. There are some corner cases where a constraint may be temporarily violated during batch apply once global timestamps are being used. Guaranteeing that collection data isn't flushed avoids the constraint violation.



 Comments   
Comment by Githook User [ 10/Aug/17 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-29212: Stage changes for taking stable checkpoints.
Branch: master
https://github.com/mongodb/mongo/commit/64313d4e689558b501bf924f2b2b3040269b285f

Generated at Thu Feb 08 04:20:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.