OPTIONS

Replace a Config Server

Changed in version 3.2: Starting in MongoDB 3.2, config servers for sharded clusters can be deployed as a replica set. The replica set config servers must run the WiredTiger storage engine. MongoDB 3.2 deprecates the use of three mirrored mongod instances for config servers.

For replacing config servers deployed as three mirrored mongod instances, see Migrate Config Servers with the Same Hostname and Migrate Config Servers with Different Hostnames.

Overview

If the config server replica set becomes read only, i.e. does not have a primary, the sharded cluster cannot support operations that change the cluster metadata, such as chunk splits and migrations. Although no chunks can be split or migrated, applications will be able to write data to the sharded cluster.

If one of the config servers is unavailable or inoperable, repair or replace it as soon as possible. The following procedure replaces a member of a config server replica set with a new member.

The tutorial is specific to MongoDB 3.2. For earlier versions of MongoDB, refer to the corresponding version of the MongoDB Manual.

Considerations

The following restrictions apply to a replica set configuration when used for config servers:

  • Must have zero arbiters.
  • Must have no delayed members.
  • Must build indexes (i.e. no member should have buildIndexes setting set to false).

Procedure

1

Start the replacement config server.

Start a mongod instance, specifying both the --configsvr and --replSet options.

mongod --configsvr --replSet <replicaSetName>
2

Add the new config server to the replica set.

Connect a mongo shell to the primary of the config server replica set and use rs.add() to add the new member.

rs.add("<hostnameNew>:<portNew>")

The initial sync process copies all the data from one member of the config server replica set to the new member without restarting.

mongos instances automatically recognize the change in the config server replica set members without restarting.

3

Shut down the member to replace.

If replacing the primary member, step down the primary first before shutting down.

4

Remove the member to replace from the config server replica set.

Upon completion of initial sync of the replacement config server, from a mongo shell connected to the primary, use rs.remove() to remove the old member.

rs.remove("<hostnameOld>:<portOld>")

mongos instances automatically recognize the change in the config server replica set members without restarting.

5

If necessary, update mongos configuration or DNS entry.

With replica set config servers, the mongos instances specify in the --configdb or sharding.configDB setting the config server replica set name and at least one of the replica set members.

As such, if the mongos instance does not specify the removed replica set member in the --configdb or sharding.configDB setting, no further action is necessary.

If, however, a mongos instance specified the removed member in the --configdb or configDB setting, either:

  • Update the setting for the next time you restart the mongos, or
  • Modify the DNS entry that points to the system that provided the old config server, so that the same hostname points to the new config server.

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.