Merge pull request #544 from bgrabar/secondaries-154

DOCS-154 DOCS-816 add 2.2 replica set behaviors

Author: Ed Costello

source/administration/replica-sets.txt

@@ -556,6 +556,30 @@ resource requirements and do not require dedicated hardware.
 
       rs.addArb("m1.example.net:30000")
 
+.. _replica-set-configure-sync-target:
+
+Manually Configure a Secondary's Sync Target
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To override the default selection logic, if needed, and to manually
+configure a :term:`secondary` member's sync target for pulling
+:term:`oplog` entries, use either of the following commands. If you want
+your choice to affect the initial sync, run the command *before* initial
+sync. Always exercise caution when overriding the default behavior:
+
+- :dbcommand:`replSetSyncFrom` command
+
+- :method:`rs.syncFrom()` helper in the :program:`mongo` shell
+
+These commands do not work *during* initial sync. To affect initial
+sync, you must specify a target *before* initial sync starts.
+If you run one of the commands during initial sync, no error message
+appears, but the sync target does not change until initial sync completes.
+
+These commands provide a temporary override of default behavior. The
+change does not persist if the :program:`mongod` instance or the sync
+socket closes.
+
 .. _replica-set-procedure-change-oplog-size:
 
 Changing Oplog Size

source/core/replication-internals.txt

@@ -261,17 +261,17 @@ set members sync, or copy, :term:`oplog` entries from other members.
 When a new member joins a set or an existing member restarts, the
 member waits to receive heartbeats from other members. By
 default, the member syncs from the *the closest* member of the
-set that is either the primary or another secondary with more recent
-oplog entries. This prevents two secondaries from syncing from each other.
+set that is either the primary or another :term:`secondary` with more recent
+oplog entries.
 
 In version 2.0, secondaries only change sync targets if the connection
-between secondaries drops or produces an error.
+to the sync target drops or produces an error.
 
 For example:
 
 #. If you have two secondary members in one data center and a primary in
    a second facility, and if you start all three instances at roughly
-   the same time (i.e. with no existing data sets or oplog,) both
+   the same time (i.e. with no existing data sets or oplog), both
    secondaries will likely sync from the primary, as neither secondary
    has more recent oplog entries.
 
@@ -283,4 +283,28 @@ For example:
    facility, the new secondary will likely sync from the existing
    secondary because it is closer than the primary.
 
-.. seealso:: :ref:`replica-set-resync-stale-member`
+In version 2.2, secondaries also use the following additional sync
+behaviors:
+
+- Secondaries will sync from :ref:`delayed members
+  <replica-set-delayed-members>` *only* if no other member is available.
+
+- Secondaries will *not* sync from :ref:`hidden members
+  <replica-set-hidden-members>`.
+
+- Secondaries will *not* start syncing from a member in a
+  :term:`recovering` state.
+
+- For one member to sync from another, both members must have the same
+  value, either ``true`` or ``false``, for the
+  :data:`members[n].buildIndexes` field.
+
+Pre-Fetching Indexes to Improve Replication Throughput
+------------------------------------------------------
+
+By default, secondaries will in most cases pre-fetch :ref:`indexes`
+associated with the affected document to improve replication throughput.
+
+You can limit this feature to pre-fetch only the index on the ``_id``
+field, or you can disable this feature entirely. For more information,
+see :setting:`replIndexPrefetch`.

source/reference/command/replSetSyncFrom.txt

@@ -30,6 +30,11 @@ replSetSyncFrom
    behind the current member, :program:`mongod` will return and log a
    warning, but *will* sync from such members.
 
+   If you attempt to change a member's sync target *during* initial
+   sync, the change will not take effect until initial sync completes.
+   No error message appears, but the sync target does not change until
+   after initial sync.
+
    The command has the following prototype form:
 
    .. code-block:: javascript

source/release-notes/2.2.txt

@@ -666,6 +666,8 @@ identify what process may produce errors or halt replication. See
 Replica Set Members can Sync from Specific Members
 ``````````````````````````````````````````````````
 
+.. the following has been copied to source/administration/replica-sets.txt
+
 The new :dbcommand:`replSetSyncFrom` command and new
 :method:`rs.syncFrom()` helper in the :program:`mongo` shell make it
 possible for you to manually configure from which member of the set a
@@ -677,6 +679,8 @@ behavior.
 Replica Set Members will not Sync from Members Without Indexes Unless ``buildIndexes: false``
 `````````````````````````````````````````````````````````````````````````````````````````````
 
+.. the following has been copied to source/core/replication-internals.txt
+
 To prevent inconsistency between members of replica sets, if the
 member of a replica set has :data:`members[n].buildIndexes` set to
 ``true``, other members of the replica set will *not* sync from this
@@ -686,6 +690,8 @@ member, unless they also have :data:`members[n].buildIndexes` set to
 New Option To Configure Index Pre-Fetching during Replication
 `````````````````````````````````````````````````````````````
 
+.. the following has been copied to source/core/replication-internals.txt
+
 By default, when replicating options, :term:`secondaries <secondary>`
 will pre-fetch :ref:`indexes` associated with a query to improve replication
 throughput in most cases. The :setting:`replIndexPrefetch` setting and