diff --git a/source/administration/replica-set-deployment.txt b/source/administration/replica-set-deployment.txt index 0bc4ad414d8..846cb1114a2 100644 --- a/source/administration/replica-set-deployment.txt +++ b/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 diff --git a/source/administration/replica-set-member-configuration.txt b/source/administration/replica-set-member-configuration.txt index d8248f5c990..7f0302bd398 100644 --- a/source/administration/replica-set-member-configuration.txt +++ b/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` diff --git a/source/core/replica-set-arbiter.txt b/source/core/replica-set-arbiter.txt index 0185143c187..4d3568fd016 100644 --- a/source/core/replica-set-arbiter.txt +++ b/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 `. An arbiter has exactly ``1`` election vote. diff --git a/source/core/replica-set-architectures.txt b/source/core/replica-set-architectures.txt index d8e86438708..7be9a6169eb 100644 --- a/source/core/replica-set-architectures.txt +++ b/source/core/replica-set-architectures.txt @@ -17,7 +17,7 @@ The architecture of a :term:`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 ` 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. diff --git a/source/core/replica-set-delayed-member.txt b/source/core/replica-set-delayed-member.txt index 232ab83c7c0..a2e55396eb3 100644 --- a/source/core/replica-set-delayed-member.txt +++ b/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 ` for primary, if :rsconf:`members[n].votes` is set to 1. +- *Do* vote in :term:`elections ` for primary, if :rsconf:`members[n].votes` is set to 1. Behavior ~~~~~~~~ diff --git a/source/core/replica-set-hidden-member.txt b/source/core/replica-set-hidden-member.txt index 2563f872925..a93c0d6d2d2 100644 --- a/source/core/replica-set-hidden-member.txt +++ b/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: \ <\>`. 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` diff --git a/source/core/replica-set-members.txt b/source/core/replica-set-members.txt index e82e6485436..72d3abf7ace 100644 --- a/source/core/replica-set-members.txt +++ b/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 diff --git a/source/includes/extracts-4.2-changes.yaml b/source/includes/extracts-4.2-changes.yaml index 4c52f5ab9d9..fe1223dc0b7 100644 --- a/source/includes/extracts-4.2-changes.yaml +++ b/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 diff --git a/source/tutorial/rotate-encryption-key.txt b/source/tutorial/rotate-encryption-key.txt index 4d61c7f0bea..fb3eac1a598 100644 --- a/source/tutorial/rotate-encryption-key.txt +++ b/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: