-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 5.0.0, 6.0.0, 7.0.0, 7.3.0
-
Component/s: None
-
Query Execution
-
Fully Compatible
-
ALL
-
v7.3, v7.0, v6.0, v5.0
-
-
QE 2024-03-18, QE 2024-04-01, Repl 2024-02-19
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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
-