Issue Summary

The team discussed whether WiredTiger can adopt checkpoints on secondaries without requiring oplog application to be ahead of the checkpoint being installed. Today, oplog application is effectively treated as a prerequisite for checkpoint adoption and for maintaining ingest-table correctness, but the thread suggests this may be an implementation restriction rather than a fundamental requirement.

The specific question is whether a secondary could:

• skip intermediate checkpoints when jumping ahead (e.g. install C then F without needing D/E), and
• adopt checkpoints even if oplog application has not advanced to that point, especially for read-only secondaries that do not write to ingest tables.

Context

Current behavior and concerns raised in the thread:

• Peter noted that skipping checkpoints should be supported as long as oplog application is still ahead of the checkpoint being adopted.
• Wenbin asked whether the oplog requirement itself could be lifted, which would enable:
  • read replicas that do not need to tail oplog continuously,
  • standby nodes that can move between checkpoints even when oplog application lags.
• Ivan explained that the current layered-cursor logic depends on ingest-table entries taking precedence over stable-table content because ingest data is assumed to be at least as new as stable content.
• Ivan also pointed out that pruning ingest tables safely while cursors may still be positioned on them is non-trivial, because the system currently lacks logic to reposition cursors from ingest to stable content.
• Nic clarified that the special case of interest is a read-only secondary that never writes to ingest and only jumps from checkpoint to checkpoint.
• Ivan agreed that this narrower case is potentially much simpler and may even work with the current logic if the system never has ingest data and only moves from one stable checkpoint to another.

Proposed Solution

Investigate and define support for a special mode for read-only secondaries that:

• disallows writing to ingest tables,
• allows adopting checkpoints directly from stable checkpoint to stable checkpoint,
• does not require oplog application to be ahead as a correctness condition in this mode.

If this narrower mode proves viable, it could serve as a stepping stone toward a broader design that relaxes the oplog-ahead restriction for checkpoint adoption in more general scenarios.

Notes from Discussion

• The main blocker for the general case appears to be ingest/stable merge semantics in layered cursors.
• A full solution may require new logic for ingest-table pruning and cursor repositioning.
• The read-only-secondary special case may avoid those complexities entirely.
• Ivan requested that a WT ticket be raised when ready.

Original Slack thread: https://mongodb.slack.com/archives/C08143UMQP4/p1793311733384079
This ticket was generated by AI from a Slack thread.