Re: Operation timed out while trying to shard a collection

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 13 Apr 2016 16:01:20 -0700 (PDT)
Why ads?


Hi,

{ “code” : 50, “ok” : 0, “errmsg” : “Operation timed out” }

Error code 50 is a generic error message, saying that the operation 
exceeded a time limit. In this case:

2016-04-08T10:46:23.478-0400 I COMMAND [conn2] command admin.$cmd command: 
checkShardingIndex { checkShardingIndex: “test.events”, keyPattern: { 
publisher: 1.0, reported: 1.0 } } keyUpdates:0 writeConflicts:0 
numYields:784390 reslen:74 locks:{ Global: { acquireCount: { r: 1568782 } 
}, Database: { acquireCount: { r: 784391 } }, Collection: { acquireCount: { 
r: 784391 } } } protocol:op_command 72013ms

this checkShardingIndex operation took 72 seconds, and

2016-04-08T10:47:12.846-0400 I COMMAND [conn1] command admin.$cmd command: 
splitVector { splitVector: “test.events”, keyPattern: { publisher: 1.0, 
reported: 1.0 }, min: { publisher: MinKey, reported: MinKey }, max: { 
publisher: MaxKey, reported: MaxKey }, maxChunkSizeBytes: 67108864, 
maxSplitPoints: 0, maxChunkObjects: 0 } keyUpdates:0 writeConflicts:0 
numYields:784390 reslen:236463 locks:{ Global: { acquireCount: { r: 1568782 
} }, Database: { acquireCount: { r: 784391 } }, Collection: { acquireCount: 
{ r: 784391 } } } protocol:op_command 49339ms

this splitVector operation took 49 seconds. In combination, both operations 
took 121 seconds to finish, so the mongos returned the message that the 
sh.shardCollection() command took too long to finish in the form of a 
timeout error.

The checkShardingIndex command is an internal command that performs a 
collection scan to ensure that *every* document in the collection contains 
the shard key. For example, if the shard key is {a:1,b:1}, it will check 
every document for the existence of the field a and b.

The splitVector command is also an internal command. It uses the average 
object size and number of object in the collection to split the collection 
into chunks, based on the shard key and the maximum chunk size (which defaults 
to 64 MB 
<https://docs.mongodb.org/manual/core/sharding-chunk-splitting/#chunk-size>
).

The issue that leads to your timeout error is not only the number of 
documents, but also the size of the collection itself. Instead of importing 
the whole collection and sharding it afterward, a better solution is to 
pre-split the collection before importing. This will allow MongoDB to 
import documents directly into the chunks as efficiently as possible.

To pre-split a collection:

   1. Deploy the sharded cluster. 
   2. Create an empty collection using db.createCollection() 
   <https://docs.mongodb.org/manual/reference/method/db.createCollection/
   and also create the necessary indexes using db.collection.createIndex() 
   <https://docs.mongodb.org/manual/reference/method/db.collection.createIndex/>, 
   including the index that corresponds to the shard key. 
   3. Shard the collection using sh.shardCollection() 
   <https://docs.mongodb.org/manual/reference/method/sh.shardCollection/
   4. Pre-split the destination (empty) collection as described in Create 
   Chunks in a Sharded Cluster 
   <https://docs.mongodb.org/manual/tutorial/create-chunks-in-sharded-cluster/>. 
   You should see the balancer distributes the empty chunks across the shards. 
   *Note:* this pre-split step is automatically done if you are using a 
   hashed shard key 
   <https://docs.mongodb.org/manual/tutorial/shard-collection-with-a-hashed-shard-key/#specify-the-initial-number-of-chunks>
   . 
   5. Import your data via mongos. 

Since the empty chunks are already distributed and balanced, the imported 
data will go straight into the proper shard.

Please note that you should only pre-split an empty collection.

a compound index on “publisher” and “reported” (a date)

Choosing the correct shard key is extremely important for a sharded cluster 
deployment. If the shard key you are using involves a date element, the key 
will be monotonically increasing. This may result in a “hot shard”, i.e. 
there will be a shard that is more active compared to others. This could 
limit your insert rate, and the cluster will constantly need to split 
chunks and rebalance, since all inserts could go into a single chunk. 
Please see Sharding Pitfalls 
<http://blog.mongodb.org/post/98888988013/sharding-pitfalls-part-i>, Shard 
Keys <https://docs.mongodb.org/manual/core/sharding-shard-key/>, and Considerations 
for Selecting Shard Keys 
<https://docs.mongodb.org/manual/tutorial/choose-a-shard-key/> for more 
information regarding choosing a shard key.

Best regards,
Kevin


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/b95badcb-714e-4d70-807c-fb346d93f3b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?