DOCS-240: replication review counter-edits

Author: Sam Kleinman

source/administration/replica-sets.txt

@@ -4,11 +4,12 @@ Replica Set Administration
 
 .. default-domain:: mongodb
 
-:term:`Replica sets <replica set>` automate the vast majority of the
-administrative tasks associated with database replication and
-management. However, administrators must perform some tasks manually.
-This document gives an overview of those tasks. This document also
-provides troubleshooting suggestions.
+:term:`Replica sets <replica set>` automate most
+administrative tasks associated with database replication.
+However, some tasks related to deployment and system management still
+require administrator intervention. This document provides an overview
+of those those tasks as well as a collection of troubleshooting
+suggestions for administers of replica sets.
 
 .. seealso::
 
@@ -39,10 +40,10 @@ the following to prepare the new member's :term:`data directory <dbpath>`:
 - Make sure the new member's data directory *does not* contain data. The
   new member will copy the data directory from an existing member.
 
-  If the new member is in ":term:`recovering`" status, it must exit
-  recovering status and become a :term:`secondary` member before MongoDB
-  can copy all data as part of the replication process. This process can
-  be time intensive but does not require administrator intervention.
+  If the new member is in a ":term:`recovering`" state, it must exit
+  become a :term:`secondary` before MongoDB
+  can copy all data as part of the replication process. This process
+  takes time but does not require administrator intervention.
 
 - Manually copy the data directory from an existing member. The new
   member becomes a secondary member and will catch up to the current
@@ -51,7 +52,7 @@ the following to prepare the new member's :term:`data directory <dbpath>`:
   current.
 
   Ensure that you can copy the data directory to the new member and
-  begin replication within the window allowed by the oplog. If the
+  begin replication within the :ref:`window allowed by the oplog <replica-set-oplog-sizing>`. If the
   difference in the amount of time between the most recent operation and
   the most recent operation to the database exceeds the length of the
   :term:`oplog` on the existing members, then the new instance will have
@@ -168,12 +169,12 @@ There are two processes for replacing a member of a :term:`replica set`:
 .. warning::
 
    Any replica set configuration change can trigger the current
-   :term:`primary` to step down, forcing an :term:`election`. This
-   causes the current shell session to produce an error even when the
-   operation succeeds. Also, clients connected to this replica set will
-   disconnect.
+   :term:`primary` to step down, which forces an :term:`election`. This
+   causes the current shell session, and clients connected to this replica set,
+   to produce an error even when the operation succeeds.
 
 .. _replica-set-node-priority-configuration:
+.. _replica-set-member-priority-configuration:
 
 Adjusting Priority
 ~~~~~~~~~~~~~~~~~~~~
@@ -205,8 +206,7 @@ elections. :ref:`Hidden members <replica-set-hidden-members>`,
 :ref:`arbiters <replica-set-arbiters>` all have :data:`members[n].priority`
 set to ``0``.
 
-Unless configured otherwise, all members have a :data:`members[n].priority`
-set to ``1``.
+All members have a :data:`members[n].priority` equal to ``1`` by default.
 
 The value of :data:`members[n].priority` can be any floating point
 (i.e. decimal) number between ``0`` and ``1000``. Priorities
@@ -243,31 +243,32 @@ cases the :ref:`default oplog size <replica-set-oplog-sizing>` is an
 acceptable size; however, in some situations you may need a larger or
 smaller oplog. To resize the oplog, follow these steps:
 
-1. Restart the current :term:`primary` instance in the :term:`replica set` in
+#. Restart the current :term:`primary` instance in the :term:`replica set` in
    "standalone" mode, running on a different port.
 
-2. Save the last entry from the old (current) oplog and create a
+#. Save the last entry from the old (current) oplog and create a
    backup of the oplog.
 
-3. Drop the old oplog and create a new oplog of a different size.
+#. Drop the existing oplog and create a new oplog of a different size.
 
-4. Insert the previously saved last entry from the old oplog into the
+#. Insert the previously saved last entry from the old oplog into the
    new oplog.
 
-5. Restart the server as a member of the replica set on its usual
+#. Restart the server as a member of the replica set on its usual
    port.
 
-6. Apply this procedure to any other member of the replica set that
+#. Apply this procedure to any other member of the replica set that
    *could become* primary.
 
 .. seealso:: The ":doc:`/tutorial/change-oplog-size`" tutorial.
 
 .. _replica-set-node-configurations:
