-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
ALL
This is an extension to SERVER-3562. That fix caused the 'movePrimary' command to not move any collection data for sharded collections. Because 'movePrimary' (or 'clone') does not take out a write lock, it is possible for users to try to write to that collection while the clone is in-flight. If they do so before the metadata is updated, the writes can be lost.
The long-term fix would be to lock all of the collections being moved by 'clone'. As a short-term fix, I'd suggest having 'movePrimary' return a warning if it detects any unsharded collections in the database being moved.
- related to
-
SERVER-8870 mongos unaware of database move after movePrimary
- Closed