Edits for disaster recovery, from the previous PR #104 (#109)

* Edits for the previous PR

* Edit

Author: JuliaMongo

source/disaster-recovery.txt

@@ -66,7 +66,7 @@ Use an Odd Number of Replica Set Members
 To elect a :manual:`primary </core/replica-set-members>`, you need a majority of :manual:`voting </core/replica-set-elections>` replica set members available. We recommend that you create replica sets with an
 odd number of voting replica set members. There is no benefit in having
 an even number of voting replica set members. |service| satisfies this
-requirement by default, as |service| requires having 3,5, or 7 nodes.
+requirement by default, as |service| requires having 3, 5, or 7 nodes.
 
 Fault tolerance is the number of replica set members that can become
 unavailable with enough members still available for a primary election. 
@@ -91,7 +91,7 @@ availability zones. This way you can have multiple separate physical data
 centers, each in its own availability zone and in the same region.
 
 This section aims to illustrate the need for a deployment with five data centers.
-To begin, we will consider deployments with two and three data centers first.
+To begin, consider deployments with two and three data centers.
 
 Consider the following diagram, which shows data distributed across
 two data centers:
@@ -129,8 +129,8 @@ automatically when you deploy a dedicated cluster to a region that supports avai
 availability zones. For example, for a three-node replica set {+cluster+} deployed to a three-availability-zone region, {+service+} deploys one node
 in each zone. A local failure in the data center hosting one node doesn't
 impact the operation of data centers hosting the other nodes because MongoDB
-performs automatic failover and leader election. Applications will
-automatically recover in the event of local failures.
+performs automatic failover and leader election. Applications automatically
+recover in the event of local failures.
 
 We recommend that you deploy replica sets to the following regions because they support at least three availability zones:
 
@@ -155,8 +155,8 @@ Use ``mongos`` Redundancy for Sharded {+Clusters+}
 When a client connects to a sharded {+cluster+}, we recommend that you include multiple :manual:`mongos </reference/program/mongos/>`
 processes, separated by commas, in the connection URI. To learn more,
 see :manual:`MongoDB Connection String Examples </reference/connection-string-examples/#self-hosted-replica-set-with-members-on-different-machines>`.
-This allows operations to route to different ``mongos`` instances for load
-balancing, but it is also important for disaster recovery. 
+This setup allows operations to route to different ``mongos`` instances
+for load balancing, but it is also important for disaster recovery.
 
 Consider the following diagram, which shows a sharded {+cluster+}
 spread across three data centers. The application connects to the {+cluster+} from a remote location. If Data Center 3 becomes unavailable, the application can still connect to the ``mongos``
@@ -250,9 +250,9 @@ Ensure that you perform MongoDB major version upgrades far before your
 current version reaches `end of life <https://www.mongodb.com/legal/support-policy/lifecycles>`__. 
 
 You can't downgrade your MongoDB version using the {+atlas-ui+}. Because of this,
-we recommend that you work directly with MongoDB Professional or Technical Services
-when planning and executing a major version upgrade. This will help you avoid
-any issues that might occur during the upgrade process.
+when planning and executing a major version upgrade, we recommend that you
+work directly with MongoDB Professional or Technical Services to help you
+avoid any issues that might occur during the upgrade process.
 
 Disaster Recovery Recommendations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -348,7 +348,7 @@ unavailable, follow these steps to bring your deployment back online:
 
    .. step:: Determine when the cloud provider outage began. 
 
-      You will need this information later in this procedure to restore your deployment.
+      You need this information later in this procedure to restore your deployment.
 
    .. step:: Identify the alternative cloud provider you would like to deploy your new {+cluster+} on
 
@@ -374,7 +374,7 @@ unavailable, follow these steps to bring your deployment back online:
    .. step:: Switch any applications that connect to the old {+cluster+} to the newly-created {+cluster+}
 
       To find the new connection string, see :atlas:`Connect via Drivers </driver-connection>`.
-      Review your application stack as you will likely need to redeploy it onto the new cloud provider.
+      Review your application stack as you likely need to redeploy it onto the new cloud provider.
 
 .. _arch-center-atlas-outage:
 
@@ -383,7 +383,7 @@ unavailable, follow these steps to bring your deployment back online:
 
 In the highly unlikely event that the {+service+} Control Plane and
 the {+atlas-ui+} are unavailable, your {+cluster+} is still available and accessible.
-To lear more, see `Platform Reliability <https://www.mongodb.com/products/platform/trust#reliability>`__.
+To learn more, see `Platform Reliability <https://www.mongodb.com/products/platform/trust#reliability>`__.
 Open a high-priority :atlas:`support ticket </support/#request-support>`
 to investigate this further.
 
@@ -450,10 +450,9 @@ Deletion of Production Data
 
 Production data might be accidentally deleted due to human error or a bug
 in the application built on top of the database.
-If the cluster itself was accidentally deleted, Atlas may have retained
+If the cluster itself was accidentally deleted, Atlas might retain
 the volume temporarily.
 
-
 If the contents of a collection or database have been deleted, follow these steps to restore your data:
 
 .. procedure::