Problem
mongosync is running into a data consistency error in our internal testing when $_internalApplyOplogUpdate is used with $set: { foo: Timestamp(0, 0) }. The primary will set foo to Timestamp(0, 0). But secondaries will set foo to the current timestamp.
Although $_internalApplyOplogUpdate is for internal use only and will likely not affect external users, mongosync may corrupt user data if $_internalApplyOplogUpdate is not replicated correctly.
Solution & Acceptance Criteria
- Fix the replication bug.
- Figure out if this bug affects regular update command.
- Figure out if this bug only affects Timestamp(0, 0)
Impact
mongosync will not corrupt user data.
Optional Permalinks
REP-4005 is where this bug was first discovered.
- is depended on by
-
SERVER-88750 Add "bypassEmptyTsReplacement" param to insert, update, findAndModify, and bulkWrite
- Closed
- is related to
-
SERVER-76926 Unify insert and {upsert: true} insert behavior for $setOnInsert: Timestamp(0,0)
- Closed
- related to
-
SERVER-89034 Always preserve 0-valued timestamps when migrating documents, add tests
- Closed