From 70f37d07e10b9825ec5365a4dfa09eb4a7201437 Mon Sep 17 00:00:00 2001 From: Ed Costello Date: Thu, 30 Aug 2012 14:45:55 -0400 Subject: [PATCH] DOCS-448 annotate that config servers may only work with one shard cluster Also some edits for style and clarification --- .../administration/sharding-architectures.txt | 7 ++- source/core/sharding.txt | 60 ++++++++++++------- source/reference/glossary.txt | 2 +- 3 files changed, 45 insertions(+), 24 deletions(-) diff --git a/source/administration/sharding-architectures.txt b/source/administration/sharding-architectures.txt index 176c5b11c52..5ebe501f3f3 100644 --- a/source/administration/sharding-architectures.txt +++ b/source/administration/sharding-architectures.txt @@ -40,6 +40,11 @@ a production-level shard cluster should have the following: - 3 :ref:`config servers `, each residing on a separate node. +.. note:: + + :ref:`Config servers ` are tied to single shard + cluster and cannot be shared by multiple shard clusters. + - For each shard, a three member :term:`replica set ` consisting of: - 3 :program:`mongod` replicas or @@ -70,7 +75,7 @@ a production-level shard cluster should have the following: information. - :program:`mongos` instances. Typically, you will deploy a single - :program:`mongos` instance on every application server. Alternatively, + :program:`mongos` instance on each application server. Alternatively, you may deploy several `mongos` nodes and let your application connect to these via a load balancer. diff --git a/source/core/sharding.txt b/source/core/sharding.txt index 2b36c8e645b..26a53ec62a3 100644 --- a/source/core/sharding.txt +++ b/source/core/sharding.txt @@ -77,7 +77,7 @@ MongoDB has the following features: users to increase the potential amount of data to mange with MongoDB and expand the :term:`working set`. -A typical :term:`shard cluster` consists of config servers that +A typical :term:`shard cluster` consists of config servers which store metadata that maps :term:`chunks ` to shards, the :program:`mongod` instances which hold data (i.e the :term:`shards `,) and lightweight routing processes, :doc:`mongos @@ -89,7 +89,7 @@ Indications While sharding is a powerful and compelling feature, it comes with significant :ref:`infrastructure requirements ` -and some limited complexity costs. As a result, its important to use +and some limited complexity costs. As a result, it's important to use sharding only as necessary, and when indicated by actual operational requirements. Consider the following overview of indications it may be time to consider sharding. @@ -108,8 +108,8 @@ You should consider deploying a :term:`shard cluster`, if: If these attributes are not present in your system, sharding will only add additional complexity to your system without providing much benefit. -If you do plan to eventually partition your data, you should also -give some thought to which collections you'll want to shard along with +If you plan to eventually partition your data, you should +consider which collections you will want to shard along with the corresponding shard keys. .. _sharding-capacity-planning: @@ -122,7 +122,7 @@ the corresponding shard keys. application. As a result, if you think you're going to need sharding eventually, - its crucial that you **do not** wait until your system is + it's critical that you **do not** wait until your system is overcapacity to enable sharding. .. index:: sharding; requirements @@ -143,7 +143,7 @@ A :term:`shard cluster` has the following components: These special :program:`mongod` instances store the metadata for the cluster. The :program:`mongos` instances cache this data and use it to determine which :term:`shard` is responsible for which - :term:`chunk`. + :term:`chunk`. For testing purposes you may deploy a shard cluster with a single configuration server, but this is not recommended for production. @@ -158,8 +158,8 @@ A :term:`shard cluster` has the following components: These are "normal," :program:`mongod` instances that hold all of the actual data for the cluster. - Typically, a :term:`replica sets `, consisting of - multiple :program:`mongod` instances, compose a shard. The members + Typically, one or more :term:`replica sets `, consisting of + multiple :program:`mongod` instances, compose a shard cluster. The members of the replica set provide redundancy for the data and increase the overall reliability and robustness of the cluster. @@ -182,7 +182,7 @@ A :term:`shard cluster` has the following components: resources, and you can run them on your application servers without impacting application performance. However, if you use the :term:`aggregation framework` some processing may occur on - the :program:`mongos` instances that causes them to require more + the :program:`mongos` instances which can cause them to require more system resources. Data @@ -300,21 +300,30 @@ help produce one that is more ideal. Config Servers -------------- -The configuration servers store the shard metadata that tracks the -relationship between the range that defines a :term:`chunk` and the -:program:`mongod` instance (typically a :term:`replica set`) or -:term:`shard` where that data resides. Without a config server, the +Config servers maintain the shard metadata in a config +database. The :term:`config database ` stores +the relationship between :term:`chunks ` and where they reside +within a :term:`shard cluster`. Without a config database, the :program:`mongos` instances would be unable to route queries or write -operations within the cluster. This section describes their operation -and use. +operations within the cluster. Config servers *do not* run as replica sets. Instead, a :term:`shard -cluster` operates with a group of *three* config servers that use a +cluster` operates with a group of *three* config servers which use a two-phase commit process that ensures immediate consistency and -reliability. Because the :program:`mongos` instances all maintain -caches of the config server data, the actual load on the config -servers is small. MongoDB will write data to the config server only -when: +reliability. + +For testing purposes you may deploy a shard cluster with a single +config server, but this is not recommended for production. + +.. warning:: + + If you choose to run a single config server and it becomes + inoperable for any reason, the cluster will be unusable. + +The actual load on configuration servers is small because each +:program:`mongos` instances maintains a cached copy of the configuration +database. +MongoDB will write data to the config server only when: - Creating splits in existing chunks, which happens as data in existing chunks exceeds the maximum chunk size. @@ -344,10 +353,17 @@ Because the configuration data is small relative to the amount of data stored in a cluster, the amount of activity is relatively low, and 100% up time is not required for a functioning shard cluster. As a result, backing up the config servers is not difficult. Backups of config -servers are crucial as shard clusters become totally inoperable when +servers are critical as shard clusters become totally inoperable when you lose all configuration instances and data. Precautions to ensure that the config servers remain available and intact are critical. + .. note:: + + Configuration servers maintain metadata for only one shard cluster. + You must have a separate configuration server or servers for each + shard cluster you configure. + + .. index:: mongos .. _sharding-mongos: @@ -458,7 +474,7 @@ have on the cluster, by: `. Additionally, it's possible to disable the balancer on a temporary -basis for maintenance and limit the window during which it runs to +basis for maintenance and to limit the window during which it runs to prevent the balancing process from impacting production traffic. .. seealso:: The ":ref:`"Balancing Internals diff --git a/source/reference/glossary.txt b/source/reference/glossary.txt index 61986db49c1..b72a2c3b9d0 100644 --- a/source/reference/glossary.txt +++ b/source/reference/glossary.txt @@ -356,7 +356,7 @@ Glossary held allows concurrent readers, but no writers. config database - One of three :program:`mongod` instances that store all the + One of three :program:`mongod` instances that store all of the metadata associated with a :term:`shard cluster`. balancer