-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Admin, Replication
-
None
-
ALL
-
Repl 2019-08-26
-
15
This mode/command will need to support situations where unique indexes restraints must be loosened like during initial-sync/recovery mode.
Depending on the state of the data, and the contents of the oplog, in a backup taken with "mongodump --oplog", attempting to restore the data may cause temporary unique-index violations. The violations will be resolved by the time "mongorestore" has replayed the dumped oplog, but it's currently impossible to do the mongorestore because the unique-index violations will abort the restore.
We need a way to suspend unique-index constraints while restoring a dump with an oplog, then re-enable the constraints at the end of the restore. There should be a rigorous strategy in place for dealing with unique-index violations that remain at the end of the restore.
- is depended on by
-
TOOLS-176 Dump/Restore with --oplog not point-in-time
- Closed
- is duplicated by
-
SERVER-10773 Provide mechanism for cloud to reliably replay an oplog into a secondary, including restart
- Closed
- is related to
-
TOOLS-852 mongorestore --noDataRestore
- Accepted
-
SERVER-19618 Allow applyOps to ignore unique index constraints
- Closed
-
TOOLS-2345 Does oplogApplicationMode 'initialSync' address duplicate key issues?
- Closed