[SERVER-12391] Assertion "can't find shard for" when dropping sharded collection Created: 17/Jan/14  Updated: 06/Dec/22  Resolved: 20/Dec/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.4.8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Simon Schneider Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian Squeeze
MongoS 2.4.8
PyMongo 2.0.1


Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

MongoS can come in a state where dropping a sharded collection fails. Namespaces are no longer existent on shards, but configsvr entry in "collections" collection is still

{"dropped" : false}

After restart of MongoS dropping works fine.

Log Message in MongoS:

Fri Jan 17 09:12:32.201 [conn59971] DROP: database001.collection001
Fri Jan 17 09:12:32.201 [conn59971] about to log metadata event: { _id: "mongos001-2014-01-17T09:12:32-52d8f40058a9bbeefff45009", server: "mongos001", clientAddr: "N/A", time: new Date(1389949952201), what: "dropCollectio
n.start", ns: "database001.collection001", details: {} }
Fri Jan 17 09:12:32.680 [conn59971] distributed lock 'database001.collection001/mongos001:27017:1386839918:1804289383' acquired, ts : 52d8f40058a9bbeefff4500a
Fri Jan 17 09:12:33.420 [conn59971] Assertion: 13129:can't find shard for: shard001/server002:27018,server001:27018
0xa89e91 0xa4facb 0xa5000c 0x9a3568 0x99e874 0x8c856f 0x8c9e6b 0x9204b7 0x9994c6 0x90eb1b 0x9cae73 0x99716d 0x6666c4 0xa7645e 0x7fcd1eb598ca 0x7fcd1df0cb6d
 /usr/bin/mongos(_ZN5mongo15printStackTraceERSo+0x21) [0xa89e91]
 /usr/bin/mongos(_ZN5mongo11msgassertedEiPKc+0x9b) [0xa4facb]
 /usr/bin/mongos() [0xa5000c]
 /usr/bin/mongos(_ZN5mongo15StaticShardInfo4findERKSs+0x358) [0x9a3568]
 /usr/bin/mongos(_ZN5mongo5Shard5resetERKSs+0x34) [0x99e874]
 /usr/bin/mongos(_ZN5mongo15setShardVersionERNS_12DBClientBaseERKSsNS_12ChunkVersionEN5boost10shared_ptrIKNS_12ChunkManagerEEEbRNS_7BSONObjE+0x30f) [0x8c856f]
 /usr/bin/mongos(_ZNK5mongo12ChunkManager4dropEN5boost10shared_ptrIKS0_EE+0x10db) [0x8c9e6b]
 /usr/bin/mongos(_ZN5mongo15dbgrid_pub_cmds7DropCmd3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x267) [0x9204b7]
 /usr/bin/mongos(_ZN5mongo7Command22execCommandClientBasicEPS0_RNS_11ClientBasicEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0x416) [0x9994c6]
 /usr/bin/mongos(_ZN5mongo7Command20runAgainstRegisteredEPKcRNS_7BSONObjERNS_14BSONObjBuilderEi+0x21b) [0x90eb1b]
 /usr/bin/mongos(_ZN5mongo14SingleStrategy7queryOpERNS_7RequestE+0x2d3) [0x9cae73]
 /usr/bin/mongos(_ZN5mongo7Request7processEi+0x1bd) [0x99716d]
 /usr/bin/mongos(_ZN5mongo21ShardedMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x74) [0x6666c4]
 /usr/bin/mongos(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x42e) [0xa7645e]
 /lib/libpthread.so.0(+0x68ca) [0x7fcd1eb598ca]
 /lib/libc.so.6(clone+0x6d) [0x7fcd1df0cb6d]
Fri Jan 17 09:12:33.423 [conn59971] scoped connection to shard001/server002:27018,server001:27018 not being returned to the pool
Fri Jan 17 09:12:33.555 [conn59971] distributed lock 'database001.collection001/mongos001:27017:1386839918:1804289383' unlocked.
Fri Jan 17 09:12:33.821 [conn59971] end connection 10.3.44.13:56460 (9 connections now open)



 Comments   
Comment by Gregory McKeon (Inactive) [ 20/Dec/18 ]

Changes to dropCollection in 4.0 have made this go away.

Generated at Thu Feb 08 03:28:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.