I understand that the recommended way to backup MongoDB data is to use file system level tools. However, mongodump utility is promoted as a valid alternative for smaller instances, when file system snapshots are not available for some reason. Many resources recommend running it with --oplog option to enable point-in-time restores.
I tried to understand how --oplog could enable point-in-time snapshots without proper multi-version concurrency control from the database engine. I think it can only work in the following way:
- We assume that _id values in all collections are monotonously increasing
- Mongodump blocks all writes and records last operation id in the oplog
- Mongodump starts dumping documents from all collections by navigating _id index in decreasing order
- After dump has started, mongodump unlocks writes to the collections
- We assume that all inserts from now on will have higher _id values and will appear only in oplog dump, not collections dump.
This system quickly breaks if _id values are not monotonously increasing or if write locks are not implemented and there is a race condition. Also, there is no support for secondary unique indexes.
From what I see, the following statements are true, meaning that mongodump cannot possibly enable point-in-time restores, so it's specification is misleading as it comes to its snapshot-like capabilities:
- Even build-in _id values generators do not guarantee total order
- mongodump does not issue any write locks
- mongodump does not traverse _id index in descending order, so inserted records will appear both in collection dump and oplog dump.
Is my understanding correct? Is there any value in --oplog option of mongodump utility?
Following are the tickets which seem to enforce my suggestions: