DOCS-11573: csrs data center

Author: kay-kim

source/core/replica-set-architecture-geographically-distributed.txt

@@ -54,16 +54,15 @@ distributions of members include:
   - If Data Center 2 goes down, the replica set remains writeable as
     the members in Data Center 1 can hold an election.
 
-  .. note::
-
-     .. include:: /includes/extracts/arbiters-and-pvs-with-reference.rst
 
 - Three data centers: one members to Data Center 1, one member to Data
   Center 2, and one member to Data Center 3.
 
   - If any Data Center goes down, the replica set remains writeable as
     the remaining members can hold an election.
 
+.. include:: /includes/note-csrs-distribution.rst
+
 Five-member Replica Set
 ```````````````````````
 
@@ -78,12 +77,15 @@ distributions of members include:
   - If Data Center 2 goes down, the replica set remains writeable as
     the members in Data Center 1 can create a majority.
 
+
 - Three data centers: two member to Data Center 1, two members to Data
   Center 2, and one member to site Data Center 3.
 
   - If any Data Center goes down, the replica set remains writeable as
     the remaining members can hold an election.
 
+.. include:: /includes/note-csrs-distribution.rst
+
 For example, the following 5 member replica set distributes its members
 across three data centers.
 

source/core/replica-set-architectures.txt

@@ -125,6 +125,8 @@ throughput by distributing reads to secondary members. As your
 deployment grows, add or move members to alternate data centers to
 improve redundancy and availability.
 
+.. include:: /includes/note-csrs-distribution.rst
+
 Always ensure that the main facility is able to elect a primary.
 
 Add Capacity Ahead of Demand
@@ -146,6 +148,9 @@ the likelihood that even with a loss of a data center, the remaining
 replica set members can form a majority or at minimum, provide a copy
 of your data.
 
+.. include:: /includes/note-csrs-distribution.rst
+
+
 To ensure that the members in your main data center be elected primary
 before the members in the alternate data center, set the
 :rsconf:`members[n].priority` of the members in the alternate data

source/core/sharded-cluster-components.txt

@@ -43,13 +43,24 @@ for a production sharded cluster deployment:
 - Deploy each Shard as a 3 member :term:`replica set`
 - Deploy one or more :binary:`~bin.mongos` routers
 
+Replica Set Distribution
+~~~~~~~~~~~~~~~~~~~~~~~~
+
 Where possible, consider deploying one member of each replica set 
 in a site suitable for being a disaster recovery location.
 
+.. include:: /includes/note-csrs-distribution.rst
+
+Number of Shards
+~~~~~~~~~~~~~~~~
+
 Sharding requires at least two shards to distribute sharded data. Single
 shard sharded clusters may be useful if you plan on enabling sharding in
 the  near future, but do not need to at the time of deployment.
 
+Number of ``mongos`` and Distribution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 Deploying multiple :binary:`~bin.mongos` routers supports high
 availability and scalability. A common pattern is to place a
 :binary:`~bin.mongos` on each application server. Deploying one

source/includes/note-csrs-distribution.rst

@@ -0,0 +1,10 @@
+.. note::
+
+   Distributing replica set members across two data centers provides
+   benefit over a single data center. However, in a two data center
+   distribution, if the data center with the majority of the members
+   goes down, the replica set becomes read-only.
+
+   If possible, distribute members across at least three data centers.
+   For config server replica sets (CSRS), distribute across three (or
+   more depending on the number of members) centers if possible.

source/tutorial/deploy-geographically-distributed-replica-set.txt

@@ -67,12 +67,20 @@ For a geographically redundant three-member replica set deployment, you
 must decide how to distribute your system. Some possible distributions
 for the three members are:
 
-- Across Three Data Centers: One members to each site.
+- Across Three Data Centers: One members to each site. 
 
 - Across Two Data Centers: Two members to Site A and one member to Site
   B. If one of the members of the replica set is an arbiter, distribute
-  the arbiter to Site A with a data-bearing member.
+  the arbiter to Site A with a data-bearing member. 
 
+.. note::
+
+   Distributing across two data centers provides benefit over a single
+   data center. However, in a two data center distribution, if the data
+   center with two members goes down, the replica set becomes
+   read-only. As such, for config server replica sets (CSRS),
+   distribute across three data centers if possible.
+
 .. include:: /includes/steps/deploy-geographically-distributed-replica-set-3member.rst
 
 Deploy a Geographically Redundant Five-Member Replica Set
@@ -91,7 +99,10 @@ for the five members are:
 - Across Five Data Centers: One members in each site.
 
 - Across Two Data Centers: Three members in Site A and two members in
-  Site B.
+  Site B. If possible, avoid distributing config server replica set across only
+  two data centers.
+
+.. include:: /includes/note-csrs-distribution.rst
 
 The following five-member replica set includes an arbiter.
 

source/tutorial/troubleshoot-sharded-clusters.txt

@@ -81,6 +81,8 @@ and write data from the shards, but no :ref:`chunk migration
 </tutorial/split-chunks-in-sharded-cluster>` will occur until a primary
 is available.
 
+.. include:: /includes/note-csrs-distribution.rst
+
 .. include:: /includes/note-config-server-startup.rst
 
 .. _sharded-clusters-3.2-config-server-avail: