-
Type:
Bug
-
Resolution: Cannot Reproduce
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
None
-
ALL
-
Sharding 2016-10-10, Sharding 2016-10-31, Sharding 2016-11-21, Sharding 2016-12-12, Sharding 2017-01-02
-
0
-
None
-
None
-
None
-
None
-
None
-
None
-
None
I'm not sure how this managed to happen. Occurs in BF-3608
2016-09-23T16:07:49.719+0000 d23261| 2016-09-23T16:07:49.707+0000 I COMMAND [conn4] going to kill op: 497
2016-09-23T16:07:49.720+0000 d23261| 2016-09-23T16:07:49.711+0000 W COMMAND [conn1] failpoint: moveChunkHangAtStep3 set to: { mode: 0, data: {} }
2016-09-23T16:07:49.795+0000 d23261| 2016-09-23T16:07:49.793+0000 I SHARDING [conn11] moveChunk data transfer progress: { active: true, sessionId: "shard0000_shard0001_57e553552ab4c67e7602e6d7", ns: "testDB.bar", from: "ip-10-136-48-200:23261", min: { a: MinKey }, max: { a: MaxKey }, shardKeyPattern: { a: 1.0 }, state: "clone", counts: { cloned: 2, clonedBytes: 66, catchup: 0, steady: 0 }, ok: 1.0 } my mem used: 0
"cloned" is 2 here, if relevant. The failpoint is released as well, right after the killOp, possibly starting something before the killOp marking the txn takes affect. But there's only one document in that chunk, so shouldn't matter...
Then a .count() on the destination shard's collection is also 2 when it should be only 1 document that was cloned.
2016-09-23T16:07:50.770+0000 [thread1] Error: [1] != [2] are not equal : shard1 accessed the xfermods log despite donor migration abortion :