Fix typos in replication section

Author: npentrel

source/administration/replica-set-deployment.txt

@@ -10,7 +10,7 @@ Replica Set Deployment Tutorials
    :depth: 1
    :class: singlecol
 
-The following tutorials provide information in deploying replica sets.
+The following tutorials provide information on deploying replica sets.
 
 .. class:: toc
 

source/administration/replica-set-member-configuration.txt

@@ -10,7 +10,7 @@ Member Configuration Tutorials
    :depth: 1
    :class: singlecol
 
-The following tutorials provide information in configuring replica set
+The following tutorials provide information on configuring replica set
 members to support specific operations, such as to provide dedicated
 backups, to support reporting, or to act as a cold standby.
 
@@ -21,7 +21,7 @@ backups, to support reporting, or to act as a cold standby.
 .. class:: toc
 
    :doc:`/tutorial/adjust-replica-set-member-priority`
-      Change the precedence given to a replica set members in an
+      Change the precedence given to a replica set member in an
       election for primary.
 
    :doc:`/tutorial/configure-secondary-only-replica-set-member`

source/core/replica-set-arbiter.txt

@@ -18,7 +18,7 @@ Replica Set Arbiter
 In some circumstances (such as you have a primary and a secondary but
 cost constraints prohibit adding another secondary), you may choose to
 add an arbiter to your replica set. An arbiter does **not** have a copy
-of data set and **cannot** become a primary. However, an arbiter
+of the data set and **cannot** become a primary. However, an arbiter
 participates in :ref:`elections for primary <replica-set-elections>`.
 An arbiter has exactly ``1`` election vote.
 

source/core/replica-set-architectures.txt

@@ -17,7 +17,7 @@ The architecture of a :term:`replica set <replica set>` affects the
 set's capacity and capability. This document provides strategies for
 replica set deployments and describes common architectures.
 
-The standard replica set deployment for production system is a
+The standard replica set deployment for a production system is a
 three-member replica set. These sets provide redundancy and fault
 tolerance. Avoid complexity when possible, but let your application
 requirements dictate the architecture.
@@ -50,7 +50,7 @@ if constraints prohibit against another data bearing voting member, an
 
 An :term:`arbiter <arbiter>` does not store a copy of the data and
 requires fewer resources. As a result, you may run an arbiter on an
-application server or other shared process. With no copy of the data,
+application server or other shared resource. With no copy of the data,
 it may be possible to place an arbiter into environments that you would
 not place other members of the replica set. Consult your security
 policies.

source/core/replica-set-delayed-member.txt

@@ -43,7 +43,7 @@ Delayed members:
   members. Always prevent applications from seeing and querying
   delayed members.
 
-- *do* vote in :term:`elections <election>` for primary, if :rsconf:`members[n].votes` is set to 1.
+- *Do* vote in :term:`elections <election>` for primary, if :rsconf:`members[n].votes` is set to 1.
 
 Behavior
 ~~~~~~~~

source/core/replica-set-hidden-member.txt

@@ -61,7 +61,7 @@ Write Concern
 
 Hidden replica set members can acknowledge write operations issued
 with :writeconcern:`w: \<number\> <\<number\>>`. For write operations
-isued with :writeconcern:`w : "majority" <"majority">`, however,
+issued with :writeconcern:`w : "majority" <"majority">`, however,
 hidden members must also be voting members (i.e. :rsconf:`members[n].votes`
 greater than ``0``) to acknowledge the ``"majority"`` write operation.
 Non-voting replica set members (i.e. :rsconf:`members[n].votes` 

source/core/replica-set-members.txt

@@ -14,10 +14,10 @@ A *replica set* in MongoDB is a group of :binary:`~bin.mongod` processes
 that provide redundancy and high availability. The members of a
 replica set are:
 
-:ref:`replica-set-primary-member`.
+:ref:`replica-set-primary-member`
    The primary receives all write operations.
 
-:ref:`replica-set-secondary-members`.
+:ref:`replica-set-secondary-members`
    Secondaries replicate operations from the primary to maintain an
    identical data set. Secondaries may have additional configurations
    for special usage profiles. For example, secondaries may be

source/includes/extracts-4.2-changes.yaml

@@ -618,7 +618,7 @@ content: |
    With flow control enabled, as the lag grows close to the
    :parameter:`flowControlTargetLagSeconds`, writes on the primary must obtain
    tickets before taking locks to apply writes. By limiting the number of
-   tickets issued per second, the flow control mechanism attempts to keep the 
+   tickets issued per second, the flow control mechanism attempts to keep 
    the lag under the target.
 ---
 ref: 4.2-changes-extended-json-v2

source/tutorial/rotate-encryption-key.txt

@@ -26,8 +26,8 @@ MongoDB provides two options for key rotation. You can rotate out the
 binary with a new instance that uses a new key. Or, if you are using a
 KMIP server for key management, you can rotate the master key.
 
-Rotate a Member of Replica Set
-------------------------------
+Rotate a Replica Set Member
+---------------------------
 
 For a replica set, to rotate out a member: