- Sharding >
- Sharded Cluster Administration >
- Sharded Cluster Config Server Administration >
- Migrate Config Servers with Different Hostnames
Migrate Config Servers with Different Hostnames¶
On this page
Important
This procedure applies to migrating config servers when using three
mirrored mongod
instances as config servers.
Changed in version 3.2: Starting in MongoDB 3.2, config servers can be deployed as
replica set.
MongoDB 3.2 deprecates the use of three mirrored mongod
instances for config servers.
For replacing config servers deployed as members of a replica set, see Replace a Config Server.
Overview¶
For a sharded cluster that uses three mirrored config servers, all three config servers must be available in order to support operations that result in cluster metadata changes, e.g. chunk splits and migrations. If one of the config servers is unavailable or inoperable, you must replace it as soon as possible.
For a sharded cluster that uses three mirrored config servers, this procedure migrates a config server to a new server that uses a different hostname. Use this procedure only if the config server will not be accessible via the same hostname. If possible, avoid changing the hostname so that you can instead use the procedure to migrate a config server and use the same hostname.
Considerations¶
With three mirrored config servers, changing a config server’s hostname requires downtime and requires restarting every process in the sharded cluster.
While migrating config servers, always make sure that
all mongos
instances have three config servers specified in
the configDB
setting at all times. Also ensure that
you specify the config servers in the same order for each
mongos
instance’s configDB
setting.
Security¶
If your authentication mechanism or authorization strategy relies on the hostnames of the servers, you may need to re-issue certificates or update security settings with the hostname of the new server.
The Authentication and TLS/SSL documentation provide more details about updating your configuration.
Procedure¶
Important
This procedure applies to migrating config servers when using three
mirrored mongod
instances as config servers. For replacing
config servers deployed as members of a replica set, see
Replace a Config Server.
Disable the cluster balancer process temporarily. See Disable the Balancer for more information.
Shut down the config server to migrate.
This renders all config data for the sharded cluster “read only.”
Copy the contents of
dbPath
from the old config server to the new config server. For example, to copy the contents ofdbPath
to a machine namedmongodb.config2.example.net
, use a command that resembles the following:If the authentication mechanism used by your deployment relies on hostnames, ensure that you re-issue any certificates or update any settings related to that mechanism with the new hostname.
For example, if using TLS/SSL, re-issue the certificate with the updated hostname.
See Security.
Start the config server instance on the new system. The default invocation is:
Shut down all existing MongoDB processes. This includes:
- the
mongod
instances for the shards. - the
mongod
instances for the existing config databases. - the
mongos
instances.
- the
Restart all shard
mongod
instances.Restart the
mongod
instances for the two existing non-migrated config servers.Restart the
mongos
instances.Re-enable the balancer to allow the cluster to resume normal balancing operations. See the Disable the Balancer section for more information on managing the balancer process.