-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
replSetReconfig.txt
107 lines (74 loc) · 3.28 KB
/
replSetReconfig.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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
===============
replSetReconfig
===============
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
.. dbcommand:: replSetReconfig
The :dbcommand:`replSetReconfig` command modifies the configuration
of an existing replica set. You can use this command to add and
remove members, and to alter the options set on existing
members. Use the following syntax:
.. code-block:: javascript
{ replSetReconfig: <new_config_document>, force: false }
You may also run :dbcommand:`replSetReconfig` with the shell's
:method:`rs.reconfig()` method.
.. slave-ok, admin-only
Considerations
--------------
Be aware of the following :dbcommand:`replSetReconfig` behaviors and
considerations:
.. warning::
.. include:: /includes/warning-mixed-version-rs-config.rst
- You must issue this command against the :term:`admin database` of the current
primary member of the replica set.
- You can optionally force the replica set to accept the new
configuration by specifying ``force: true``. Use this option if there
is no current primary in the replica set.
.. warning::
Forcing the :dbcommand:`replSetReconfig` command can lead to a
:term:`rollback` situation. Use with caution.
Use the force option to restore a replica set to new servers with
different hostnames.
- A majority of the set's members must be operational for the
changes to propagate properly.
- This command can cause downtime as the set renegotiates
primary-status. Typically this is 10-20 seconds, but could
be as long as a minute or more. Therefore, you should attempt
to reconfigure only during scheduled maintenance periods.
- In some cases, :dbcommand:`replSetReconfig` forces the current
primary to step down, initiating an election for primary among the
members of the replica set. When this happens, the primary node will drop
all current connections.
.. versionchanged:: 3.2
- .. include:: /includes/fact-rs-nonzero-priority-vote-restriction.rst
- .. include:: /includes/fact-rs-non-voting-priority-restriction.rst
- Before changing the :rsconf:`protocolVersion`, ensure that at least
one oplog entry (generated from the current protocol version) has
replicated from the primary to all secondaries.
To verify, on each secondary, check the
:data:`optimes.lastCommittedOpTime.t
<replSetGetStatus.optimes.lastCommittedOpTime>` field returned from
:method:`rs.status()`. For example, connect a :binary:`~bin.mongo`
shell to each secondary and run:
.. code-block:: javascript
rs.status().optimes.lastCommittedOpTime.t
- If the current replica set protocol version is ``0``, the ``t`` is equal
to ``-1``.
- If the current replica set protocol version is ``1``, the ``t`` is greater
than ``-1``.
Once you have verified that at least one oplog entry (using the current
protocol version) has replicated to all the secondaries, you can change
the protocol version.
:dbcommand:`replSetReconfig` obtains a special mutually
exclusive lock to prevent more than one
:dbcommand:`replSetReconfig` operation from occurring at the same
time.
Additional Information
----------------------
:ref:`replSetGetConfig-output`,
:doc:`/reference/replica-configuration`, :method:`rs.reconfig()`, and
:method:`rs.conf()`.