minor edits: replica set read preference article

Author: Sam Kleinman

source/applications/replication.txt

@@ -67,7 +67,7 @@ for a replica set. Use the :data:`settings.getLastErrorDefaults` setting
 in the :doc:`replica set configuration
 </reference/replica-configuration>`. The following sequence of commands
 creates a configuration that waits for the write operation to complete
-on a majority of the set members before returning:
+on a majority of the set members beforBe returning:
 
 .. code-block:: javascript
 
@@ -172,8 +172,7 @@ read preference modes:
 
 You can specify a read preference mode on connection objects, database object,
 collection object, or per-operation. The syntax for specifying the read
-preference mode is :api:`specific to the driver and to the idioms of the host
-language <>`.
+preference mode is :api:`specific to the driver and to the idioms of the host language <>`.
 
 Read preference modes are also available to clients connecting to a
 :term:`sharded cluster` through a :program:`mongos`. The
@@ -525,8 +524,8 @@ for more information.
 
 .. [#acceptable-secondary-latency] Applications can configure the
    threshold used in this stage. The default "acceptable latency" is
-   15 milliseconds, which you can override in the drivers with the
-   `secondaryAcceptableLatencyMS` option.
+   15 milliseconds, which you can override in the drivers with their own
+   ``secondaryAcceptableLatencyMS`` option.
    For :program:`mongos` you can use the
    :option:`--localThreshold <mongos --localThreshold>` or
    :setting:`localThreshold` runtime options to set this value.
@@ -614,22 +613,11 @@ using non-:readmode:`primary` read preference modes:
 - Reporting and analytics workloads.
 
   Having these queries target a :term:`secondary` helps distribute
-  load and prevent these operations from affecting the primary
-  workload of the primary.
+  load and prevent these operations from affecting the main workload
+  of the primary.
 
   Also consider using :readmode:`secondary` in conjunction with a
-  direct connection to a :ref:`hidden member
-  <replica-set-hidden-members>` of the set.
-
-.. warning::
-
-  Although it is tempting to use :readmode:`secondaryPreferred` to distribute
-  load, if your primary cannot accept your full read load, then
-  using :readmode:`secondaryPreferred` is dangerous: if all secondaries
-  become unavailable, but you have enough arbiters to prevent the primary from
-  stepping down, then this mode will redirect traffic to the primary. For this
-  reason, use :readmode:`secondary` to distribute load,
-  not :readmode:`secondaryPreferred`.
+  direct connection to a :ref:`hidden member <replica-set-hidden-members>` of the set.
 
 - Providing local reads for geographically distributed applications.
 
@@ -642,9 +630,21 @@ using non-:readmode:`primary` read preference modes:
 - Maintaining availability during a failover.
 
   Use :readmode:`primaryPreferred` if you want your application to do
-  consistent reads from the primary under normal circumstances, but to allow
-  stale reads from secondaries in an emergency. This provides a "read-only mode"
-  for your application during a failover.
+  consistent reads from the primary under normal circumstances, but to
+  allow stale reads from secondaries in an emergency. This provides a
+  "read-only mode" for your application during a failover.
+
+.. warning::
+
+   In some situations using :readmode:`secondaryPreferred` to
+   distribute read load to replica sets may carry significant
+   operational risk: if all secondaries are unavailable and your set
+   has enough :term:`arbiters <arbiter>` to prevent the primary from
+   stepping down, then the primary will receive all traffic from
+   clients.
+
+   For this reason, use :readmode:`secondary` to distribute read load
+   to replica sets, not :readmode:`secondaryPreferred`.
 
 Using read modes other than :readmode:`primary` and
 :readmode:`primaryPreferred` to provide extra capacity is not in and