completed 'Failover and Recovery'; small changes; added a TODO

Author: gwaldo

source/administration/replica-sets.txt

@@ -570,15 +570,15 @@ Possible causes of replication lag include:
 Failover and Recovery
 ~~~~~~~~~~~~~~~~~~~~~
 
-In most cases, failover occurs with out administrator intervention
-seconds after the :term:`primary` steps down or becomes inaccessible
-and ineligible to act as primary. If your MongoDB deployment does not
-failover according to expectations, consider the following operational
-errors:
+In most cases, failover occurs without administrator intervention
+seconds after the :term:`primary` steps down, becomes inaccessible,
+or otherwise ineligible to act as primary. If your MongoDB deployment 
+does not failover according to expectations, consider the following 
+operational errors:
 
 - No remaining member is able to form a majority. This can happen as a
-  result of network portions that render some members
-  inaccessible. Architect your deployment to ensure that a majority of
+  result of network partitions that render some members
+  inaccessible. Design your deployment to ensure that a majority of
   set members can elect a primary in the same facility as core
   application systems.
 
@@ -599,6 +599,9 @@ were never replicated to the set so that the data set is in a
 consistent state. The :program:`mongod` program writes rolled back
 data to a :term:`BSON`.
 
+.. a *what*?  TODO: Clarify what is meant by "program writes rolled
+.. back data to a BSON"
+
 You can prevent rollbacks prevented by ensuring safe writes by using
 the appropriate :term:`write concern`.