一 引言

为什么是不完整的？因为有另一个不完整的管理脚本来做这个事情，

但是它是不完整的，实现简陋。我的如下的工作便是将整个流程补充

完整，并保证目标达成。所以我记录下来的是不完整的另一部分。

如下。

 [classic_tong @ 20200321 https:////www.cnblogs.com/hugetong/p/12542153.html]

二 背景

目标系统的redis版本是4.0，之所以强调版本，是因为新版本中，拥有了命令

redis-cli --cluster。4.0版本中并没有，它的前任是脚本，redis-trib.rb。二者

大同小异，没有本质区别。

下面是，进行中使用到的几个操作

1.  查看当前集群拓扑的方法

redis-cli -c cluster nodes 
redis-cli -c cluster slots

拓扑关系

a51459f9cf9b5611cefe137dfcfbd9d9fdb03cfe 10.1.3.168:6379@16379 slave c3ac54ffd1efd366fdf70b3ba0e4185bee49840e 0 1584705659599 6 connected
8ea700c80aa9bebbcd87549cad4538cfeb13dc5f 10.1.4.40:6379@16379 master - 0 1584705662628 1 connected 0-5460
d1fb28322822546c76800cee00fc08ea30eee3d9 10.1.4.39:6379@16379 slave 38dcb1adf11ca19bc66d2d2e887588fb65537c9e 0 1584705658000 4 connected
f4f3aa15073de7f6efc0ee104d4b51de8d5e5ff5 10.1.3.165:6379@16379 slave 8ea700c80aa9bebbcd87549cad4538cfeb13dc5f 0 1584705660606 5 connected
38dcb1adf11ca19bc66d2d2e887588fb65537c9e 10.1.3.170:6379@16379 myself,master - 0 1584705659000 3 connected 10923-16383
c3ac54ffd1efd366fdf70b3ba0e4185bee49840e 10.1.3.169:6379@16379 master - 0 1584705661622 2 connected 5461-10922

 

2  查看数据分布的方法

redis-trib.rb info 127.0.0.1:6379  

数据分别是指，那些数据存储在那些节点上。

我这里的集群组织方式是，一对一对的组织。每一对有一个master，一个slave。slave作为master的数据冗余和failover节点。可以从上一个命令的输出里，见到他们的关系，

而，数据的分布如下所示，关注keys信息。可以看见，那些那些key，在那些那些地方。当正在进行数据迁移时，我们能看见keys前边的数值在一点点减少。

[root@redis6st caotong]# redis-trib.rb info 127.0.0.1:6379
127.0.0.1:6379 (38dcb1ad...) -> 1998 keys | 5461 slots | 1 slaves.
10.1.4.40:6379 (8ea700c8...) -> 2012 keys | 5461 slots | 1 slaves.
10.1.3.169:6379 (c3ac54ff...) -> 1999 keys | 5462 slots | 1 slaves.
[OK] 6009 keys in 3 masters.
0.37 keys per slot on average.

 

3 查看集群实时状态的方法

redis-trib.rb check 127.0.0.1:6379 

这个输出，重点关心的是一下额外的信息， 如xxx is migrating 字样

[root@redis6st caotong]# redis-trib.rb check 127.0.0.1:6379
>>> Performing Cluster Check (using node 127.0.0.1:6379)
M: 38dcb1adf11ca19bc66d2d2e887588fb65537c9e 127.0.0.1:6379
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
S: a51459f9cf9b5611cefe137dfcfbd9d9fdb03cfe 10.1.3.168:6379
   slots: (0 slots) slave
   replicates c3ac54ffd1efd366fdf70b3ba0e4185bee49840e
M: 8ea700c80aa9bebbcd87549cad4538cfeb13dc5f 10.1.4.40:6379
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
S: d1fb28322822546c76800cee00fc08ea30eee3d9 10.1.4.39:6379
   slots: (0 slots) slave
   replicates 38dcb1adf11ca19bc66d2d2e887588fb65537c9e
S: f4f3aa15073de7f6efc0ee104d4b51de8d5e5ff5 10.1.3.165:6379
   slots: (0 slots) slave
   replicates 8ea700c80aa9bebbcd87549cad4538cfeb13dc5f
M: c3ac54ffd1efd366fdf70b3ba0e4185bee49840e 10.1.3.169:6379
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

 

三 方案

我这里，采用的迁移方案，是先扩容再缩容。这样是热的，online的。对在线系统无感知的。

把你想迁入的目标作为扩容资源扩进来，然后再将你想缩容的资源作为迁出目标缩掉，即可。

 

我会先增加一对主备节点，然后理由上面提到的两个命令，来观察：

（1）迁移的过程是否正常，（2）数据是否正常流动，（3）迁移是否已经进行完成

迁移进行完成指的是数据流动已经完成。

过程是否正常：1 通过前文的check命令查看runtime状态。2.通过info命名查看数据流动进程。

最终的状态，可以通过nodes命令观察，是否出现fail的节点。以及是否每个master都结对一个slave，

包括谁和谁是一对的这种对应关系。

 

遗憾的是，这个增减动作不是手工进行的（通过开篇的那个脚本处理）。未能补充这样的细节。

不过，索性聪明如你，redis-cli --cluster help下就ok了。无外乎add node，add slot之类的。

 

四 补充

如面前提到，当进行以上操作时，可能会出现fail的节点。这个时候也无需慌张。

如果fail的是一个master，它的slave会自动顶替成为master。

所以，需要我们处理的只有一中情况，就是slave fail。

我们只需采用（三）中的操作，将这个slave去除。然后把它reset（重启？），等它就绪之后

再把它加回集群里。

因为有个master是没有slave的，所以聪明的redis会用这个顶上去。不出意外，是会成功的：）

 

需要注意的是，这个时候，该master的单点的。整个系统是处于高风险状态的。

不过也没关系，因为还有其他master做冗余（是么？我不确定。）

 [classic_tong @ 20200321 https:////www.cnblogs.com/hugetong/p/12542153.html] 

五 结局

简陋如斯，羞于发布，轻踩。