background
In some cases, the official recommended migration method is not so convenient, such as the MONGOs cluster's overall migration steps are very cumbersome, and network requirements are high;
Mongosync support for MONGOs cluster migrations, currently supports 3.0 and below, especially for MongoDB cross room migrations
There is such a demand
Room A has a set of MONGOs cluster, need to migrate to the engine room B,a and B MONGO instance network, but in one of the relay server can ping a room and b room of the MongoDB example, so I use 360 development of open source migration Tool Mongosync
Steps
1 in B computer room to establish and a room with the same configuration of MONGOs cluster
2 A machine room MONGOs stop load Balancer
3 Mongosync Total + incremental Sync
4 wait for both ends of the cluster data to complete synchronization, in the B room to set sharding information, such as which table which field to participate in sharding
5 A machine room MONGOs cluster business stop Clothing
6 Confirm the data is completely synchronized, the application layer will change the business IP to b room mongos IP
7 Migration Complete
methods of installation and use of Mongosync
System version CentOS 7.2 python 2.7.5 gcc 4.8.5 installation Method
1 git clone Https://github.com/jacketwoo/mongosync
2 Yum install-y scons
3 Yum install-y boost boost-devel
4 Yum install-y Openssl-devel
5 CD mongosync/
6 Make use Method (full amount + increment +mongos)
Nohup./mongosync--src_srv 10.6.13.140:27000--src_user ucloudbackup--src_passwd xxx--src_auth_db admin--dst_srv 10.1 9.110.146:27000--dst_user ucloudbackup--dst_passwd xxx--dst_auth_db admin--oplog--is_mongos--shard_user Ucloudbackup--shard_passwd xxx&
where Shard_user and shard_passwd refers to each of the fragmented login account and password, there is no account of the inconsistency of the multiple fragmented account, so ideally all of the slices are using a set of accounts and passwords
More wikis See Https://github.com/Qihoo360/mongosync/wiki