-
Type: Bug
-
Resolution: Done
-
Priority: Critical - P2
-
Affects Version/s: 3.1.2
-
Component/s: Replication
-
None
-
Minor Change
-
ALL
-
-
Repl D (12/11/15)
-
0
This bug affects versions 3.1.2+ with WiredTiger as the storage engine. It doesn't affect 3.0.7.
Here's the test output from the repro script:
// The primary and secondary are synchronized up until this point. // A no-op update is issued, but an op is still logged in the oplog. // This leads to the secondary getting out of sync with the primary // (and is a form of data loss). > res = primaryColl.update({}, {$pushAll: {a: []}}); > assert.writeOK(res); res => { "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 } oplog [ { "ts" : Timestamp(1449024242, 1), "h" : NumberLong("-3274359779073625624"), "v" : 2, "op" : "n", "ns" : "", "o" : { "msg" : "initiating set" } }, { "ts" : Timestamp(1449024254, 1), "t" : NumberLong(1), "h" : NumberLong("-7260876401968846914"), "v" : 2, "op" : "n", "ns" : "", "o" : { "msg" : "new primary" } }, { "ts" : Timestamp(1449024254, 2), "t" : NumberLong(1), "h" : NumberLong("9051320871864503306"), "v" : 2, "op" : "c", "ns" : "test.$cmd", "o" : { "create" : "foo" } }, { "ts" : Timestamp(1449024254, 3), "t" : NumberLong(1), "h" : NumberLong("-455571380945262558"), "v" : 2, "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("565e5afe7750e3087f8ef04f"), "a" : [ 1 ] } }, { "ts" : Timestamp(1449024254, 4), "t" : NumberLong(1), "h" : NumberLong("-4618385206475519820"), "v" : 2, "op" : "u", "ns" : "test.foo", "o2" : { "_id" : ObjectId("565e5afe7750e3087f8ef04f") }, "o" : { } } ] Primary doc [ { "_id" : ObjectId("565e5afe7750e3087f8ef04f"), "a" : [ 1 ] } ] Secondary doc [ { "_id" : ObjectId("565e5afe7750e3087f8ef04f") } ]
- is related to
-
SERVER-21738 Definitively detect no-op updates
- Backlog