Lock is not taken, but an ugly and confusing assert is logged.
From test failure:
m27001| 2014-04-01T21:07:24.400-0400 [conn11] Collection config.locks does not exist. Using EOF runner: query: { _id: "configUpgrade", state: 0 } sort: {} projection: {}
m27001| 2014-04-01T21:07:24.400-0400 [conn11] update config.locks query: { _id: "configUpgrade", state: 0 } update: { $set: { state: 1, who: "ip-10-146-215-7:27003:1396400844:1804289383:mongosMain:846930886", process: "ip-10-146-215-7:27003:1396400844:1804289383", when: new Date(1396400844233), why: "upgrading config database to new format v5", ts: ObjectId('533b62cccf9c8a51fbe0c364') } } nscanned:0 nscannedObjects:0 nMatched:0 nModified:0 keyUpdates:0 numYields:0 locks(micros) w:218 0ms
...
m27001| 2014-04-01T21:07:24.400-0400 [conn13] Database::_addNamespaceToCatalog ns: config.locks
...
m27001| 2014-04-01T21:07:24.401-0400 [conn13] insert config.locks ninserted:1 keyUpdates:0 numYields:0 locks(micros) r:37 w:721 0ms
The first config upgrade lock document got inserted on the first config server (27000) by some non-27003 mongos - this caused the mongos at port 27003 to try to lock the initial lock document. On the second config server though (27001, as seen above), the mongos's update at port 27003 beat the initial lock document and so the update didn't apply. Crossing messages between servers is normal for distributed locks, but since this was the very first lock document created there was no "ts" field and the tournament was confused and errored.
Behavior has been like this for a long time.
- is duplicated by
-
SERVER-7161 Sharding will fail with non obvious error when locks collection is not consistent
-
- Closed
-