+.. _replica-set-member-configurations:
 
 Member Configurations
 ---------------------
 
-All :term:`replica set's` have a single :term:`primary` and one or more
+All :term:`replica sets <replica set>` have a single :term:`primary` and one or more
 :term:`secondaries <secondary>`. Replica sets sets allow you to configure
 secondary members in a variety of ways. This section describes these
 configurations.
@@ -345,7 +346,7 @@ operations in the :program:`mongo` shell:
    rs.reconfig(cfg)
 
 After re-configuring the set, the member with the ``_id`` of ``0``
-has a priority of ``0`` so that it cannot become master. The
+has a priority of ``0`` so that it cannot become primary. The
 other members in the set will not advertise the hidden member in the
 :dbcommand:`isMaster` or :func:`db.isMaster()` output.
 
@@ -479,8 +480,7 @@ shared key file that serves as a shared password.
 
 .. versionadded:: 1.8 for replica sets (1.9.1 for sharded replica sets) added support for authentication.
 
-To enable authentication using a key file for the replica set,
-add the following option to your configuration file:
+To enable authentication add the following option to your configuration file:
 
 .. code-block:: cfg
 

source/administration/replication-architectures.txt

@@ -4,27 +4,28 @@ Replication Architectures
 
 .. default-domain:: mongodb
 
-There is no single :term:`replica set` architecture that is ideal for
+There is no single ideal :term:`replica set` architecture for
 every deployment or environment. Indeed the flexibility of replica sets
 might be their greatest strength. This document describes the most
 commonly used deployment patterns for replica sets. The descriptions
-are necessarily not mutually exclusive and in some cases can be combined.
+are necessarily not mutually exclusive, and you can combine features
+of each architecture in your own deployment.
 
 .. seealso:: :doc:`/administration/replica-sets` and
-   :doc:`/reference/replica-configuration`
+   :doc:`/reference/replica-configuration`.
 
-Three-Member Sets
-------------------
+Three Member Sets
+-----------------
 
-The minimum *recommended* architecture for a replica set consists of
+The minimum *recommended* architecture for a replica set consists of:
 
-- One :term:`primary <primary>`
+- One :term:`primary <primary>` and
 
 - Two :term:`secondary <secondary>` members, either of which can become
   the primary at any time.
 
   This makes :ref:`failover <replica-set-failover>` possible and ensures
-  there exists two full, independent copies of the data set at all
+  there exists two full and independent copies of the data set at all
   times. If the primary fails, the replica set elects another member as
   primary and continues replication until the primary recovers.
 
@@ -58,8 +59,8 @@ conditions are true:
 - Members that cannot function as primaries in a :term:`failover`
   have their :data:`priority <members[n].priority>` values set to ``0``.
 
-  If a member cannot function as a primary, for example because of
-  resource constraints, a :data:`priority <members[n].priority>` value
+  If a member cannot function as a primary because of
+  resource or network latency constraints a :data:`priority <members[n].priority>` value
   of ``0`` prevents it from being a primary. Any member with a
   ``priority`` value greater than ``0`` is available to be a primary.
 
@@ -73,9 +74,7 @@ Geographically Distributed Sets
 -------------------------------
 
 A geographically distributed replica set provides data recovery should
-the primary data center fail.
-
-A geographically distributed set includes at least one member in a
+one data center fail. These sets include at least one member in a
 secondary data center. The member has its the :data:`priority
 <members[n].priority>` :ref:`set <replica-set-reconfiguration-usage>` to
 ``0`` to prevent the member from ever becoming primary.
@@ -89,10 +88,10 @@ In many circumstances, these deployments consist of the following:
   This member can become the primary member at any time.
 
 - One secondary member in a secondary data center. This member is
-  ineligible to become primary. Its :data:`members[n].priority` value is
-  set to ``0``.
+  ineligible to become primary. Set its :data:`members[n].priority` to
+  ``0``.
 
-If the primary member should fail, the replica set elects a new primary
+If the primary is unavailable, the replica set will elect a new primary
 from the primary data center.
 
 If the *connection* between the primary and secondary data centers fails,
