Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Cannot Reproduce
-
3.4.2
-
None
-
ALL
Description
Replica set with 2 nodes and an arbiter with one node down
When performing a w:"majority" write that would otherwise fail with Duplicate Key Exception, I expect it to fail with Write Concern Timeout exception after the timeout has expired. However, it still produces the dup key exception after the wait:
replset:PRIMARY> db.test.insertOne({_id:1})
|
{ "acknowledged" : true, "insertedId" : 1 }
|
replset:PRIMARY> db.test.insertOne({_id:1},{writeConcern:{w:"majority",wtimeout:5000}})
|
...
|
WAIT
|
...
|
2017-04-26T18:09:57.685-0400 E QUERY [thread1] WriteError: E11000 duplicate key error collection: test.test index: _id_ dup key: { : 1.0 } :
|
WriteError({
|
"index" : 0,
|
"code" : 11000,
|
"errmsg" : "E11000 duplicate key error collection: test.test index: _id_ dup key: { : 1.0 }",
|
"op" : {
|
"_id" : 1
|
}
|
})
|
WriteError@src/mongo/shell/bulk_api.js:469:48
|
Bulk/mergeBatchResults@src/mongo/shell/bulk_api.js:836:49
|
Bulk/executeBatch@src/mongo/shell/bulk_api.js:906:13
|
Bulk/this.execute@src/mongo/shell/bulk_api.js:1150:21
|
DBCollection.prototype.insertOne@src/mongo/shell/crud_api.js:242:9
|
@(shell):1:1
|
replset:PRIMARY> rs.status()
|
{
|
"set" : "replset",
|
"date" : ISODate("2017-04-26T22:10:05.449Z"),
|
"myState" : 1,
|
"term" : NumberLong(3),
|
"heartbeatIntervalMillis" : NumberLong(2000),
|
"optimes" : {
|
"lastCommittedOpTime" : {
|
"ts" : Timestamp(1493242117, 1),
|
"t" : NumberLong(1)
|
},
|
"appliedOpTime" : {
|
"ts" : Timestamp(1493244598, 1),
|
"t" : NumberLong(3)
|
},
|
"durableOpTime" : {
|
"ts" : Timestamp(1493244598, 1),
|
"t" : NumberLong(3)
|
}
|
},
|
"members" : [
|
{
|
"_id" : 0,
|
"name" : "AD-MAC10G.local:27017",
|
"health" : 0,
|
"state" : 8,
|
"stateStr" : "(not reachable/healthy)",
|
"uptime" : 0,
|
"optime" : {
|
"ts" : Timestamp(0, 0),
|
"t" : NumberLong(-1)
|
},
|
"optimeDurable" : {
|
"ts" : Timestamp(0, 0),
|
"t" : NumberLong(-1)
|
},
|
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
|
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
|
"lastHeartbeat" : ISODate("2017-04-26T22:10:04.105Z"),
|
"lastHeartbeatRecv" : ISODate("2017-04-26T21:28:42.092Z"),
|
"pingMs" : NumberLong(0),
|
"lastHeartbeatMessage" : "Connection refused",
|
"configVersion" : -1
|
},
|
{
|
"_id" : 1,
|
"name" : "AD-MAC10G.local:27018",
|
"health" : 1,
|
"state" : 1,
|
"stateStr" : "PRIMARY",
|
"uptime" : 2740,
|
"optime" : {
|
"ts" : Timestamp(1493244598, 1),
|
"t" : NumberLong(3)
|
},
|
"optimeDate" : ISODate("2017-04-26T22:09:58Z"),
|
"infoMessage" : "could not find member to sync from",
|
"electionTime" : Timestamp(1493244557, 1),
|
"electionDate" : ISODate("2017-04-26T22:09:17Z"),
|
"configVersion" : 1,
|
"self" : true
|
},
|
{
|
"_id" : 2,
|
"name" : "AD-MAC10G.local:27019",
|
"health" : 1,
|
"state" : 7,
|
"stateStr" : "ARBITER",
|
"uptime" : 57,
|
"lastHeartbeat" : ISODate("2017-04-26T22:10:03.982Z"),
|
"lastHeartbeatRecv" : ISODate("2017-04-26T22:10:02.801Z"),
|
"pingMs" : NumberLong(0),
|
"configVersion" : 1
|
}
|
],
|
"ok" : 1
|
}
|
replset:PRIMARY>
|
This makes it impossible to distinguish the write concern failure.
Attachments
Issue Links
- is related to
-
SERVER-29263 Shell bulk api hides write concern errors when there is a write error and the bulk write is 'ordered'
-
- Backlog
-