MongoDB | 2572498

Info

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.

Top User Comments

Steps to Reproduce

launch a 3-node replica set. On the primary: > use test > db.coll.insertOne({_id: 1}) > db.runCommand({update: "coll", bypassDocumentValidation: true, ordered: true, stmtIds: [ 0 ], updates: [ { q: { _id: 1 }, u: [ { $_internalApplyOplogUpdate: { oplogUpdate: { $v: 1, $set: { foo: Timestamp(0, 0) } } } } ], multi: false, upsert: false, collation: { locale: "simple" } } ]}) > db.coll.findOne() The result is  { _id: 1, foo: Timestamp(\{ t: 0, i: 0 } ) } on the primary. On any secondary: > use test > db.getMongo().setReadPref('secondary') > db.coll.findOne() The result is something like { _id: 1, foo: Timestamp(\{ t: 1707506908, i: 2 } ) } on the secondary. The actual timestamp will be the current time.