-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Replication
-
ALL
-
-
0
If a collection on a primary is in "drop-pending" state, by executing a create collection command via the applyOps command using the original UUID of that collection it is possible to erroneously "roll back" that collection i.e. remove it from the "drop-pending" state, and make it a normal collection again. Presumably, the correct thing to do would be to disallow collection creation operations via applyOps on collection UUIDs that are currently in drop-pending state.
This issue can lead to a db hash mismatch between a primary and secondary, since the drop-pending "roll back" gets logged in the oplog as a renameCollection operation. When a secondary applies the initial collection drop (the drop prepare), it might physically drop the collection before it applies the later renameCollection operation from the primary. If it tries to then apply the renameCollection operation on a collection that has been physically dropped, it will presumably fail silently, leaving it permanently missing a collection that the primary still has. See repro script.
- duplicates
-
SERVER-32098 Disallow operations on drop-pending collections through applyOps
- Closed