- Administration >
- Data Center Awareness >
- Zones
Zones¶
On this page
In sharded clusters, you can create zones of sharded data based on the shard key. You can associate each zone with one or more shards in the cluster. A shard can associate with any number of non-conflicting zones. In a balanced cluster, MongoDB migrates chunks covered by a zone only to those shards associated with the zone.
Some common deployment patterns where zones can be applied are as follows:
- Isolate a specific subset of data on a specific set of shards.
- Ensure that the most relevant data reside on shards that are geographically closest to the application servers.
- Route data to shards based on the hardware / performance of the shard hardware.
The following image illustrates a sharded cluster with three shards and two
zones. The A
zone represents a range with a lower boundary of 1
and an
upper bound of 10
. The B
zone represents a range with a lower boundary
of 10
and an upper boundary of 20
. Shards Alpha
and Beta
have
the A
zone. Shard Beta
also has the B
zone. Shard Charlie
has
no zones associated with it. The cluster is in a steady state and no chunks
violate any of the zones.
Behavior and Operations¶
Ranges¶
Each zone covers one or more ranges of shard key values. Each range a zone covers is always inclusive of its lower boundary and exclusive of its upper boundary.
Zones cannot share ranges, nor can they have overlapping ranges.
Balancer¶
The balancer attempts to evenly distribute a sharded collection’s chunks across all shards in the cluster.
For each chunk marked for migration, the balancer checks each possible destination shard for any configured zones. If the chunk range falls into a zone, the balancer migrates the chunk into a shard inside that zone. Chunks that do not fall into a zone can exist on any shard in the cluster and are migrated normally.
During balancing rounds, if the balancer detects that any chunks violate the configured zones for a given shard, the balancer migrates those chunks to a shard where no conflict exists.
After configuring a zone with a shard key range and associating it with a shard or shards, the cluster may take some time to migrate the affected data. This depends on the division of chunks and the current distribution of data in the cluster. When balancing is complete, reads and writes for documents in a given zone are routed only to the shard or shards inside that zone.
Once configured, the balancer respects zones during future balancing rounds.
Shard Key¶
You must use fields contained in the shard key when defining a new range for a zone to cover. If using a compound shard key, the range must include the prefix of the shard key.
For example, given a shard key { a : 1, b : 2, c : 3 }
, creating or
updating a zone to cover values of b
requires including a
as the
prefix. Creating or updating a zone to covers values of c
requires
including a
and b
as the prefix.
You cannot create zones using fields not included in the shard key. For example, if you wanted to use zones to partition data based on geographic location, the shard key would need at least one field that contained geographic data.
When choosing a shard key for a collection, consider what fields you might want to use for configuring zones. After sharding, you cannot change the shard key. See Choosing a Shard Key for considerations in choosing a shard key.
Hashed Shard Keys and Zones¶
When using zones on a hashed shard key, each zone covers the hashed shard
key values. Given a shard key { a : 1 }
and a zone alpha
with a lower
bound of 1
and an upper bound of 5
, the bounds represent the hashed
value of a
, and not the actual value. Therefore, there is no guarantee
that MongoDB routes documents where a
has a value of 1
to 5
to
zone alpha
. MongoDB routes any document where the hashed shard key value
falls within the range of 1
or 5
to a shard inside zone alpha
.
In general, a zone covering a sequential range of hashed shard key values may exhibit unexpected behavior.
It is possible create a zone which covers the entire range of shard key values
using minkey
and maxkey
to guarantee that MongoDB
restricts all the data for a specific collection to the shard or shards in
that zone.
Shard Zone Boundaries¶
Zone ranges are always inclusive of the lower boundary and exclusive of the upper boundary.
See also