/
replica-set-priority-0-member.txt
74 lines (57 loc) · 2.84 KB
/
replica-set-priority-0-member.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
.. _replica-set-secondary-only-members:
==============================
Priority 0 Replica Set Members
==============================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
A :rsconf:`priority 0 <members[n].priority>` member is a member that
**cannot** become :term:`primary` and **cannot** trigger
:term:`elections <election>`. Priority 0 members can acknowledge write
operations issued with :ref:`write concern <write-concern>` of
``w : <number>``. For ``"majority"`` write concern, the priority 0
member must also be a voting member (i.e. :rsconf:`members[n].votes` is
greater than ``0``) to acknowledge the write. Non-voting replica set
members (i.e. :rsconf:`members[n].votes` is ``0``) cannot contribute to
acknowledging write operations with ``"majority"`` write concern.
Other than the aforementioned restrictions, secondaries that have
:rsconf:`priority 0 <members[n].priority>` function as normal
secondaries: they maintain a copy of the data set, accept read
operations, and vote in elections.
Configure a secondary to have *priority 0* to prevent it from
becoming primary, which is particularly useful in multi-data center
deployments.
For example, in the following diagram, one data center hosts the
primary and a secondary. A second data center hosts one *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 member keeps a current copy of the data to be able to
replace an unavailable member.
In many cases, you need not set standby to *priority 0*. However, in
sets with varied hardware 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 for some members of a set
with different hardware or workload profiles. In these cases, deploy a
member with *priority 0* so it can't become primary. Also consider
using an :ref:`hidden member <replica-set-hidden-members>` for this
purpose.
If your set already has seven voting members, also configure the
member as :ref:`non-voting <replica-set-non-voting-members>`.
Priority 0 Members and Failover
-------------------------------
When configuring a *priority 0* member, consider potential failover
patterns, including all possible 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
-------------
To configure a *priority 0* member, see
:doc:`/tutorial/configure-secondary-only-replica-set-member`.