-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
build-indexes-on-replica-sets.txt
237 lines (169 loc) · 8.02 KB
/
build-indexes-on-replica-sets.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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
.. index:: index; replica set
.. index:: replica set; index
.. _index-build-on-replica-sets:
.. _index-building-replica-sets:
=============================
Build Indexes on Replica Sets
=============================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
For replica sets, secondaries will begin building indexes *after* the
:term:`primary` finishes building the index. In :term:`sharded clusters
<sharded cluster>`, the :binary:`~bin.mongos` will send :method:`createIndex()
<db.collection.createIndex()>` to the primary members of the replica
set for each shard, which then replicate to the secondaries after the
primary finishes building the index.
To minimize the impact of building an index on your replica set, you
can use the following procedure to build indexes.
Considerations
--------------
.. important::
To create :ref:`unique indexes <index-type-unique>` using the
following procedure, you must stop all writes to the collection
during this procedure.
If you cannot stop all writes to the collection during this
procedure, do not use the procedure on this page. Instead, build
your unique index on the collection by:
- issuing :method:`db.collection.createIndex()` on the primary for a
replica set, or
- issuing :method:`db.collection.createIndex()` on the
:binary:`~bin.mongos` for a sharded cluster.
- Ensure that your :term:`oplog` is large enough to permit the
indexing or re-indexing operation to complete without falling
too far behind to catch up. See the :ref:`oplog sizing
<replica-set-oplog-sizing>` documentation for additional
information.
- This procedure *does* take one member out of the replica set at a
time. However, this procedure will only affect one member of the
set at a time rather than *all* secondaries at the same time.
Procedure
---------
.. note::
If you need to build an index in a :term:`sharded cluster`, repeat
the following procedure for each replica set that provides each
:term:`shard`.
To create :ref:`unique indexes <index-type-unique>` using the
following procedure, you must stop all writes to the collection
during the index build. Otherwise, you may end up with inconsistent
data across the replica set members. If you cannot stop all writes to
the collection, do not use the following procedure to create unique
indexes.
.. _tutorial-index-on-replica-sets-stop-one-member:
Stop One Secondary
~~~~~~~~~~~~~~~~~~
Stop the :binary:`~bin.mongod` process on one secondary. Restart the
:binary:`~bin.mongod` process, making the following configuration updates:
.. tabs::
tabs:
- id: config-file
name: Configuration File
content: |
If you are using a configuration file, make the following
configuration updates:
- Comment out the :setting:`replication.replSetName` option.
- Change the :setting:`net.port` to a different port. [#different-port]_
Make a note of the original port setting as a comment.
- If the :binary:`~bin.mongod` is a :term:`shard` or
:term:`config server` member, you must also:
- Comment out the :setting:`sharding.clusterRole` option.
- Set parameter :parameter:`skipShardingConfigurationChecks`
(available in MongoDB 3.2.19+) to
``true`` in the :setting:`setParameter` section.
For example, for a shard/config server replica set member,
the updated configuration file will include content like the
following example:
.. code-block:: yaml
net:
port: 27218
# port: 27018
#replication:
# replSetName: shardA
#sharding:
# clusterRole: shardsvr
setParameter:
skipShardingConfigurationChecks: true
- id: command-line
name: Command-line Options
content: |
If using command-line options, make the following
configuration updates:
- Remove :option:`--replSetName <mongod --replSet>`.
- Modify :option:`--port <mongod --port>` to a different port. [#different-port]_
- If the :binary:`~bin.mongod` is a :term:`shard` or
:term:`config server` member, you must also:
- Remove :option:`--shardsvr <mongod --shardsvr>` if a
shard member and :option:`--configsvr <mongod
--configsvr>` if a config server member.
- Set parameter
:parameter:`skipShardingConfigurationChecks` (available
in MongoDB 3.2.19+) to ``true`` in the
:setting:`setParameter` section.
For example, if your replica set member that is not part of
a sharded cluster *normally* runs with on the default port
of ``27017`` with the :option:`--replSet <mongod --replSet>`
option you would use the following invocation:
.. code-block:: sh
mongod --port 27218
.. [#different-port] By running the :binary:`~bin.mongod` on a different
port, you ensure that the other members of the replica set and all
clients will not contact the member while you are building the
index.
.. _tutorial-index-on-replica-sets-build-index:
Build the Index
~~~~~~~~~~~~~~~
Create the new index using the :method:`~db.collection.createIndex()`
in the :binary:`~bin.mongo` shell, or comparable method in your
driver. This operation will create the index on this
:binary:`~bin.mongod` instance
For example, to create an ascending index on the ``username`` field of
the ``records`` collection, use the following :binary:`~bin.mongo` shell
operation:
.. code-block:: sh
db.records.createIndex( { username: 1 } )
.. _tutorial-index-on-replica-sets-restart-mongod:
Restart the Program ``mongod`` as a Replica Set Member
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When the index build completes, restart the :binary:`~bin.mongod`
instance as a member of the replica set using its normal configuration
file or command-line arguments. That is, undo the configuration changes
made when starting as a standalone. For shard or config server replica
set members, be sure to remove the
:parameter:`skipShardingConfigurationChecks` parameter.
When the index build completes, start the :binary:`~bin.mongod` instance
with the :option:`--replSet <mongod --replSet>` option on its usual port:
.. code-block:: sh
mongod --port 27017 --replSet rs0
Allow replication to catch up on this member.
Build Indexes on all Secondaries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For each secondary in the set, build an index according to the
following steps:
#. :ref:`tutorial-index-on-replica-sets-stop-one-member`
#. :ref:`tutorial-index-on-replica-sets-build-index`
#. :ref:`tutorial-index-on-replica-sets-restart-mongod`
Build the Index on the Primary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When all the secondaries have the new index, step down the primary,
restart it as a standalone using the procedure described above,
and build the index on the former primary:
#. :ref:`Build the index in the background
<index-creation-background>` on the primary.
#. Step down the primary using the :method:`rs.stepDown()` method in
the :binary:`~bin.mongo` shell to cause the current primary to become a
secondary graceful and allow the set to elect another member as
primary.
Then repeat the index building procedure, listed below, to build the
index on the primary:
#. :ref:`tutorial-index-on-replica-sets-stop-one-member`
#. :ref:`tutorial-index-on-replica-sets-build-index`
#. :ref:`tutorial-index-on-replica-sets-restart-mongod`
Building the index on the background, takes longer than the foreground
index build and results in a less compact index structure. Additionally,
the background index build may impact write performance on the
primary. However, building the index in the background allows the set to
be continuously up for write operations while MongoDB builds the
index.