Re: mongo rebalancer failing.

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


Hi Saurabh.

I am getting Failed with error ‘chunk too big to move’, from rs3 to rs2

The error “chunk too big to move” is due to MongoDB balancer being unable 
to move a chunk from one shard to another. There are two possible reasons 
that could cause this error:

   - The chunk is larger than the specified chunk size 
   <https://docs.mongodb.org/manual/core/sharding-chunk-splitting/#sharding-chunk-size
   which is 64 MB by default, and cannot be split into smaller chunks. 
   - There are more than 250,000 documents 
   <https://docs.mongodb.org/manual/reference/limits/#Maximum-Number-of-Documents-Per-Chunk-to-Migrate
   in a chunk. 

If MongoDB cannot split a chunk, it will be marked as “jumbo” 
<https://docs.mongodb.org/manual/core/sharding-chunk-migration/#jumbo-chunks>. 
You may see these jumbo-marked chunks in the output of 
sh.status({verbose:true}).

The main reason for “chunk too big to move” error is sub-optimal selection 
of the shard key, where it’s either:

   1. has a low cardinality 
   <https://docs.mongodb.org/manual/tutorial/choose-a-shard-key/#cardinality>, 
   or 
   2. has a non-equal distribution. 

From the following two lines in your sh.status() output. In your case, I 
believe it’s due to the second reason:

shard key: { “ip” : 1 }

shard key: { “src_ip” : 1 }

If your application logs IP data in MongoDB, and some ip or src_ip are more 
common than others, you will create a large chunk that cannot be split. 
E.g., if you record a client’s IP address every time the client connects to 
you, then after 250,000 connections, the chunk that contains the client’s 
IP address now contains too many documents to be split.

Unfortunately once you select a shard key, it is immutable. There is no 
easy fix for this issue, other than dumping the collection and reload them 
with another shard key.

For topics concerning shard key selection, you might find this links 
informative: Considerations for Selecting Shard Keys 
<https://docs.mongodb.org/manual/tutorial/choose-a-shard-key/>.

Also it is worth mentioning for your case that a shard key like {"ip": 
"hashed"} does *not* solve the problem of cardinality, since the same IP 
address will be hashed to the same value and thus does not increase your 
key space at all.

I also would like to point out the following two lines from your sh.status() 
output:

4148 : Failed with error ‘data transfer error’, from rs3 to rs2

1521 : Failed with error ‘data transfer error’, from rs3 to rs1

There may be connectivity issues between rs3 to other shards in the 
cluster, since the balancer tries to move chunks out of shard rs3 and 
failed so many times due to data transfer error.

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/6cb54e57-058b-475c-b7d5-50a0f3d4dff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?