-
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
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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
-