@@ -104,8 +103,8 @@ from the secondary data center. With proper :term:`write concern` there
 will be no data loss and downtime can be minimal.
 
 When you add a secondary data center, make sure to keep an odd number of
-members overall to prevent ties during elections for primary. This can
-be done by deploying an :ref:`arbiter <replica-set-arbiters>` in your
+members overall to prevent ties during elections for primary by
+deploying an :ref:`arbiter <replica-set-arbiters>` in your
 primary data center. For example, if you have three members in the
 primary data center and add a member in a secondary center, you create
 an even number. To create an odd number and prevent ties, deploy an
@@ -175,18 +174,19 @@ Delayed Replication
 ~~~~~~~~~~~~~~~~~~~
 
 :term:`Delayed members <delayed member>` are special :program:`mongod`
-instances in a :term:`replica set` that function the same way as
-:term:`secondary` members with the following operational differences:
-they are not eligible for election to primary and do not receive
-secondary queries. Delayed members *do* vote in :term:`elections
-<election>` for primary.
-
-Delayed members apply operations from the :term:`oplog` on a delay to
+instances in a :term:`replica set` that
+apply operations from the :term:`oplog` on a delay to
 provide a running "historical" snapshot of the data set, or a rolling
 backup. Typically these members provide protection against human error,
 such as unintentionally deleted databases and collections or failed
 application upgrades or migrations.
 
+Otherwise, delayed member function identically to
+:term:`secondary` members, with the following operational differences:
+they are not eligible for election to primary and do not receive
+secondary queries. Delayed members *do* vote in :term:`elections
+<election>` for primary.
+
 See :ref:`Replica Set Delayed Nodes <replica-set-delayed-members>` for
 more information about configuring delayed replica set members.
 
@@ -237,8 +237,8 @@ primary *and* a quorum of voting members in the main facility.
 
 .. _replica-set-arbiter-nodes:
 
-Arbiter Nodes
--------------
+Arbiters
+--------
 
 Always deploy an :term:`arbiter` to ensure that a replica set will have
 a sufficient number of members to elect a :term:`primary`. While having
@@ -258,6 +258,6 @@ resource requirements and do not require dedicated hardware. Do not add
 an arbiter to a set if you have an odd number of voting members that hold
 data, to prevent tied :term:`elections <election>`.
 
-.. seealso:: :ref:`Arbiter Nodes <replica-set-arbiters>`,
+.. seealso:: :ref:`Arbiters <replica-set-arbiters>`,
    :setting:`replSet`, :option:`mongod --replSet`, and
-   :func:`rs.addArb()`.
+   :func:`rs.addArb()`.

source/core/replication-internals.txt

@@ -45,7 +45,7 @@ database remains consistent. However, clients may modify the
 :ref:`read preferences <replica-set-read-preference>` on a
 per-connection basis in order to distribute read operations to the
 :term:`secondary` members of a :term:`replica set`. Read-heavy deployments may achieve
-greater query volumes by distributing reads to secondary members. But
+greater query throughput by distributing reads to secondary members. But
 keep in mind that replication is asynchronous; therefore, reads from
 secondaries may not always reflect the latest writes to the
 :term:`primary`. See the :ref:`consistency <replica-set-consistency>`
@@ -146,7 +146,7 @@ conditions:
 
 - If the member seeking an election is not a member of the voter's set.
 
-- If the member seeking an election is not up-to_date with the most
+- If the member seeking an election is not up-to-date with the most
   recent operation accessible in the replica set.
 
 - If the member seeking an election has a lower priority than another member
@@ -194,17 +194,17 @@ aware of the following conditions and possible situations:
 
 
 .. seealso:: :ref:`Non-voting members in a replica
-             set<replica-set-non-voting-members>`,
+             set <replica-set-non-voting-members>`,
              :ref:`replica-set-node-priority-configuration`, and
-             :data:`replica configuration <members[n].votes>`
+             :data:`replica configuration <members[n].votes>`.
 
 Syncing
 -------
 
 In order to remain up-to-date with the current state of the :term:`replica set`,
 set members sync, or copy, :term:`oplog` entries from other members.
 
-When a new member joins a set or when an existing member restarts, the
+When a new member joins a set or an existing member restarts, the
 member waits to receive heartbeats from other members. By
 default, the member syncs from the *the closest* member of the
 set that is either the primary or another secondary with more recent