讲到redis的迁移，一般会使用rdb或者aof在主库做自动重载到目标库方法。但该方法有个问题就是无法保证源节点数据和目标节点数据保持一致，一般线上环境也不允许源库停机，所以要在迁移过程后还要实现同步达到数据的一致性。公司线上环境使用的是redis自己的cluster，每个节点都拥有多个rdb和aof文件，使用原始方法无疑是难上加难。本文主要讨论两种方法来实现不停机源库前提下，实现源库(redis cluster)到目标库(cluster或者单实例)的迁移：
- 采用redis replication实现
- 使用开源同步开源工具
方法一：通过redis复制机制，将目标节点作为源节点的从节点，然后关闭源节点，进行主从自动fail over，最后再关闭并删除源节点实例
1.运行环境：
源节点实例：127.0.0.1:12000/127.0.0.1:12001/127.0.0.1:12002
[root@10_86_30_37_10.86.30.37 mycluster_export1]# redis-cli -p 12000 cluster nodes
e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea 127.0.0.1:12000 myself,master - 0 0 1 connected 0-5000
f63f0d52372ad8b5c414c47e9318717b6aa113cc 127.0.0.1:12001 master - 0 1463025774035 2 connected 5001-10000
fdeb68f696290a91f08a5da3b8a3c585aaa35856 127.0.0.1:12002 master - 0 1463025775037 0 connected 10001-16383
迁移目标节点实例：
127.0.0.1:13000/127.0.0.1:13001/127.0.0.1:13002
2.迁移过程
- 启动三个目标节点，配置了redis集群模式的实例
redis-server redis13000.conf redis-server redis13001.conf redis-server redis13002.conf
- 将这三个节点做已有集群实例的slave
redis-cli -p 13000 cluster meet 127.0.0.1 12000 redis-cli -p 13000 cluster replicate e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea redis-cli -p 13001 cluster meet 127.0.0.1 12001 redis-cli -p 13001 cluster replicate f63f0d52372ad8b5c414c47e9318717b6aa113cc redis-cli -p 13002 cluster meet 127.0.0.1 12002 redis-cli -p 13002 cluster replicate fdeb68f696290a91f08a5da3b8a3c585aaa35856
- 查看集群情况：
redis-cli -p 13002 cluster slots 1) 1) (integer) 5001 2) (integer) 10000 3) 1) "127.0.0.1" 2) (integer) 12001 4) 1) "127.0.0.1" 2) (integer) 13001 2) 1) (integer) 10001 2) (integer) 16383 3) 1) "127.0.0.1" 2) (integer) 12002 4) 1) "127.0.0.1" 2) (integer) 13002 3) 1) (integer) 0 2) (integer) 5000 3) 1) "127.0.0.1" 2) (integer) 12000 4) 1) "127.0.0.1" 2) (integer) 13000
- 将其中一个主节点下线，10s后观察情况：
redis-cli -p 12000 shutdown redis-cli -p 13000 cluster nodes fdeb68f696290a91f08a5da3b8a3c585aaa35856 127.0.0.1:12002 master - 0 1463042318423 0 connected 10001-16383 f63f0d52372ad8b5c414c47e9318717b6aa113cc 127.0.0.1:12001 master - 0 1463042319426 2 connected 5001-10000 e39a73c30dfff3139242e66f8e0a41178b39e280 127.0.0.1:13000 myself,master - 0 0 6 connected 0-5000 1f552bdea453caeaa64b4b33a05e4eedeb3f3dd2 127.0.0.1:13001 slave f63f0d52372ad8b5c414c47e9318717b6aa113cc 0 1463042317421 4 connected 6a70a82c6f07dc4e61a97b6aee7a2994365642cc 127.0.0.1:13002 slave fdeb68f696290a91f08a5da3b8a3c585aaa35856 0 1463042320429 5 connected e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea 127.0.0.1:12000 master,fail - 1463042217663 1463042214056 1 disconnected
- 删除已经下线的主节点，一个一个操作，操作中间检查操作是否成功，因为留言协议和failover需要一段时间
redis-cli -p 13000 cluster forget e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea redis-cli -p 13001 cluster forget e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea redis-cli -p 13002 cluster forget e5ce695f7c5745ca81b4239fb5666b6a71fbb4ea redis-cli -p 13000 cluster nodes fdeb68f696290a91f08a5da3b8a3c585aaa35856 127.0.0.1:12002 master - 0 1463043284365 0 connected 10001-16383 f63f0d52372ad8b5c414c47e9318717b6aa113cc 127.0.0.1:12001 master - 0 1463043283364 2 connected 5001-10000 e39a73c30dfff3139242e66f8e0a41178b39e280 127.0.0.1:13000 myself,master - 0 0 6 connected 0-5000 1f552bdea453caeaa64b4b33a05e4eedeb3f3dd2 127.0.0.1:13001 slave f63f0d52372ad8b5c414c47e9318717b6aa113cc 0 1463043286369 4 connected 6a70a82c6f07dc4e61a97b6aee7a2994365642cc 127.0.0.1:13002 slave fdeb68f696290a91f08a5da3b8a3c585aaa35856 0 1463043285368 5 connected redis-cli -p 13000 cluster nodes e39a73c30dfff3139242e66f8e0a41178b39e280 127.0.0.1:13000 myself,master - 0 0 6 connected 0-5000 1f552bdea453caeaa64b4b33a05e4eedeb3f3dd2 127.0.0.1:13001 slave - 0 1463043457854 4 connected 6a70a82c6f07dc4e61a97b6aee7a2994365642cc 127.0.0.1:13002 slave - 0 1463043458857 5 connected
3.重点细节：
- 删除的主节点，如果重新启动，他自身会重新加载集群配置文件，造成集群混乱，建议如果想重启该实例，删掉集群配置文件，进行重新配置。
- 必须先关闭master节点后，再删除。一次不能将所有实例都关闭，逐个操作，否则会造成整个集群down掉
- 删除forget节点时，要在所有其他节点上执行cluster forget 命令，貌似这个命令不会通过留言协议传播到所有节点