MongoDB Documentation, Release 3.0.4 2. If the hostname has changed for any of the config servers, update the configDB string for each mongos instance. The mongos instances must all use the same configDB string. The strings must list identical host names in identical order. 3. Restart the mongos instances being sure to use the updated configDB string if hostnames have changed. 1. Shut down the mongod process. To ensure a clean shutdown, use the shutdown command. 2. Move the data directory (i.e., the dbPath ) to the new machine. 3. Restart the mongod process at the new location. 4. Connect to the replica set’s current primary. 5. If the hostname of the member has changed, use rs.reconfig() to update the replica set configuration document (page 652) with the new hostname. 6. To confirm the new configuration, issue rs.conf() . 7. Wait for the member to recover. To check the member’s state, issue rs.status() . For example, the following sequence of commands updates the hostname for the instance at position 2 in the members array: For more information on updating the configuration document, see replica-set-reconfiguration-usage . Migrate the Primary in a Replica Set Shard While migrating the replica set’s primary, the set must elect a new primary. This failover process which renders the replica set unavailable to perform reads or accept writes for the duration of the election, which typically completes quickly. If possible, plan the migration during a maintenance window. cfg = rs.conf() cfg.members[2].host = "pocatello.example.net:27017" rs.reconfig(cfg) Tip To avoid downtime, give each config server a logical DNS name (unrelated to the server’s physical or virtual hostname). Without logical DNS names, moving or renaming a config server requires shutting down every mongod and mongos instance in the sharded cluster. For more information, see Start the mongos Instances (page 692). Migrate the shards one at a time. For each shard, follow the appropriate procedure in this section. Migrate a Replica Set Shard To migrate a sharded cluster, migrate each member separately. First migrate the non-primary members, and then migrate the primary last. If the replica set has two voting members, add an arbiter (page 571) to the replica set to ensure the set keeps a majority of its votes available during the migration. You can remove the arbiter after completing the migration. 1. Step down the primary to allow the normal failover (page 580) process. To step down the primary, connect to the primary and issue the either the replSetStepDown command or the rs.stepDown() method. The following example shows the rs.stepDown() method: 711 10.3. Sharded Cluster Tutorials Migrate a Member of a Replica Set Shard Migrate the Shards