DOCS-5289 fix config server write descriptions

Author: kay-kim

source/core/sharded-cluster-config-servers.txt

@@ -11,15 +11,15 @@ Config Servers
 
 Config servers are special :program:`mongod` instances that store the
 :doc:`metadata </core/sharded-cluster-metadata>` for a sharded cluster.
-Config servers use a two-phase commit to ensure immediate consistency
-and reliability. Config servers *do not* run as replica sets. All
-config servers must be available to deploy a sharded cluster or to
-make any changes to cluster metadata.
 
-A production sharded cluster has *exactly three* config servers. For
-testing purposes you may deploy a cluster with a single config server.
-But to ensure redundancy and safety in production, you should always
-use three.
+A production sharded cluster has *exactly three* config servers. All
+config servers must be available to deploy a sharded cluster or to make
+any changes to cluster metadata. Config servers *do not* run as replica
+sets.
+
+For testing purposes you may deploy a cluster with a single config
+server. But to ensure redundancy and safety in production, you should
+always use three.
 
 .. warning::
 
@@ -40,34 +40,36 @@ same config servers for different sharded clusters.
 .. index:: config databases
 .. index:: database, config
 
-Config Database
----------------
-
-Config servers store the metadata in the :doc:`config database
-</reference/config-database>`. The :program:`mongos` instances cache
-this data and use it to route reads and writes to shards.
-
 .. _config-server-read-write-ops:
 
 Read and Write Operations on Config Servers
 -------------------------------------------
 
-MongoDB only writes data to the config server in the following cases:
+Config servers store the cluster's metadata in the :doc:`config
+database </reference/config-database>`. The :program:`mongos` instances
+cache this data and use it to route reads and writes to shards.
+
+MongoDB only writes data to the config server when the metadata
+changes, such as
+
+- after a :doc:`chunk migration </core/sharding-chunk-migration>`, or
 
-- To create splits in existing chunks. For more information, see
-  :doc:`chunk splitting </core/sharding-chunk-splitting>`.
+- after a :doc:`chunk split </core/sharding-chunk-splitting>`.
 
-- To migrate a chunk between shards. For more information, see
-  :doc:`chunk migration </core/sharding-chunk-migration>`.
+When writing to the three config servers, a coordinator dispatches the
+same write commands to the three config servers and collects the
+results. Differing results indicate an inconsistent writes to the
+config servers and may require manual intervention. Once the config
+servers become inconsistent, the balancer will not perform any chunk
+migration and :program:`mongos` will not perform auto-splits of chunks.
 
-MongoDB reads data from the config server data in the following
-cases:
+MongoDB reads data from the config server in the following cases:
 
 - A new :program:`mongos` starts for the first time, or an existing
   :program:`mongos` restarts.
 
-- After a chunk migration, the :program:`mongos` instances update
-  themselves with the new cluster metadata.
+- After change in the cluster metadata, such as after a chunk
+  migration.
 
 MongoDB also uses the config server to manage distributed locks.
 
@@ -85,13 +87,12 @@ after the config servers are accessible again. If you restart the
 :program:`mongos` instances before the config servers are available,
 the :program:`mongos` will be unable to route reads and writes.
 
-Clusters become inoperable without the cluster metadata. *Always,*
-ensure that the config servers remain available and intact. As such,
-backups of config servers are critical. The data on the config server
-is small compared to the data stored in a cluster. This means the
-config server has a relatively low activity load, and the config
-server does not need to be always available to support a sharded
-cluster. As a result, it is easy to back up the config servers.
+Clusters become inoperable without the cluster metadata. To ensure that
+the config servers remain available and intact, backups of config
+servers are critical. The data on the config server is small compared
+to the data stored in a cluster, and the config server has a relatively
+low activity load. These properties facilitate finding a window to back
+up the config servers.
 
 .. include:: /includes/fact-rename-config-servers-requires-cluster-restart.rst
 

source/core/sharded-cluster-high-availability.txt

@@ -47,17 +47,24 @@ other shards. However, your application must be able to deal with
 partial results, and you should investigate the cause of the
 interruption and attempt to recover the shard as soon as possible.
 
-One or Two Config Databases Become Unavailable
-----------------------------------------------
-
-Three distinct :program:`mongod` instances provide the :term:`config
-database` using a special two-phase commits to maintain consistent state
-between these :program:`mongod` instances. Cluster operation will
-continue as normal but :ref:`chunk migration <sharding-balancing>` and
-the cluster can create no new :doc:`chunk splits
-</tutorial/split-chunks-in-sharded-cluster>`. Replace the config server as soon as
-possible. If all config databases become unavailable, the
-cluster can become inoperable.
+One or Two Config Servers Become Unavailable
+--------------------------------------------
+
+Three distinct :program:`mongod` instances provide the :doc:`config
+servers </core/sharded-cluster-config-servers>`.
+
+If one or two config servers become unavailable, the cluster's metadata
+becomes *read only*. You can still read and write data from the shards,
+but no :ref:`chunk migration <sharding-balancing>` or :doc:`chunk
+splits </tutorial/split-chunks-in-sharded-cluster>` will occur until
+all three servers are available. Replace the config server as soon as
+possible. If all config databases become unavailable, the cluster can
+become inoperable.
+
+If the config servers are inconsistent, the balancer will not perform
+any :ref:`chunk migration <sharding-balancing>` nor will the
+:program:`mongos` perform :doc:`auto-chunk splits
+</tutorial/split-chunks-in-sharded-cluster>`.
 
 .. include:: /includes/note-config-server-startup.rst