From 1e015802275bc333ff56480382c172be5f171a9c Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Fri, 28 Jun 2013 15:17:45 -0400 Subject: [PATCH] dability: rs-priority-0 Old --- file: build/rs-priority-zero/json/core/replica-set-priority-0-member.json source: source/core/replica-set-priority-0-member.txt stats: coleman-liau: 10.196579572446552 flesch-ease: 39.57946377672212 flesch-level: 12.968193586698337 foggy: count: 40 factor: 0.09501187648456057 threshold: 3 sentence-count: 20 sentence-len-avg: 21 smog-index: 11.20814326018867 word-count: 421 New --- file: build/rs-priority-zero/json/core/replica-set-priority-0-member.json source: source/core/replica-set-priority-0-member.txt stats: coleman-liau: 9.858789625360231 flesch-ease: 44.75171031199099 flesch-level: 10.76538278411227 foggy: count: 33 factor: 0.09510086455331412 threshold: 3 sentence-count: 23 sentence-len-avg: 15 smog-index: 9.971965246562196 word-count: 347 --- source/core/replica-set-priority-0-member.txt | 104 ++++++++---------- ...gure-secondary-only-replica-set-member.txt | 11 +- 2 files changed, 54 insertions(+), 61 deletions(-) diff --git a/source/core/replica-set-priority-0-member.txt b/source/core/replica-set-priority-0-member.txt index 0bf16eebe8b..c5cc0272866 100644 --- a/source/core/replica-set-priority-0-member.txt +++ b/source/core/replica-set-priority-0-member.txt @@ -6,69 +6,53 @@ Priority 0 Replica Set Members .. default-domain:: mongodb -*Priority 0* members contain copies of the :term:`primary's ` -data set, can accept read operations from client applications, and vote -in :ref:`elections ` for primary. However, -*priority 0* members **cannot** become primary in an election, and -*priority 0* members **do not** trigger elections. - -For example, you may consider setting the priority of a member to 0 -when you wish to to prevent :term:`secondaries ` located -outside of the main data centers from ever becoming primary. - -.. example:: - - In the following three member replica set, the first data center - contains the primary and a secondary whereas the second data center - contains a *priority 0* member that cannot become a primary. - - .. include:: /images/replica-set-three-members-geographically-distributed.rst +A *priority 0* member is similar to a secondary except that it cannot +become a :term:`primary` and it cannot *trigger* an :term:`election`. +The member otherwise functions as a secondary. It maintains a copy of +the data set, accepts read operations, and votes in elections. You can +use the *priority 0* setting to prevent :term:`secondaries ` +located outside the main data center from becoming primary. + +In the following three-member replica set, the first data center +contains the primary and a secondary. The second data center contains a +*priority 0* member that cannot become primary. + +.. include:: /images/replica-set-three-members-geographically-distributed.rst + +Priority 0 Members as Standbys +------------------------------ + +A *priority 0* member can function as a standby. In some replica sets, +it might not be possible to add a new member in a reasonable amount of +time. A standby holds an up-to-date copy of the data for the purpose of +replacing a secondary that fails or goes offline. + +In many cases, you need not configure a standby as *priority 0*. But in +sets with varied hardware availability or :ref:`geographic distribution +`, a *priority 0* standby ensures +that only qualified members become primary. + +A priority 0* standby may also be valuable when your primary and any hot +standbys have different hardware specifications than the other members +of the set. In these cases, deploy a member as a *priority 0* member to +ensure it can vote in elections but not become primary. (You also can +use a :ref:`hidden ` member for this +purpose.) + +If your set already has seven voting members, set the standby's +:data:`~local.system.replset.members[n].votes` value to ``0``. This +ensures it does not vote in elections. + +Priority 0 Members and Failover +------------------------------- + +When configuring a *priority 0* member, consider the likely failover +scenarios, such as inter-site network partitions. Always ensure that +your main data center contains both a quorum of voting members and +contains members that are eligible to be primary. Configuration ------------- -A *priority 0* member has its -:data:`~local.system.replset.members[n].priority` equal to ``0`` in its -member configuration: - -.. code-block:: javascript - :emphasize-lines: 4 - - { - "_id" : , - "host" : , - "priority" : 0 - } - -Applications ------------- - -*Priority 0* members can function as cold standbys in a replica -set. In this role, a member of a replica set holds a copy of the data -but cannot become primary without manual intervention. For some sets, -it may not be possible to initialize a new member in a reasonable -amount of time. In these situations, it may be useful to maintain a -cold standby with an up-to-date copy for the purpose of replacing -another member in the replica set. In most cases, these members can be -ordinary members of the replica set, but in larger sets, with varied -hardware availability, or given some patterns of :ref:`geographical -distribution `, you may want to -use a *priority 0* or a :doc:`hidden member -` to maintain an extra copy of the data. - -*Priority 0* members may be valuable when your primary and any hot -standbys have different hardware specification than the other members -of the set. In these cases, deploy members as a *priority 0* member -or a :ref:`hidden ` member to ensure that -they will vote in elections but will never be eligible to become -primary. If your set already has ``7`` voting members, set the -:data:`~local.system.replset.members[n].votes` value to ``0`` for the -cold standby members, so that they won't vote in elections. - -When configuring *priority 0* members, consider the likely failover -scenarios, such as inter-site network partitions. Always ensure that -there will be members eligible for election as primary *and* a quorum -of voting members in the main facility. - To configure a *priority 0* member, see :doc:`/tutorial/configure-secondary-only-replica-set-member`. diff --git a/source/tutorial/configure-secondary-only-replica-set-member.txt b/source/tutorial/configure-secondary-only-replica-set-member.txt index 35d08d4e15f..04e7aa9328f 100644 --- a/source/tutorial/configure-secondary-only-replica-set-member.txt +++ b/source/tutorial/configure-secondary-only-replica-set-member.txt @@ -12,11 +12,20 @@ detailed description of secondary-only members and their purposes, see :doc:`/core/replica-set-priority-0-member`. To configure a member as secondary-only, set its -:data:`~local.system.replset.members[n].priority` value to ``0``. Any +:data:`~local.system.replset.members[n].priority` value to ``0`` in its member configuration. Any member with a :data:`~local.system.replset.members[n].priority` equal to ``0`` will never seek :ref:`election ` and cannot become primary in any situation. +.. code-block:: javascript + :emphasize-lines: 4 + + { + "_id" : , + "host" : , + "priority" : 0 + } + MongoDB does not permit the current :term:`primary` to have a priority of ``0``. To prevent the current primary from again becoming a primary, you must first step down the current primary using