Redis集群使用总结（二）：
本篇文章需要结合上一篇《redis集群使用总结（一）》，而这里主要介绍Redis集群的管理的分析和研究总结。
· 如何管理
· 故障转移
· 注意事项
一、如何管理
Redis集群的管理涉及的主要就是针对集群中的主次节点进行新增、删除以及对节点重新分片操作，而这些操作我们就可以使用redis-trib.rb工具来实现，具体如下：
1、新增Master节点
Redis集群中新增节点需要新创建一个空节点，然后将该空节点加入到集群中，最后为这个新的空节点分配slot哈希槽值即可，具体如下：
A、新建空节点
首先，新建一个redis-6382.conf配置文件：
文件内容与其它节点内容类似，不同的是端口，日志目录以及数据库文件的路径；
其次，启动这个新节点：
$redis-server /redis/etc/redis-6382.conf
B、加入空节点到集群
$redis-trib.rb add-node 127.0.0.1:6382 127.0.0.1:6379
NOTE：
127.0.0.1:6379为集群中的任意节点；
127.0.0.1:6382为集群新增的空节点；
执行完成之后，结果显示如下：
可以使用redis-trib.rb验证新增节点的类型是否为主节点：
$redis-trib.rb check 127.0.0.1:6382
结果显示如下：
C、为空节点分配slot
$redis-trib.rb reshard 127.0.0.1:6382
执行结果显示，并按提示输入：
// 提示要迁移的slots的数量，这里输入500
How many slots do you want to move (from 1 to 16384)? 500
// 提示指定为哪个node-id分配slot，这里输入新增的node
What is the receiving node ID? e7fcec2bdbd19c5244502276059a53878b9093af
// 选择指定slot的来源
// all->代表从所有的master中重新分配
// done-> 数据要提取slot的master节点id，最后用done结束
Please enter all the source node IDs.
Type ‘all’ to use all the nodes assource nodes for the hash slots.
Type ‘done’ once you entered allthe source nodes IDs.
// 这里我们选择all即可
Source node #1:all
// 输入yes之后，开始进行slots的分配和数据的移动
Do you want to proceed with the proposed reshard plan (yes/no)? yes
执行结果显示：
从上图可以知道，新的主节点已经添加并分配好slots，slots值的范围为500.
D、验证使用该节点
从上图知道，新节点已经添加并配置成功，并且使用正常无问题。
2、新增Slave节点
新增Slave节点与新增Master的前三步骤相同，这里不再介绍，不同的是需要登录到从节点的redis-cli，使用replicate为该节点指定主节点，具体如下：
127.0.0.1:7382>cluster replicatee7fcec2bdbd19c5244502276059a53878b9093af
结果显示：
(error) ERR To set a master the node must be empty and without assignedslots.
NOTE：
上面的错误意思是不能为一个非空并且分配了slot的主节点继续添加从节点。
由于上面的问题，我们现在将6382主节点置空并且清除为其指定的slots，具体如下：
A、先删除主节点的slots
$redis-trib.rb reshrd 127.0.0.1:6382
// 删除指定的500的slots
How many slots do you want to move (from 1 to 16384)? 500
// 选择将当前的slots要转移到的node-id（非当前的节点id）
What is the receiving node ID? ae4c4e5faf5fb679f697d07b7afe1cfb55991113
// 指定slots的来源为当前的node-id
Source node #1:e7fcec2bdbd19c5244502276059a53878b9093af
Source node #2:done
// 开始转移同步
Do you want to proceed with the proposed reshard plan (yes/no)? yes
B、再删除从节点的slots
该步骤的实现与A中的步骤完全相同，请自行实现。
C、指定从节点
127.0.0.1:7382>cluster replicatee7fcec2bdbd19c5244502276059a53878b9093af
执行结果：
从上图已经知道，从节点已经绑定成功了。
D、查看下主从节点关系
$redis-trib.rb check 127.0.0.1:6380
执行结果：
从上图我们看出，主节点6382为空，从节点7382也为空，并且主从节点的关系也已经正常，接下来就是使用reshard如同上面的操作相同，这里不介绍说明。
3、删除Slave节点
$redis-trib.rb del-node 127.0.0.1:7382
8d8589fd7e9d140442e06b06e9e810d5d0f5e257
执行结果：
4、删除Master节点
A、转移主节点slots
这里的操作与上面的操作相同，这里不赘述。
B、删除主节点
$redis-trib.rb del-node 127.0.0.1:6382
8d8589fd7e9d140442e06b06e9e810d5d0f5e257
执行结果：
二、故障转移
Redis集群支持一旦某个主节点故障之后，集群如何保持正常工作，目前其包含两种故障转移类型：自动转移和手动转移。对于前者，不需要使用者做任何工作，全部交由Redis集群内部维护，但这种方式会存在很小概率丢失keys的机率；相对于前者，手动转移可以解决前者数据丢失的问题，具体如下：
A、自动转移
要触发一次故障自动转移，最简单的办法就是令集群中的某个主节点进入下线状态，具体可以如下面操作：
首先，查看下当前集群的主节点：
$redis-cli -p 6379 cluster nodes | grep master
执行结果：
上图展示了目前集群共有6379,6380,6381三个主节点。
其次，向主节点6381发送debug segfault,让其下线：
$redis-cli -p 6381 debug segfault
执行结果：
Error: Server closed the connection
此时，主节点6381已经断开连接，已经下线了。
最后，查看下主从节点：
$redis-cli -p 6379 cluster nodes | grep master
执行结果：
由上图可以知道，当主节点6381下限故障之后，其拥有的从节点7381上升为主节点，而6381节点的类型不变，只是处于下限不能工作，这就是Redis集群中节点的主从故障自动转移了。
B、手动转移
有的时候在主节点没有任何问题的情况下，强制手动故障转移也是很有必要的，比如想要升级主节点的Redis进程，我们可以通过故障转移将其转为slave，再进行升级操作来避免对集群的可用性造成很大的影响。
Redis集群使用 CLUSTERFAILOVER命令来进行故障转移，不过要被转移的主节点的从节点上执行该命令，手动故障转移比主节点失败自动故障转移更加安全，因为手动故障转移时，客户端的切换是在确保新的主节点完全复制了失败的旧的主节点数据的前提下下发生的，所以避免了数据的丢失。
具体操作在后续文章中继续介绍，谢谢。
三、注意事项
1、从节点添加
在实际使用中，我们在添加主节点之后（分配slots之前），同时为其添加一个或多个从节点（从节点必须为空）。
2、主节点删除
在删除主节点时，必须确保该主节点为空，否则不能删除该节点，可以删除前将该节点的slots转移分配到其它节点，然后再行删除。
NOTE：
有人会疑惑，该主节点如果有从节点可以删除吗？答案是可以的，当该主节点被删除之后，其所有的从节点会被随机分配给其它的主节点，其继续保持从节点的身份。
3、故障转移
故障转移从主节点的多个从节点中选举了一个从节点，并将其升为主节点，使继续提供服务，那么如果故障的主节点恢复之后，节点的主从关系如何？答案是，以最新的分配角色为准，即升级为主节点的从节点，继续保持主节点身份，而恢复的旧主节点，其身份变为了从节点。
技术讨论群：
489451956（新）