createCollectionForApplyOps runs on secondaries and has functionality to temporarily rename a collection out of the way into a tmp collection, with the expectation that it will be renamed back again. This is for oplog replay when this scenario happens:
1) createCollection(foo.bar) w/ UUID 1
2) renameCollection(foo.bar to foo.baz) still w/ UUID 1
3) createCollection(foo.bar) w/ UUID 2
createCollectionForApplyOps will rename foo.bar w/ UUID 2 out of the way into a tmp collection when it sees 1) and create foo.bar w/ UUID 1, with the expectation that it will eventually see 3) and rename the tmp collection back.
However, this code can leak bugs. When secondaries somehow have a collection that the primary doesn't, and the primary then creates the collection and the secondaries rename their original collection out of the way, orphaning it.
- is related to
-
SERVER-21700 Do not relax constraints during steady state replication
- Closed
-
SERVER-49930 Log collection name in createCollectionForApplyOps() invariant that collections are not renamed out of the way in steady state replication
- Closed
- related to
-
SERVER-33714 Downgrading FCV from 3.6 to 3.4 leaves an admin.system.keys collection on shards that on upgrade is orphaned and renamed without a UUID
- Closed