-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Execution
-
Storage Execution 2026-04-13, Storage Execution 2026-04-27, Storage Execution 2026-05-11, Storage Execution 2026-05-25
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Once validation of metadata and graceful stepdown have been implemented, the following sequence of events becomes invalid:
- Node is primary.
- Concurrent conflicting createCollection calls happen, resulting in one of them creating a table and then rolling back. Table is added to the reaper.
- Reaper gets EBUSY when it tries to drop the table.
- Node steps down.
- Node installs a checkpoint from the new primary
Here the validation will fail because the node has a table that it shouldn't, so we need to either disable validation or skip installing the checkpoint.
In normal operation this should skip at most one checkpoint before all tables are cleaned up, but we've had bugs that result in forever getting EBUSY before. To avoid having a standby that never installs checkpoints, we should put a limit on how many are skipped and fassert if it exceeded.
- is related to
-
WT-18405 Do not drop a table on the follower with uncheckpointed data
-
- Open
-
-
SERVER-134216 Adjust step_up_create_drop_since_installed_checkpoint.js for the follower table-drop contract
-
- Closed
-
-
WT-18029 Validate local vs shared metadata equivalence on checkpoint pickup (strict_checkpoint_metadata)
-
- Closed
-
- related to
-
SERVER-134217 Gate the follower's replicated dropIdent on an installed checkpoint covering the drop
-
- Closed
-