-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 5.0.0, 4.4.7
-
Component/s: None
-
None
-
Storage Execution
-
ALL
-
Execution Team 2023-11-13, Execution Team 2023-11-27
-
(copied to CRM)
When using startupRecoveryForRestore we advance the oldest timestamp during startup oplog recovery, as described in SERVER-55766. This causes the drop-pending ident reaper to run, dropping the tables for any collection/index drops that were applied during the recovery. However, those writes may not have been checkpointed yet. Thus if a crash occurs before a subsequent checkpoint, we may end up in a state where the catalog references a table which no longer exists in the storage engine.
- duplicates
-
SERVER-80974 Unclean shutdown while dropping local.* collection and indexes can make the catalog inconsistent
- Closed
- is caused by
-
SERVER-55766 Introduce an optimized "for restore" startup replication recovery mechanism
- Closed
- related to
-
SERVER-79245 Unclean shutdown while dropping collection and indexes to resync can make the catalog inconsistent
- Closed
-
SERVER-81878 startupRecoveryForRestore may not play nicely with collection drop applied during startup recovery
- Closed