-
Type: New Feature
-
Resolution: Unresolved
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
1,323
-
(copied to CRM)
From TOOLS-2041:
I think the use case of doing an --oplogReplay into a pre-existing collection is fairly dubious. The point of --oplogReplay is to provide a point-in-time restore. If there's pre-existing data, you cannot guarantee the state after the restore is consistent. You would have a mix of documents from different times. This is a problem even if there aren't any duplicate key errors.
If we were to ignore duplicate key errors during oplog application and skip those ops, it would get even worse - it would be possible to have documents which aren't even internally consistent. Different fields will be from different times.
So I think it's correct that duplicate key errors during --oplogReplay do cause mongomirror to fail. If you want to restore into a pre-existing collection, it's best not to use --oplogReplay. In fact, I think in a future major version update we should consider disallowing the use of --oplogReplay without --drop.
- related to
-
TOOLS-2041 Mongorestore should handle duplicate key errors during oplog replay
- Closed