Navigation
This version of the documentation is archived and no longer supported.

Build Indexes on Replica Sets

On this page

For replica sets, secondaries will begin building indexes after the primary finishes building the index. In sharded clusters, the mongos will send 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 unique indexes 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:

  • Ensure that your oplog is large enough to permit the indexing or re-indexing operation to complete without falling too far behind to catch up. See the 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.
  • Before version 2.6 Background index creation operations become foreground indexing operations on secondary members of replica sets. After 2.6, background index builds replicate as background index builds on the secondaries.

Procedure

Note

If you need to build an index in a sharded cluster, repeat the following procedure for each replica set that provides each shard.

To create unique indexes 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.

Stop One Secondary

Stop the mongod process on one secondary. Restart the mongod process without the --replSet option and running on a different port. [1] This instance is now in “standalone” mode.

For example, if your mongod normally runs with on the default port of 27017 with the --replSet option you would use the following invocation:

mongod --port 47017
[1]By running the 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.

Build the Index

Create the new index using the createIndex() in the mongo shell, or comparable method in your driver. This operation will create the index on this mongod instance

For example, to create an ascending index on the username field of the records collection, use the following mongo shell operation:

db.records.createIndex( { username: 1 } )

See also

Create an Index and Create a Compound Index for more information.

Restart the Program mongod

When the index build completes, start the mongod instance with the --replSet option on its usual port:

mongod --port 27017 --replSet rs0

Modify the port number (e.g. 27017) or the replica set name (e.g. rs0) as needed.

Allow replication to catch up on this member.

Build Indexes on all Secondaries

Changed in version 2.6: Secondary members can now build indexes in the background. Previously all index builds on secondaries were in the foreground.

For each secondary in the set, build an index according to the following steps:

  1. Stop One Secondary
  2. Build the Index
  3. Restart the Program mongod

Build the Index on the Primary

To build an index on the primary you can either:

  1. Build the index in the background on the primary.

  2. Step down the primary using the rs.stepDown() method in the 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:

    1. Stop One Secondary
    2. Build the Index
    3. Restart the Program 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.