From f6519844ce7efcb56f8e72e56818ef4bd4aa48e0 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 27 Sep 2012 14:24:18 -0400 Subject: [PATCH 1/5] DOCS-561 & DOCS-551 reconfig repl set when members down: draft 1 --- source/administration/replica-sets.txt | 1 + source/core/replication-internals.txt | 1 - .../list-administration-tutorials.rst | 15 ++-- source/reference/replica-configuration.txt | 4 +- source/replication.txt | 3 + ...gure-replica-set-when-members-are-down.txt | 84 +++++++++++++++++++ 6 files changed, 99 insertions(+), 9 deletions(-) create mode 100644 source/tutorial/reconfigure-replica-set-when-members-are-down.txt diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index 6a22c3128f2..98c808b4729 100644 --- a/source/administration/replica-sets.txt +++ b/source/administration/replica-sets.txt @@ -32,6 +32,7 @@ suggestions for administers of replica sets. - :doc:`/tutorial/force-member-to-be-primary` - :doc:`/tutorial/change-hostnames-in-a-replica-set` - :doc:`/tutorial/convert-secondary-into-arbiter` + - :doc:`/tutorial/reconfigure-replica-set-when-members-are-down.txt` .. _replica-set-node-configurations: .. _replica-set-member-configurations: diff --git a/source/core/replication-internals.txt b/source/core/replication-internals.txt index a320e8a640f..de9c8f2d849 100644 --- a/source/core/replication-internals.txt +++ b/source/core/replication-internals.txt @@ -297,7 +297,6 @@ and a majority of servers in one data center and one server in another. .. index:: replica set; sync - Syncing ------- diff --git a/source/includes/list-administration-tutorials.rst b/source/includes/list-administration-tutorials.rst index ca5e889554e..f031cf264de 100644 --- a/source/includes/list-administration-tutorials.rst +++ b/source/includes/list-administration-tutorials.rst @@ -3,12 +3,15 @@ - :doc:`tutorial/install-mongodb-on-os-x` - :doc:`tutorial/install-mongodb-on-debian-or-ubuntu-linux` - :doc:`tutorial/install-mongodb-on-windows` -- :doc:`tutorial/change-oplog-size` -- :doc:`tutorial/deploy-replica-set` -- :doc:`tutorial/deploy-geographically-distributed-replica-set` -- :doc:`tutorial/expand-replica-set` -- :doc:`tutorial/change-hostnames-in-a-replica-set` -- :doc:`tutorial/convert-secondary-into-arbiter` +- :doc:`/tutorial/deploy-replica-set` +- :doc:`/tutorial/convert-standalone-to-replica-set` +- :doc:`/tutorial/expand-replica-set` +- :doc:`/tutorial/deploy-geographically-distributed-replica-set` +- :doc:`/tutorial/change-oplog-size` +- :doc:`/tutorial/force-member-to-be-primary` +- :doc:`/tutorial/change-hostnames-in-a-replica-set` +- :doc:`/tutorial/convert-secondary-into-arbiter` +- :doc:`/tutorial/reconfigure-replica-set-when-members-are-down.txt` - :doc:`tutorial/recover-data-following-unexpected-shutdown` - :doc:`tutorial/deploy-shard-cluster` - :doc:`tutorial/convert-replica-set-to-replicated-shard-cluster` diff --git a/source/reference/replica-configuration.txt b/source/reference/replica-configuration.txt index 8e68a65ab46..ff7587b8014 100644 --- a/source/reference/replica-configuration.txt +++ b/source/reference/replica-configuration.txt @@ -255,8 +255,8 @@ all optional fields. .. _replica-set-reconfiguration-usage: -Use ---- +Example Reconfiguration Operations +---------------------------------- Most modifications of :term:`replica set` configuration use the :program:`mongo` shell. Consider the following reconfiguration diff --git a/source/replication.txt b/source/replication.txt index 706c7a87570..9ec56296e4b 100644 --- a/source/replication.txt +++ b/source/replication.txt @@ -41,6 +41,8 @@ operations in detail: .. Updates to this tutorial list should also be made in source/administration/replica-sets.txt + and if appropriate in + source/includes/list-administration-tutorials.rst .. toctree:: :maxdepth: 1 @@ -53,6 +55,7 @@ operations in detail: tutorial/force-member-to-be-primary tutorial/change-hostnames-in-a-replica-set tutorial/convert-secondary-into-arbiter + tutorial/reconfigure-replica-set-when-members-are-down .. _replication-reference: diff --git a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt new file mode 100644 index 00000000000..8eebf7d9ef8 --- /dev/null +++ b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt @@ -0,0 +1,84 @@ +=============================================== +Reconfigure a Replica Set when Members are Down +=============================================== + +.. default-domain:: mongodb + +If members are down and you want to reconfigure your replica set, use +the procedures described here. + + +Reconfigure When a Majority of Members are Running +-------------------------------------------------- + +To reconfigure :term:`replica set` when a minority of members is down +and a majority of members are still up, send the :method:`rs.reconfig()` +command to the current :term:`primary`. For examples of using +:method:`rs.reconfig()`, see +:ref:`replica-set-reconfiguration-usage`. + +Reconfigure When a Majority of Members are Down +----------------------------------------------- + +To reconfigure a replica set when the majority of members are down or +unreachable, you must manually change the set configuration. + +This includes situations where you have a network partition and where +neither side of the partition has a majority. In such cases the two +sides of the partition cannot see each other when determining whether a +majority exists (see +:ref:`replica-set-elections-and-network-partitions`). Therefore, do not +use scripts to reconfigure but do so manually. + +This section gives several procedures for reconfiguring when a majority +is down. Use the procedure appropriate to your version and situation. + +Reconfigure Using the Force : True Option +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. versionchanged:: 2.0 + +In v2.0+, the ``force : true`` option was added for reconfiguring the +set when a majority is down. The ``force : true`` option manually +reconfigures the set when there is a serious problem, such as a disaster +recovery failover. Do not use ``force : true`` every time you +reconfigure. Also, do not put ``force : true`` into a script that +automatically runs, and do not use it when there is still a primary. + +If you use force and look at your replica set config, you will notice +that your version number has jumped a lot (by tens or hundreds of +thousands). This is normal and designed to prevent set version +collisions if network partitioning ends. + +Recover when a majority of nodes are down or on the wrong side of a +network partition. + +Connect to a surviving member (any one is fine) and "force" a +reconfiguration of the set without the down hosts. + +#. Consider doing a backup on a surviving member, both for safety and to + bring up more new set members more easily. + +#. Save the current config somewhere so that you can switch back to the + old configuration once the down/unreachable members are healed. + + .. code-block:: javascript + + config = rs.config() + printjson(config) # store this somewhere + +#. Remove the down members from the config.members array. + Remove the unreachable members of the set. Consider the following + example: + + .. code-block:: javascript + + config.members = [config.members[1], config.members[3], config.members[4]] + +#. Reconfigure the set by issuing the using the :dbcommand:`compact` + command with the ``force: true`` parameter on the surviving member. + + .. code-block:: javascript + + db.runCommand ( { compact: '', force: true } ) + From bd42f6aa1715d9594230006a556166cc6291b182 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 27 Sep 2012 15:53:19 -0400 Subject: [PATCH 2/5] DOCS-561 & DOCS-551 reconfig repl set when members down: draft 2 --- ...gure-replica-set-when-members-are-down.txt | 117 +++++++++++------- 1 file changed, 70 insertions(+), 47 deletions(-) diff --git a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt index 8eebf7d9ef8..fe81374139d 100644 --- a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt +++ b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt @@ -4,24 +4,8 @@ Reconfigure a Replica Set when Members are Down .. default-domain:: mongodb -If members are down and you want to reconfigure your replica set, use -the procedures described here. - - -Reconfigure When a Majority of Members are Running --------------------------------------------------- - -To reconfigure :term:`replica set` when a minority of members is down -and a majority of members are still up, send the :method:`rs.reconfig()` -command to the current :term:`primary`. For examples of using -:method:`rs.reconfig()`, see -:ref:`replica-set-reconfiguration-usage`. - -Reconfigure When a Majority of Members are Down ------------------------------------------------ - -To reconfigure a replica set when the majority of members are down or -unreachable, you must manually change the set configuration. +To reconfigure a :term:`replica set` when a majority of the members are +down or unreachable, you must manually change the set configuration. This includes situations where you have a network partition and where neither side of the partition has a majority. In such cases the two @@ -33,52 +17,91 @@ use scripts to reconfigure but do so manually. This section gives several procedures for reconfiguring when a majority is down. Use the procedure appropriate to your version and situation. -Reconfigure Using the Force : True Option -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. note:: To reconfigure a replica set when a majority of members are + running, run the :method:`rs.reconfig()` command on the current + :term:`primary`. For examples of using :method:`rs.reconfig()`, see + :ref:`replica-set-reconfiguration-usage`. + +Force a Reconfiguration when the Primary is Down +------------------------------------------------ .. versionchanged:: 2.0 -In v2.0+, the ``force : true`` option was added for reconfiguring the -set when a majority is down. The ``force : true`` option manually -reconfigures the set when there is a serious problem, such as a disaster -recovery failover. Do not use ``force : true`` every time you -reconfigure. Also, do not put ``force : true`` into a script that -automatically runs, and do not use it when there is still a primary. +This procedure lets you recover while a majority of :term:`replica set` +members are down or unreachable. A member might be unreachable, for +example, if it is on the wrong side of a network partition. + +.. TODO Question: must the primary be down for you to use this procedure? + +You connect to any surviving member and use the the ``force : true`` +option to force a reconfiguration of the replica set. + +The ``force : true`` option manually reconfigures the set. The option is +intended only for serious problems, such as a disaster recovery +failover. Do not use ``force : true`` every time you reconfigure. Also, +do not put ``force : true`` into any automatic scripts and do not use +``force : true`` when there is still a primary. -If you use force and look at your replica set config, you will notice -that your version number has jumped a lot (by tens or hundreds of -thousands). This is normal and designed to prevent set version -collisions if network partitioning ends. +To force reconfiguration: -Recover when a majority of nodes are down or on the wrong side of a -network partition. +1. Back up a surviving member, both for safety and to bring up more new + set members more easily. -Connect to a surviving member (any one is fine) and "force" a -reconfiguration of the set without the down hosts. +#. Connect to any surviving member and save the current configuration + so that you can switch back to the old configuration once the members + are restored. Consider the following example commands for saving the + configuration: -#. Consider doing a backup on a surviving member, both for safety and to - bring up more new set members more easily. + .. code-block:: javascript + + cfg = rs.config() + + printjson(cfg) -#. Save the current config somewhere so that you can switch back to the - old configuration once the down/unreachable members are healed. +#. On the same member, remove the down and unreachable members of the + replica set from the :data:`members ` array by + setting the array equal to the surviving members alone. Consider the + following example, which uses the ``cfg`` variable created in the + previous step: .. code-block:: javascript - config = rs.config() - printjson(config) # store this somewhere + cfg.members = [cfg.members[0] , cfg.members[4] , cfg.members[7]] -#. Remove the down members from the config.members array. - Remove the unreachable members of the set. Consider the following - example: +#. On the same member, reconfigure the set by using the + :method:`rs.reconfig()` command with the ``force : true`` option: .. code-block:: javascript - config.members = [config.members[1], config.members[3], config.members[4]] + rs.reconfig(cfg, {force : true}) + + The replica set elects a new primary, most likely the member you are + connected to. + + .. note:: When you use ``force : true``, the version number in the + replica set configuration increases significantly, by tens or + hundreds of thousands. This is normal and designed to prevent set + version collisions if network partitioning ends. -#. Reconfigure the set by issuing the using the :dbcommand:`compact` - command with the ``force: true`` parameter on the surviving member. +#. If the failure or partition was only temporary, then as members + recover they detect that they have been removed from the set and + enter a special state where they are up but refuse to answer + requests, as they are no longer syncing changes. You can now re-add + them to the configuration object: + + Be sure that each member has the same _id it had before. + + .. TODO why does each member have to have the same ID as before? + .. The wiki said they'd have to run rs.reconfig(). Why? + + Consider the following example: .. code-block:: javascript - db.runCommand ( { compact: '', force: true } ) + rs.add("example.com:30003") + + Once you add the removed members back into the set, they detect they + have been added and synchronize to the current state of the set. + Be aware that if the original primary was one of the removed members, + these members may need to rollback. From ec6b2d35b985b1e0c664605d9a63b28e51a29d7a Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 27 Sep 2012 17:15:45 -0400 Subject: [PATCH 3/5] DOCS-561 & DOCS-551 reconfig repl set when members down: draft 3 --- source/administration/replica-sets.txt | 2 +- .../list-administration-tutorials.rst | 2 +- source/release-notes/2.0.txt | 4 +- ...gure-replica-set-when-members-are-down.txt | 147 ++++++++++++------ 4 files changed, 101 insertions(+), 54 deletions(-) diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index 98c808b4729..962998b1936 100644 --- a/source/administration/replica-sets.txt +++ b/source/administration/replica-sets.txt @@ -32,7 +32,7 @@ suggestions for administers of replica sets. - :doc:`/tutorial/force-member-to-be-primary` - :doc:`/tutorial/change-hostnames-in-a-replica-set` - :doc:`/tutorial/convert-secondary-into-arbiter` - - :doc:`/tutorial/reconfigure-replica-set-when-members-are-down.txt` + - :doc:`/tutorial/reconfigure-replica-set-when-members-are-down` .. _replica-set-node-configurations: .. _replica-set-member-configurations: diff --git a/source/includes/list-administration-tutorials.rst b/source/includes/list-administration-tutorials.rst index f031cf264de..829dc6f1c2c 100644 --- a/source/includes/list-administration-tutorials.rst +++ b/source/includes/list-administration-tutorials.rst @@ -11,7 +11,7 @@ - :doc:`/tutorial/force-member-to-be-primary` - :doc:`/tutorial/change-hostnames-in-a-replica-set` - :doc:`/tutorial/convert-secondary-into-arbiter` -- :doc:`/tutorial/reconfigure-replica-set-when-members-are-down.txt` +- :doc:`/tutorial/reconfigure-replica-set-when-members-are-down` - :doc:`tutorial/recover-data-following-unexpected-shutdown` - :doc:`tutorial/deploy-shard-cluster` - :doc:`tutorial/convert-replica-set-to-replicated-shard-cluster` diff --git a/source/release-notes/2.0.txt b/source/release-notes/2.0.txt index 2de1c3b6537..122d8e9524f 100644 --- a/source/release-notes/2.0.txt +++ b/source/release-notes/2.0.txt @@ -219,7 +219,7 @@ Reconfiguration with a Minority Up If the majority of servers in a set has been permanently lost, you can now force a reconfiguration of the set to bring it back online. -See more information see :wiki:`Reconfiguring a replica set when members are down `. +For more information see :doc:`/tutorial/reconfigure-replica-set-when-members-are-down`. Primary Checks for a Caught up Secondary before Stepping Down ````````````````````````````````````````````````````````````` @@ -229,7 +229,7 @@ method will now fail if the primary does not see a :term:`secondary` within 10 seconds of its latest optime. You can force the primary to step down anyway, but by default it will return an error message. -See also :wiki:`Forcing a Member to be Primary `. +See also :doc:`/tutorial/force-member-to-be-primary`. Extended Shutdown on the Primary to Minimize Interruption ````````````````````````````````````````````````````````` diff --git a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt index fe81374139d..903ccfe7bff 100644 --- a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt +++ b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt @@ -4,43 +4,43 @@ Reconfigure a Replica Set when Members are Down .. default-domain:: mongodb -To reconfigure a :term:`replica set` when a majority of the members are -down or unreachable, you must manually change the set configuration. - -This includes situations where you have a network partition and where -neither side of the partition has a majority. In such cases the two -sides of the partition cannot see each other when determining whether a -majority exists (see -:ref:`replica-set-elections-and-network-partitions`). Therefore, do not -use scripts to reconfigure but do so manually. - -This section gives several procedures for reconfiguring when a majority -is down. Use the procedure appropriate to your version and situation. - -.. note:: To reconfigure a replica set when a majority of members are - running, run the :method:`rs.reconfig()` command on the current - :term:`primary`. For examples of using :method:`rs.reconfig()`, see - :ref:`replica-set-reconfiguration-usage`. - -Force a Reconfiguration when the Primary is Down ------------------------------------------------- +To reconfigure a :term:`replica set` when only a *minority* of members +are down or unreachable, run the :method:`rs.reconfig()` command on the +current :term:`primary`. For examples of how to reconfigure a replica +set using :method:`rs.reconfig()`, see +:ref:`replica-set-reconfiguration-usage`. + +To reconfigure a replica set when a *majority* of the members are down +or unreachable, you must manually change the set configuration as +described in the procedures in this tutorial. Use the procedure +appropriate to your version and situation. + +Reconfiguring when a *majority* of members are down can include +situations where you have a network partition and where neither side of +the partition has a majority. In such cases the two sides of the +partition cannot see each other when determining whether a majority +exists (see :ref:`replica-set-elections-and-network-partitions`). In +these situations, never use scripts to reconfigure but instead +reconfigure manually, as described in the procedures here. + +.. index:: replica set; reconfiguration +.. _replica-set-force-reconfiguration: + +Reconfigure by Forcing the Reconfiguration +------------------------------------------ .. versionchanged:: 2.0 This procedure lets you recover while a majority of :term:`replica set` -members are down or unreachable. A member might be unreachable, for -example, if it is on the wrong side of a network partition. - -.. TODO Question: must the primary be down for you to use this procedure? - -You connect to any surviving member and use the the ``force : true`` -option to force a reconfiguration of the replica set. +members are down or unreachable. You connect to any surviving member and +use :method:`rs.reconfig()`'s ``force`` option to force a +reconfiguration of the replica set. -The ``force : true`` option manually reconfigures the set. The option is +The ``force`` option manually reconfigures the set. The option is intended only for serious problems, such as a disaster recovery -failover. Do not use ``force : true`` every time you reconfigure. Also, -do not put ``force : true`` into any automatic scripts and do not use -``force : true`` when there is still a primary. +failover. Do not use ``force`` any time you reconfigure. Also, do not +include ``force`` into any automatic scripts and do not use ``force`` +when there is still a primary. To force reconfiguration: @@ -69,7 +69,8 @@ To force reconfiguration: cfg.members = [cfg.members[0] , cfg.members[4] , cfg.members[7]] #. On the same member, reconfigure the set by using the - :method:`rs.reconfig()` command with the ``force : true`` option: + :method:`rs.reconfig()` command with the ``force`` option set to + ``true``: .. code-block:: javascript @@ -79,29 +80,75 @@ To force reconfiguration: connected to. .. note:: When you use ``force : true``, the version number in the - replica set configuration increases significantly, by tens or - hundreds of thousands. This is normal and designed to prevent set - version collisions if network partitioning ends. + replica set configuration increases significantly, by tens or + hundreds of thousands. This is normal and designed to prevent set + version collisions if network partitioning ends. -#. If the failure or partition was only temporary, then as members - recover they detect that they have been removed from the set and - enter a special state where they are up but refuse to answer - requests, as they are no longer syncing changes. You can now re-add - them to the configuration object: +#. If any of the removed members come back online, there is the chance + they will elect a new primary, resulting in two primaries. To ensure + that the removed members do not elect a new primary, shut down or + decommission the removed members as soon as possible. - Be sure that each member has the same _id it had before. +Reconfigure by Replacing the Replica Set +---------------------------------------- - .. TODO why does each member have to have the same ID as before? - .. The wiki said they'd have to run rs.reconfig(). Why? +The procedures here are intended mainly for MongoDB versions *prior to* +version 2.0. For post-2.0 version, the above procedure, +:ref:`replica-set-force-reconfiguration`, is recommended. - Consider the following example: +These procedures are for situations where a *majority* of the +:term:`replica set` members are down or unreachable. If a majority is +*running*, then skip these procedures and instead use the +:method:`rs.reconfig()` command according to the examples in +:ref:`replica-set-reconfiguration-usage`. - .. code-block:: javascript +If you run a pre-2.0 version and a majority of your replica set is down, +you have the two options described here. Both involve replacing the +replica set. + +Reconfigure by Turning Off Replication +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This option replaces the :term:`replica set` with a :term:`standalone` server. + +1. Stop the surviving :program:`mongod` instances. + +#. Perform a backup. + +#. Move each surviving member's data directory to an archive folder. For example: + + .. code-block:: sh + + mv /data/db /data/db-old + + .. optional:: You may remove the data instead. + +#. Restart one of the :program:`mongod` instances *without* the + ``--replSet`` parameter. + + You are back online with a single server that is not a replica set + member. Clients can use this server for both reads and writes. + +Reconfigure by "Breaking the Mirror" +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This option selects a surviving :term:`replica set` member to be the new +:term:`primary` and to be the "seed" for a new replica set. All other +members must resync from this new primary. + +1. Stop the surviving :program:`mongod` instances. + +#. Perform a backup. + +#. Move each surviving member's data directory to an archive folder. For example: + + .. code-block:: sh + + mv /data/db /data/db-old - rs.add("example.com:30003") + .. optional:: You may remove the data instead. - Once you add the removed members back into the set, they detect they - have been added and synchronize to the current state of the set. +#. Restart all :program:`mongod` instances with the new replica set name. - Be aware that if the original primary was one of the removed members, - these members may need to rollback. +#. On the new primary, add the other instances as members of the replica + set. For more information, see :doc:`/tutorial/expand-replica-set`. From 31c76346910ba5f657f7c5a09225e68094464dab Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 27 Sep 2012 17:42:20 -0400 Subject: [PATCH 4/5] DOCS-561 & DOCS-551 reconfig repl set when members down: draft 4 --- ...gure-replica-set-when-members-are-down.txt | 25 +++++++++---------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt index 903ccfe7bff..a43fcc7a9af 100644 --- a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt +++ b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt @@ -15,7 +15,7 @@ or unreachable, you must manually change the set configuration as described in the procedures in this tutorial. Use the procedure appropriate to your version and situation. -Reconfiguring when a *majority* of members are down can include +Reconfiguring when a majority of members are down can include situations where you have a network partition and where neither side of the partition has a majority. In such cases the two sides of the partition cannot see each other when determining whether a majority @@ -38,19 +38,16 @@ reconfiguration of the replica set. The ``force`` option manually reconfigures the set. The option is intended only for serious problems, such as a disaster recovery -failover. Do not use ``force`` any time you reconfigure. Also, do not -include ``force`` into any automatic scripts and do not use ``force`` +failover. Do not use ``force`` for more routine reconfigurations. Also, +do not use ``force`` in any automatic scripts and do not use ``force`` when there is still a primary. To force reconfiguration: -1. Back up a surviving member, both for safety and to bring up more new - set members more easily. +1. Back up a surviving member. -#. Connect to any surviving member and save the current configuration - so that you can switch back to the old configuration once the members - are restored. Consider the following example commands for saving the - configuration: +#. Connect to a surviving member and save the current configuration. + Consider the following example commands for saving the configuration: .. code-block:: javascript @@ -84,10 +81,12 @@ To force reconfiguration: hundreds of thousands. This is normal and designed to prevent set version collisions if network partitioning ends. -#. If any of the removed members come back online, there is the chance - they will elect a new primary, resulting in two primaries. To ensure - that the removed members do not elect a new primary, shut down or - decommission the removed members as soon as possible. +#. If the failure or partition was only temporary, the removed members + will detect that they have been removed from the set. If any of the + removed members come back online, there is the chance they will elect + a new primary, resulting in two primaries. To ensure that the removed + members do not elect a new primary, shut down or decommission the + removed members as soon as possible. Reconfigure by Replacing the Replica Set ---------------------------------------- From 27a7b3c3ef774a364bd7c2728eea841955b82fe8 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Thu, 27 Sep 2012 17:59:48 -0400 Subject: [PATCH 5/5] DOCS-561 & DOCS-551 reconfig repl set when members down: final --- ...gure-replica-set-when-members-are-down.txt | 20 ++++++++----------- 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt index a43fcc7a9af..3c4e9c3adc4 100644 --- a/source/tutorial/reconfigure-replica-set-when-members-are-down.txt +++ b/source/tutorial/reconfigure-replica-set-when-members-are-down.txt @@ -11,7 +11,7 @@ set using :method:`rs.reconfig()`, see :ref:`replica-set-reconfiguration-usage`. To reconfigure a replica set when a *majority* of the members are down -or unreachable, you must manually change the set configuration as +or unreachable, you must change the configuration as described in the procedures in this tutorial. Use the procedure appropriate to your version and situation. @@ -36,11 +36,11 @@ members are down or unreachable. You connect to any surviving member and use :method:`rs.reconfig()`'s ``force`` option to force a reconfiguration of the replica set. -The ``force`` option manually reconfigures the set. The option is -intended only for serious problems, such as a disaster recovery -failover. Do not use ``force`` for more routine reconfigurations. Also, -do not use ``force`` in any automatic scripts and do not use ``force`` -when there is still a primary. +The ``force`` option reconfigures the set. The option is intended only +for serious problems, such as a disaster recovery failover. Do not use +``force`` every time you reconfigure. Also, do not use ``force`` in any +automatic scripts and do not use ``force`` when there is still a +primary. To force reconfiguration: @@ -81,12 +81,8 @@ To force reconfiguration: hundreds of thousands. This is normal and designed to prevent set version collisions if network partitioning ends. -#. If the failure or partition was only temporary, the removed members - will detect that they have been removed from the set. If any of the - removed members come back online, there is the chance they will elect - a new primary, resulting in two primaries. To ensure that the removed - members do not elect a new primary, shut down or decommission the - removed members as soon as possible. +#. If the failure or partition was only temporary, shut down or + decommission the removed members as soon as possible. Reconfigure by Replacing the Replica Set ----------------------------------------