-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
TAR 2023-05-29
-
1
-
0.5
-
Not Needed
Problem Statement/Rationale
I've a 3 node replica set having data of approx. 1TB.
Database on this replica set is having lots of transactions means more oplogs.
Now I've requirement to restore this database to a new 3 node replica set with minimal or no downtime with data being intact after the restore.
I'm following this process to restore and resume the application with minimal downtime.
- take a full backup of the original mongodb instance.
- restore to new mongodb instance.
- consider the restore may take approx. 24 hours.
- Now I will take oplog backup ( inc backup ) from last oplog entry of restored mongodb instance to last oplog entry of original mongodb instance.
- I want to restore this diff/incremental oplog to new mongodb instance.
I tried these however I unable to perform oplog replay.
Steps to Reproduce
How could an engineer replicate the issue you're reporting?
oplog/inc backup
mongodump -u username -p password --host=server1 --port=8303 -d local -c oplog.rs --oplog --authenticationDatabase=admin --ssl --query '{"ts": {"$gt": {"$timestamp": {"t": 1683598975, "i": 0}}' --out /tmp}}
This backup results in following 2 files :
- oplog.rs.bson
- oplog.rs.metadata.json
I'm unable to restore from either of the files and tried to rename oplog.rs.bson to oplog.bson and tried to restore but getting below error:
mongorestore -u user -p password --host=server2 --port=8470 --authenticationDatabase=admin --ssl --oplogReplay /tmp/local/ -vvvv
2023-05-09T11:29:40.885+0000 using write concern: &{majority false 0}
2023-05-09T11:29:40.926+0000 checking options
2023-05-09T11:29:40.926+0000 dumping with object check disabled
2023-05-09T11:29:40.926+0000 will listen for SIGTERM, SIGINT, and SIGKILL
2023-05-09T11:29:40.926+0000 connected to node type: replset
2023-05-09T11:29:40.927+0000 mongorestore target is a directory, not a file
2023-05-09T11:29:40.927+0000 preparing collections to restore from
2023-05-09T11:29:40.927+0000 using /tmp/local as dump root directory
2023-05-09T11:29:40.927+0000 found oplog.bson file to replay
2023-05-09T11:29:40.927+0000 enqueued collection '.oplog'
2023-05-09T11:29:40.927+0000 finalizing intent manager with longest task first prioritizer
2023-05-09T11:29:40.927+0000 restoring up to 4 collections in parallel
2023-05-09T11:29:40.927+0000 starting restore routine with id=3
2023-05-09T11:29:40.927+0000 ending restore routine with id=3, no more work to do
2023-05-09T11:29:40.928+0000 starting restore routine with id=2
2023-05-09T11:29:40.928+0000 ending restore routine with id=2, no more work to do
2023-05-09T11:29:40.928+0000 starting restore routine with id=1
2023-05-09T11:29:40.928+0000 ending restore routine with id=1, no more work to do
2023-05-09T11:29:40.928+0000 starting restore routine with id=0
2023-05-09T11:29:40.928+0000 ending restore routine with id=0, no more work to do
2023-05-09T11:29:40.928+0000 replaying oplog
2023-05-09T11:29:40.928+0000 skipping applying the config.system.sessions namespace in applyOps
2023-05-09T11:29:40.928+0000 skipping applying the config.system.sessions namespace in applyOps
2023-05-09T11:29:40.936+0000 skipping applying the config.system.sessions namespace in applyOps
2023-05-09T11:29:40.936+0000 skipping applying the config.system.sessions namespace in applyOps
2023-05-09T11:29:40.936+0000 skipping applying the config.system.sessions namespace in applyOps
2023-05-09T11:29:41.781+0000 Failed: restore error: error applying oplog: applyOps: (DuplicateKey) E11000 duplicate key error collection: admin.system.users index: user_1_db_1 dup key: { user: null, db: null }
2023-05-09T11:29:41.781+0000 0 document(s) restored successfully. 0 document(s) failed to restore.
Expected Results
What do you expect to happen?
Actual Results
What do you observe is happening?
Additional Notes
Any additional information that may be useful to include.