Skip to content

Commit 70a02fc

Browse files
devkevkay-kim
authored andcommitted
Clarify the need for priority: 0
I found the previous wording suggestive that priority: 0 would be implied if not specified when hidden: true. I prefer this wording, as I feel it makes clearer the need for priority: 0 to be explicitly specified (even though it's not much of a change). Signed-off-by: kay <kay.kim@10gen.com>
1 parent 981625e commit 70a02fc

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

source/core/replica-set-hidden-member.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -11,9 +11,9 @@ Hidden Replica Set Members
1111
A hidden member maintains a copy of the :term:`primary's <primary>`
1212
data set but is **invisible** to client applications. Hidden members
1313
are good for workloads with different usage patterns from the other
14-
members in the :term:`replica set`. Hidden members are always
14+
members in the :term:`replica set`. Hidden members must always be
1515
:ref:`priority 0 members <replica-set-secondary-only-members>` and
16-
**cannot become primary**. The :method:`db.isMaster()` method does not
16+
so **cannot become primary**. The :method:`db.isMaster()` method does not
1717
display hidden members. Hidden members, however, **do vote** in
1818
:ref:`elections <replica-set-elections>`.
1919

0 commit comments

Comments
 (0)