-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.6.0
-
Component/s: Replication
-
None
-
Fully Compatible
-
Repl 2018-01-15
The first phase of dropDatabase (for replicate sets) in 3.6 is to individually drop each collection (drop in this first phase is a misnomer for rename). When those "drops" are majority confirmed, the primary replicates a dropDatabase oplog entry.
However the loop uses an iterator over the _collections map and db->dropCollectionEvenIfSystem will perform a rename. This rename erases the entry followed by adding it back under a different name. The expectation of the for-each collection loop is that all collections will be observed. The erase/add of the underlying map breaks that requirement.
This can result in some collections not being dropped on the primary nor the secondary in the first part of dropping a database. I do believe the second phase of dropping a database that's associated with the dropDatabase oplog entry will be renamed and/or dropped on both the primary and secondary.
One possible fix is to copy the values from the map to iterate over instead.
- is related to
-
SERVER-29277 Two Phase Drops: implement dropDatabase changes to support 2-phase drops
- Closed
-
SERVER-32534 Have UnorderedFastKeyTable iterators error if the table had been modified.
- Closed
- related to
-
SERVER-32251 dropCollection/dropDatabase must be timestamped
- Closed