A MongoDB sharded cluster migration Solution

Scenario: in the production environment, all machines are replaced. It takes a short time to affect or suspend the service (the time for configservers migration) Step: migrate three configservers. We recommend that you do not change the host name for migration. The old mongos can still be accessed during and after migration, for more information, see MigrateConfigServerswiththeSameHostname.

Scenario: in the production environment, all machines are replaced. To temporarily affect or suspend the service (the time for migrating config servers) Step: migrate three config servers. We recommend that you do not change the host name for migration, the old mongos can still be accessed during and after the migration. For details, see Migrate Config Servers with the Same Hostname.

Scenario:
In the production environment, all machines are replaced. The service needs to be temporarily affected or suspended (the time for migrating config servers)
Steps:

1. Migrate three config servers. We recommend that you do not change the host name for migration. the old mongos can still be accessed during and after migration. For details, see Migrate Config Servers with the Same Hostname. Take the hosts file configuration as an example, change the ip address pointed to by the Domain Name of the config server to the new ip address. After the new config servers starts normally, the service can be started.
2. Start the new mongos on the new machine.
3. Add new data nodes to each slice.
4. Delete old data nodes from each slice.
5. Delete old mongos.

Summary: The overall steps are clear and simple, but you must pay attention to the details. If the cluster is large, the process is slow.

This article from: http://nosqldb.org, original address: http://duoyun.org/topic/544494d8bed30a781084a66d, thanks to the original author to share.