Critical - P2 We, intermittently, against a sharded cluster via a mongos get:
details
{u'code': 11000, u'ok': 1.0, u'initialGLEHost': u'rs1/cn61-ib:27018', u'err': u'E11000 duplicate key error index: mongoose_ahldev.centaur.$symbol_asc_sha_asc dup key: { : "EUROZONE_book_value_to_price", : BinData }', u'singleShard': u'rs4/cn64-ib:27018', u'connectionId': 8278, u'n': 0, u'writebackGLE': {u'code': 11000, u'ok': 1.0, u'err': u'E11000 duplicate key error index: mongoose_ahldev.centaur.$symbol_asc_sha_asc dup key: { : "EUROZONE_book_value_to_price", : BinData }', u'singleShard': u'rs4/cn64-ib:27018', u'connectionId': 8278, u'n': 0, u'lastOp': Timestamp(0, 0)}, u'lastOp': Timestamp(0, 0)}
__check_response_to_last_error [mongo_client.py:794]
_send_message [mongo_client.py:854]
remove [collection.py:565]
i.e. we're getting a E11000 duplicate key error from a remove!
Immediately before this is a find_one, and both are in a request.
(Also in control flow is a whole bunch of inserts w=0, some of which are expected to raise duplicateKeyErrors, which we want to ignore.)
Interestingly this only seems to happen via one mongos at a time. I.e. going through my local mongos, I can't trigger the problem, but picking the mongos where the problem last happened, and it happens everytime.
- depends on
-
SERVER-7958 GLE on sharded cluster can return previous operation's lastError
-
- Closed
-