11.1.4 高可用和异常测试
11.1.4.1 测试环境介绍
Master：192.168.2.128 （A）:6379 Slave：192.168.2.129 （B）:6379 Slave：192.168.2.130 （B）:6379 Sentinel：三台机器的26379端口
sentinel的消息可以通过sentinel日志（/redis/log/sentinel.log）以及sentinel:hello订阅此频道进行查看。
11.1.4.2 手动切换测试
集群情况，2.128为主
发起主动切换：
127.0.0.1:26379> sentinel failover mymaster OK
查看sentinel日志：
[1158] 19 Jun 08:14:38.504 # Executing user requested FAILOVER of 'mymaster' [1158] 19 Jun 08:14:38.507 # +new-epoch 29 [1158] 19 Jun 08:14:38.507 # +try-failover master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:38.581 # +vote-for-leader 7d60ccf8a9f9f81e5292a0dbde2c54c76a2bd265 29 [1158] 19 Jun 08:14:38.581 # +elected-leader master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:38.581 # +failover-state-select-slave master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:38.655 # +selected-slave slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:38.655 * +failover-state-send-slaveof-noone slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:38.714 * +failover-state-wait-promotion slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:39.642 # +promoted-slave slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:39.642 # +failover-state-reconf-slaves master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:39.705 * +slave-reconf-sent slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:40.645 * +slave-reconf-inprog slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:40.645 * +slave-reconf-done slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:40.735 # +failover-end master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:14:40.735 # +switch-master mymaster 192.168.2.129 6379 192.168.2.128 6379 [1158] 19 Jun 08:14:40.736 * +slave slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.128 6379 [1158] 19 Jun 08:14:40.743 * +slave slave 192.168.2.129:6379 192.168.2.129 6379 @ mymaster 192.168.2.128 6379 [1158] 19 Jun 08:27:56.524 # +new-epoch 30 [1158] 19 Jun 08:27:57.519 # +config-update-from sentinel 192.168.2.128:26379 192.168.2.128 26379 @ mymaster 192.168.2.128 6379 [1158] 19 Jun 08:27:57.519 # +switch-master mymaster 192.168.2.128 6379 192.168.2.129 6379 [1158] 19 Jun 08:27:57.519 * +slave slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:27:57.524 * +slave slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379
在2.129上看，集群已经切换过来：
11.1.4.3 主实例宕测试
接上，此时master为2.129，找出redis实例的pid，然后kill：
[root@hadoop2 log]# ps -ef |grep redis-server root 11349 1157 1 Jun18 ? 00:15:45 /usr/bin/redis-server 0.0.0.0:6379 root 14969 10433 0 08:33 pts/1 00:00:00 grep --color=auto redis-server [root@hadoop2 log]# kill 11349
此时查看sentinel日志：
[1158] 19 Jun 08:33:57.953 # +sdown master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.025 # +odown master mymaster 192.168.2.129 6379 #quorum 3/2 [1158] 19 Jun 08:33:58.025 # +new-epoch 31 [1158] 19 Jun 08:33:58.025 # +try-failover master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.028 # +vote-for-leader 7d60ccf8a9f9f81e5292a0dbde2c54c76a2bd265 31 [1158] 19 Jun 08:33:58.036 # 192.168.2.130:26379 voted for 7d60ccf8a9f9f81e5292a0dbde2c54c76a2bd265 31 [1158] 19 Jun 08:33:58.037 # 192.168.2.128:26379 voted for 7d60ccf8a9f9f81e5292a0dbde2c54c76a2bd265 31 [1158] 19 Jun 08:33:58.105 # +elected-leader master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.105 # +failover-state-select-slave master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.183 # +selected-slave slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.183 * +failover-state-send-slaveof-noone slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:58.267 * +failover-state-wait-promotion slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:59.039 # +promoted-slave slave 192.168.2.128:6379 192.168.2.128 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:59.040 # +failover-state-reconf-slaves master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:59.104 * +slave-reconf-sent slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:33:59.245 # -odown master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:34:00.082 * +slave-reconf-inprog slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:34:00.082 * +slave-reconf-done slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.129 6379 [1158] 19 Jun 08:34:00.193 # +failover-end master mymaster 192.168.2.129 6379 [1158] 19 Jun 08:34:00.193 # +switch-master mymaster 192.168.2.129 6379 192.168.2.128 6379 [1158] 19 Jun 08:34:00.194 * +slave slave 192.168.2.130:6379 192.168.2.130 6379 @ mymaster 192.168.2.128 6379 [1158] 19 Jun 08:34:00.200 * +slave slave 192.168.2.129:6379 192.168.2.129 6379 @ mymaster 192.168.2.128 6379 [1158] 19 Jun 08:34:03.319 # +sdown slave 192.168.2.129:6379 192.168.2.129 6379 @ mymaster 192.168.2.128 6379
从日志中可以看出已经切换到2.128，此时在2.128上看集群状态：
目前2.128为主，2.130为从，2.129上的redis宕掉。现在重启2.129上的redis实例，启动后该节点会从原先的主变为从，并对2.128进行同步，最后达到同步状态：
查看redis.conf和redis-sentinel.conf，发现都被改写。
11.1.4.4 单从实例宕测试
接上，2.129为从，此时杀掉该进程，redis.log日志记录如下：
[14984 | signal handler] (1434674492) Received SIGTERM scheduling shutdown... [14984] 19 Jun 08:41:32.545 # User requested shutdown... [14984] 19 Jun 08:41:32.545 * Calling fsync() on the AOF file. [14984] 19 Jun 08:41:32.545 * Saving the final RDB snapshot before exiting. [14984] 19 Jun 08:41:32.580 * DB saved on disk [14984] 19 Jun 08:41:32.580 # Redis is now ready to exit, bye bye...
此时集群正常提供对外服务，并不影响。
11.1.4.5 双从实例宕测试
接上，此时Master为2.128，还有一个活着的从2.130，集群状态如下：
此时，杀掉2.130的redis实例后，集群状态如下：
此时由于配置了最小slave个数为1，已经不满足，因此集群变为只读状态：
11.1.4.6 单sentinel宕测试
恢复集群状态，2.128为主，2.129、2.130为从。
11.1.4.7 双sentinel宕测试
恢复集群状态，2.128为主，2.129、2.130为从。此时，将2.128的sentinel和2.129的sentinel都宕掉。此时主从集群读写均正常。 在双方sentinel宕机时，杀掉master，主从集群切换失效，原因是因为设置sentinel 的quorum为2，最少有两个sentinel活集群才正常切换。
11.1.4.8 master所在主机整体宕测试
恢复集群状态，2.128为主，2.129、2.130为从。此时，对2.128进行宕机测试，直接关闭电源。 主从切换至2.130,从2.129指向新的主：
11.1.4.9 slave所在主机整体宕测试
恢复集群状态，2.128为主，2.129、2.130为从。此时直接关闭2.129，这时相当于一个redis slave进程和一个sentinel进程宕。主不受影响，并且感知到一个从已经宕机。
11.1.4.10 脑裂测试
恢复集群状态，2.128为主，2.129、2.130为从。首先进行一个从网络分离的测试：
另一种情况，如果将主机网络断开，剩余两个从成为一个新的集群，其中一个从（2.129）成为主：
原来的主机则为没有slave的主：
此时由于没有可用的slave，旧主无法写入（实际上由于网络断开也根本无法访问，因此从网络和数据库本身都不具有可写性）：
从上述两种情况测试，此架构不会导致双主对外服务，也不会因为网络恢复而数据混乱。
脑裂的场景还可以进行的一个测试时多个sentinel，例如下列架构（为了便于测试在两台机器上开多端口模拟多台机器）：
这个场景配置Quorum=3. 此时切断两台机器的通信网络（模拟两个机房之间通信中断），左边的机器（模拟主机房）集群不会受到影响，右边的机器（模拟灾备机房）由于不够大多数因此不会产生新的Master。
11.1.4.11 quorum测试
在一个如下的四节点环境中，
如果sentinel monitor的quorum设置为3，则宕机一台后再宕机，此时还剩余两台，存在两个sentinel，两个slave。由于quorum为3，而必须有>=max(quorum, num(sentinels)/2 +1) = max(3,2) = 3个sentinel都同意其中某一个sentinel主持failover，因此此时无sentinel可主持切换，因此测试表明，没有新的master被选出来，此时只能手动通过slaveof命令设置主从，并且手动切换（redis、sentinel和都应用不用重启）：
首先修改redis： 任意选取剩余的其中一个节点进行：slaveof no one 其他节点：slaveof 192.168.145.135 6379 找一个从节点上的sentinel，进入sentinel： redis-cli -p 26379 进行主动切换： sentinel failover mymaster 然后再在两个sentinel上重新发现集群： sentinel reset mymaster 检查集群状态。
如果sentinel monitor的quorum设置为2，则宕机一台后再宕机，此时还剩余两台，存在两个sentinel，两个slave。由于quorum为2，必须有>=max(quorum, num(sentinels)/2 +1)=max(2,2) =2个的sentinel都同意其中某一个sentinel主持failover，因此此时存在sentinel可主持切换，因此测试表明，新的master被选出来。
但是设置为2有一个危险就是如果出现如下的网络隔离状况：
集群就会脑裂，就会出现两个master。因此，生产上为了万无一失，宁可牺牲掉一定的高可用容错度也要避免脑裂。如果希望两台宕机依然可以切换，最好的方案不是降低quorum而是增多sentinel的个数，这个建议也是antirez在stackoverflow中回答一个人的提问时给的建议（http://stackoverflow.com/questions/27605843/redis-sentinel-last-node-doesnt-become-master#）。 如下场景测试：
11.1.4.12 Master hang死测试
由于我们的sentinel down-after-milliseconds为3100，即3.1s，因此在master上执行： debug sleep 3.0，系统不会切换，但是执行debug sleep 3.7或者更大的数值，系统就会判定为主sdown，进而变为odown随后发起投票切换。很难模拟取消odown的，因为时间差很短。
11.1.4.13 附：sentinel.conf被修改后的含义
port 26379 dir "/var/lib/redis/tmp" sentinel monitor mymaster 192.168.65.128 6379 2 sentinel config-epoch mymaster 18 ###确认mymater SDOWN时长 sentinel leader-epoch mymaster 18 ###同时一时间最多18个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务 sentinel known-slave mymaster 192.168.65.129 6379 ###已知的slave sentinel known-slave mymaster 192.168.65.130 6379 ###已知的slave sentinel known-sentinel mymaster 192.168.65.130 26379 be964e6330ee1eaa9a6b5a97417e866448c0ae40 ###已知slave的唯一id sentinel known-sentinel mymaster 192.168.65.129 26379 3e468037d5dda0bbd86adc3e47b29c04f2afe9e6 ###已知slave的唯一id sentinel current-epoch 18 ####当前可同时同步的salve数最大同步阀值
本文为《Redis开发运维实践指南》内容，该书作者为黄鹏程，已授权云栖社区转载。
