|
| 1 | +.. index:: balancing; configure |
| 2 | + |
| 3 | +========================================================== |
| 4 | +Configure Behavior of Balancer Process in Sharded Clusters |
| 5 | +========================================================== |
| 6 | + |
| 7 | +.. default-domain:: mongodb |
| 8 | + |
| 9 | +The balancer runs on a single :program:`mongos` instance and distributes |
| 10 | +chunks evenly throughout a sharded cluster. In most deployments, you do |
| 11 | +not need to configure the balancer. The balancer automatically |
| 12 | +distributes chunks in an optimal manner. However, administrators might |
| 13 | +need to modify balancer behavior depending on application or operational |
| 14 | +requirements. Should a situation arise where modifying balancer behavior |
| 15 | +is necessary, this page describes settings that can be changed. |
| 16 | + |
| 17 | +For conceptual information about the balancer, see |
| 18 | +:ref:`sharding-balancing` and :ref:`sharding-balancing-internals`. |
| 19 | + |
| 20 | +.. _sharded-cluster-config-balancing-window: |
| 21 | + |
| 22 | +Schedule a Window of Time for Balancing to Occur |
| 23 | +------------------------------------------------ |
| 24 | + |
| 25 | +You can schedule a window of time during which the balancer is allowed |
| 26 | +to migrate chunks, as described in the following procedures: |
| 27 | + |
| 28 | +- :ref:`sharding-schedule-balancing-window` |
| 29 | + |
| 30 | +- :ref:`sharding-balancing-remove-window`. |
| 31 | + |
| 32 | +The configured time is evaluated relative to the time zone of each |
| 33 | +individual :program:`mongos` instance in the sharded cluster. |
| 34 | + |
| 35 | +.. _sharded-cluster-config-default-chunk-size: |
| 36 | + |
| 37 | +Configure Default Chunk Size |
| 38 | +---------------------------- |
| 39 | + |
| 40 | +The default chunk size for a sharded cluster is 64 megabytes. In most |
| 41 | +situations, the default size is appropriate for splitting and migrating |
| 42 | +chunks. For information on how chunk size affects deployments, see |
| 43 | +details, see :ref:`sharding-chunk-size`. |
| 44 | + |
| 45 | +Changing the default chunk size affects chunks that are processes during |
| 46 | +migrations and auto-splits but does not retroactively affect all chunks. |
| 47 | + |
| 48 | +To configure default chunk size, see :ref:`sharding-balancing-modify-chunk-size`. |
| 49 | + |
| 50 | +.. _sharded-cluster-config-max-shard-size: |
| 51 | + |
| 52 | +Change the Maximum Storage Size for a Given Shard |
| 53 | +------------------------------------------------- |
| 54 | + |
| 55 | +The ``maxSize`` field in the :data:`~config.shards` collection in the |
| 56 | +:ref:`config database <config-database>` sets the maximum size for a |
| 57 | +shard, allowing you to control whether the balancer will migrate chunks |
| 58 | +to a shard. If :data:`dataSize <~dbStats.dataSize>` is above a shard's |
| 59 | +``maxSize``, the balancer will not move chunks to the shard. Also, the |
| 60 | +balancer will not move chunks off an overloaded shard. This must happen |
| 61 | +manually. The ``maxSize`` value only affects the balancer's selection of |
| 62 | +destination shards. |
| 63 | + |
| 64 | +By default, ``maxSize`` is not specified, allowing shards to consume the |
| 65 | +total amount of available space on their machines if necessary. |
| 66 | + |
| 67 | +You can set ``maxSize`` both when adding a shard and once a shard is |
| 68 | +running. |
| 69 | + |
| 70 | +To set ``maxSize`` when adding a shard, set the :dbcommand:`addShard` |
| 71 | +command's ``maxSize`` parameter to the maximum size in megabytes. For |
| 72 | +example, the following command run in the :program:`mongo` shell adds a |
| 73 | +shard with a maximum size of 125 megabytes: |
| 74 | + |
| 75 | +.. code-block:: javascript |
| 76 | + |
| 77 | + db.runCommand( { addshard : "example.net:34008", maxSize : 125 } ) |
| 78 | + |
| 79 | +To set ``maxSize`` on an existing shard, insert or update the |
| 80 | +``maxSize`` field in the :data:`~config.shards` collection in the |
| 81 | +:ref:`config database <config-database>`. Set the ``maxSize`` in |
| 82 | +megabytes. |
| 83 | + |
| 84 | +.. example:: |
| 85 | + |
| 86 | + Assume you have the following shard without a ``maxSize`` field: |
| 87 | + |
| 88 | + .. code-block:: javascript |
| 89 | + |
| 90 | + { "_id" : "shard0000", "host" : "example.net:34001" } |
| 91 | + |
| 92 | + Run the following sequence of commands in the :program:`mongo` shell |
| 93 | + to insert a ``maxSize`` of 125 megabytes: |
| 94 | + |
| 95 | + .. code-block:: javascript |
| 96 | + |
| 97 | + use config |
| 98 | + db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 125 } } ) |
| 99 | + |
| 100 | + To later increase the ``maxSize`` setting to 250 megabytes, run the |
| 101 | + following: |
| 102 | + |
| 103 | + .. code-block:: javascript |
| 104 | + |
| 105 | + use config |
| 106 | + db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 250 } } ) |
| 107 | + |
| 108 | +.. index:: balancing; secondary throttle |
| 109 | +.. index:: secondary throttle |
| 110 | +.. _sharded-cluster-config-secondary-throttle: |
| 111 | + |
| 112 | +Require Replication before Chunk Migration (Secondary Throttle) |
| 113 | +--------------------------------------------------------------- |
| 114 | + |
| 115 | +.. versionadded:: 2.2.1 |
| 116 | + |
| 117 | +You can configure the balancer to wait for replication to secondaries |
| 118 | +during migrations. You do so by enabling the balancer's |
| 119 | +``_secondaryThrottle`` parameter, which reduces throughput (i.e., |
| 120 | +"throttles") in order to decrease the load on secondaries. You might do |
| 121 | +this, for example, if you have migration-caused I/O peaks that impact |
| 122 | +other workloads |
| 123 | + |
| 124 | +When enabled, secondary throttle puts a ``{ w : 2 }`` write concern on |
| 125 | +deletes and on copies, which means the balancer waits for those |
| 126 | +operations to replicate to at least one secondary before migrating |
| 127 | +chunks. |
| 128 | + |
| 129 | +.. BACKGROUND NOTES |
| 130 | + Specifically, secondary throttle affects the first and fourth |
| 131 | + phases (informal phases) of chunk migration. Migration can happen during |
| 132 | + the second and third phases (the "steady state"): |
| 133 | + 1) copies the documents in the chunk from shardA to shardB |
| 134 | + 2) continues to copy over ongoing changes that occurred during the initial copy step, |
| 135 | + as well as current changes to that chunk range |
| 136 | + 3) Stop writes, allow shardB to get final changes, commit migration to config server |
| 137 | + 4) cleanup now-inactive data on shardA in chunk range (once all cursors are done) |
| 138 | + |
| 139 | +You enable ``_secondaryThrottle`` directly in the |
| 140 | +:data:`settings <~config.settings>` collection in the :ref:`config database |
| 141 | +<config-database>` by running the following commands from the |
| 142 | +:program:`mongo` shell: |
| 143 | + |
| 144 | +.. code-block:: javascript |
| 145 | + |
| 146 | + use config |
| 147 | + db.settings.update( { "_id" : "balancer" } , { $set : { "_secondaryThrottle" : true } , { upsert : true } } ) |
| 148 | + |
| 149 | +You also can enable secondary throttle when issuing the |
| 150 | +:dbcommand:`moveChunk` command by setting ``_secondaryThrottle`` to |
| 151 | +``true``. For more information, see :dbcommand:`moveChunk`. |
0 commit comments