发布于 2015-09-14 15:02:29 | 174 次阅读 | 评论: 0 | 来源: 网络整理
The balancer is a process that runs on one of the mongos instances in a cluster and ensures that chunks are evenly distributed throughout a sharded cluster. In most deployments, the default balancer configuration is sufficient for normal operation. However, administrators might need to modify balancer behavior depending on application or operational requirements. If you encounter a situation where you need to modify the behavior of the balancer, use the procedures described in this document.
For conceptual information about the balancer, see Shard Balancing and Cluster Balancer.
You can schedule a window of time during which the balancer can migrate chunks, as described in the following procedures:
The mongos instances user their own local timezones to when respecting balancer window.
The default chunk size for a sharded cluster is 64 megabytes. In most situations, the default size is appropriate for splitting and migrating chunks. For information on how chunk size affects deployments, see details, see Chunk Size.
Changing the default chunk size affects chunks that are processes during migrations and auto-splits but does not retroactively affect all chunks.
To configure default chunk size, see Modify Chunk Size.
The maxSize field in the shards collection in the config database sets the maximum size for a shard, allowing you to control whether the balancer will migrate chunks to a shard. If dataSize is above a shard’s maxSize, the balancer will not move chunks to the shard. Also, the balancer will not move chunks off an overloaded shard. This must happen manually. The maxSize value only affects the balancer’s selection of destination shards.
By default, maxSize is not specified, allowing shards to consume the total amount of available space on their machines if necessary.
You can set maxSize both when adding a shard and once a shard is running.
To set maxSize when adding a shard, set the addShard command’s maxSize parameter to the maximum size in megabytes. For example, the following command run in the mongo shell adds a shard with a maximum size of 125 megabytes:
db.runCommand( { addshard : "example.net:34008", maxSize : 125 } )
To set maxSize on an existing shard, insert or update the maxSize field in the shards collection in the config database. Set the maxSize in megabytes.
Example
Assume you have the following shard without a maxSize field:
{ "_id" : "shard0000", "host" : "example.net:34001" }
Run the following sequence of commands in the mongo shell to insert a maxSize of 125 megabytes:
use config
db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 125 } } )
To later increase the maxSize setting to 250 megabytes, run the following:
use config
db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 250 } } )
2.2.1 新版功能.
You can configure the balancer to wait for replication to secondaries during migrations. You do so by enabling the balancer’s _secondaryThrottle parameter, which reduces throughput (i.e., “throttles”) in order to decrease the load on secondaries. You might do this, for example, if you have migration-caused I/O peaks that impact other workloads
When enabled, secondary throttle puts a { w : 2 } write concern on deletes and on copies, which means the balancer waits for those operations to replicate to at least one secondary before migrating chunks.
You enable _secondaryThrottle directly in the settings collection in the config database by running the following commands from the mongo shell:
use config
db.settings.update( { "_id" : "balancer" } , { $set : { "_secondaryThrottle" : true } , { upsert : true } } )
You also can enable secondary throttle when issuing the moveChunk command by setting _secondaryThrottle to true. For more information, see moveChunk.