[SERVER-13043] shardCollection don't behave properly Created: 05/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major - P3
Reporter: Melania Zanin Assignee: Randolph Tan
Resolution: Done Votes: 0
Labels: sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Cluster on amazon cloud
3 config server-> t1.micro
2 mongos -> m1.medium
4 machines with each 4 shard -> m2.2xlarge

Operating system : AMAZON LINUX AMI
Mongodb version : 2.4.8


Issue Links:
Related
is related to SERVER-5160 Handle all failed shardCollection com... Closed
Operating System: Linux
Steps To Reproduce:

Don't know how to reproduce it.

Participants:

 Description   

I am creating and sharding collections dynamically with the PHP driver every week in this case.

When executing the 'shardCollection' db command with my driver, this last returned an exception 'collection already sharded with 1 chunks'. When I take a look at it, the collection in cause (MO_3h.MO_2014_09) isn't sharded at all.

Here are some useful data :

mongos> db.printShardingStatus()
 
MO_3h.MO_2014_09
                        shard key: { "_id" : 1 }
                        chunks:
MO_3h.MO_2014_10
                        shard key: { "_id" : 1 }
                        chunks:
                                shard0005       1
                        { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : shard0005 Timestamp(1, 0)

mongos> db.MO_2014_09.stats()
{
        "sharded" : false,
        "primary" : "shard0005",
        "ns" : "MO_3h.MO_2014_09",
        "count" : 10711832,
        "size" : 2423233888,
        "avgObjSize" : 226.22030367914658,
        "storageSize" : 2897113088,
        "numExtents" : 21,
        "nindexes" : 2,
        "lastExtentSize" : 756604928,
        "paddingFactor" : 1,
        "systemFlags" : 1,
        "userFlags" : 0,
        "totalIndexSize" : 5727582336,
        "indexSizes" : {
                "_id_" : 3398084592,
                "_id_m_1__id_r_1__id_d_1__id_h_1__id_p_1" : 2329497744
        },
        "ok" : 1
}

config.collections
{ "_id" : "MO_3h.MO_2014_09" , "lastmod" : { 
          "$date" : "1970-01-17T02:49:56.104Z"} , 
          "dropped" : false , "key" : { "_id" : 1} , 
          "unique" : false , "lastmodEpoch" : { "$oid" : "5301548756e74ab823a950ba"}
}

When executing a second time the 'shardCollection' db command, everything went right.
This happened to me 3 times in 8 months.

On which info should I base myself to know if the collection has been sharded or not? The config of the collection or its stats?



 Comments   
Comment by Thomas Rueckstiess [ 16/Apr/14 ]

Hi Melania,

I'm resolving this ticket now, but if you see the issue again, please re-open the ticket and provide additional information as Dan suggested above.

Thanks.
Thomas

Comment by Daniel Pasette (Inactive) [ 15/Mar/14 ]

The information should agree, but the collection.stats.sharded info is derived from the config database. If this happens again, can you please examine and attach the logs from the config server, mongos and primary shard of the collection?

Comment by Melania Zanin [ 13/Mar/14 ]

Hi,

I don't have them anymore. There was nothing suspicious other than the exception. I don't get how a brand new collection can be already sharded, when in fact it's not. Maybe there was an other problem and the exception caught was this one. Either way, re executing the command gave no problem at all. I just need to know on which info should I base myself to know if the collection has been sharded, if on config.collection or collection.stats.sharded. Thanks

Comment by Daniel Pasette (Inactive) [ 09/Mar/14 ]

looks related to SERVER-5160.

Do you have log files from the mongos you were connected to when you ran the command?

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