MongoDB Documentation, Release 3.0.4 Replace Disabled Config Server Overview Considerations Procedure Migrate a Sharded Cluster to Different Hardware 709 10.3. Sharded Cluster Tutorials This procedure moves the components of the sharded cluster to a new hardware system without downtime for reads and writes. Important: While the migration is in progress, do not attempt to change to the cluster metadata (page 689). Do not use any operation that modifies the cluster metadata in any way . For example, do not create or drop databases, create or drop collections, or use any sharding commands. If your cluster includes a shard backed by a standalone mongod instance, consider converting the standalone to a replica set (page 614) to simplify migration and to let you keep the cluster online during future maintenance. Migrating a shard as standalone is a multi-step process that may require downtime. To migrate a cluster to new hardware, perform the following tasks. mongod --configsvr Step 3: If necessary, update DNS and/or networking. Ensure the new config server is accessible by the same name as the previous config server. Step 4: Start the new config server. Step 2: Shut down one of the remaining config servers. Copy all of this host’s dbPath path from the current system to the system that will provide the new config server. This command, issued on the system with the data files, may resemble the following: rsync -az /data/configdb mongodb.config2.example.net:/data/configdb Step 1: Provision a new system, with the same IP address and hostname as the previous host. You will have to ensure the new system has the same IP address and hostname as the system it’s replacing or you will need to modify the DNS records and wait for them to propagate. In the course of this procedure never remove a config server from the configDB parameter on any of the mongos instances. This process assumes that the hostname of the instance will not change. If you must change the hostname of the instance, use the procedure to migrate a config server and use a new hostname (page 708). This procedure replaces an inoperable config server (page 670) in a sharded cluster (page 667). Use this procedure only to replace a config server that has become inoperable (e.g. hardware failure). Sharded clusters use a group of three config servers to store cluster meta data, and all three config servers must be available to support cluster metadata changes that include chunk splits and migrations. If one of the config servers is unavailable or inoperable you must replace it as soon as possible.