-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
ALL
If after the end of the clone phase, we have on the syncing node
collection_a: UUID_1
collection_b: UUID_2
collection_c: UUID_3
and we replay a renameCollection opcode renaming UUID_1 to collection_b with dropTarget: UUID_3, we will correctly rename UUID_2 to a temporary name, but also incorrectly drop UUID_3. When we then go to create UUID_3 in a later oplog entry, it may be in drop_pending state and refuse to be re-created.
- duplicates
-
SERVER-33956 A sequence of rename and create collections that do not arrive at the correct end state
- Closed
- is related to
-
SERVER-33087 Fix the use of dropTarget in renameCollection
- Closed