Skip to content

readability: rs-priority-0 #1086

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 44 additions & 60 deletions source/core/replica-set-priority-0-member.txt
Original file line number Diff line number Diff line change
Expand Up @@ -6,69 +6,53 @@ Priority 0 Replica Set Members

.. default-domain:: mongodb

*Priority 0* members contain copies of the :term:`primary's <primary>`
data set, can accept read operations from client applications, and vote
in :ref:`elections <replica-set-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 <secondary>` 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 <secondary>`
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
<replica-set-geographical-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 <replica-set-hidden-members>` 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" : <num>,
"host" : <hostname:port>,
"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 <replica-set-geographical-distribution>`, you may want to
use a *priority 0* or a :doc:`hidden member
</core/replica-set-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 <replica-set-hidden-members>` 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`.
11 changes: 10 additions & 1 deletion source/tutorial/configure-secondary-only-replica-set-member.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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 <replica-set-elections>` and cannot
become primary in any situation.

.. code-block:: javascript
:emphasize-lines: 4

{
"_id" : <num>,
"host" : <hostname:port>,
"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
Expand Down