12. 【Redis主从架构】Redis集群和哨兵集群的容灾测试
1. 哨兵节点的增加和删除
1.1 增加sentinal，会自动发现
会基于master-slave的pub/sub机制，进行sentinal的发现
1.2 删除sentinal
- 停止sentinal进程
- SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态。
- SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
2. slave的永久下线
让 master 摘除某个已经下线的 slave：SENTINEL RESET mastername，那么，在所有的哨兵节点上执行
3. slave切换成master的优先级
slave -> master选举优先级：slave-priority，值越小优先级越高。
4. 基于哨兵集群架构的安全认证
每个slave都有可能切换成master，所以每个实例都要配置两个指令：
master上启用安全认证：requirepass
master连接口令，masterauth
sentinal, sentinel auth-pass <master-group-name> <pass>
5. 容灾演练
- 通过哨兵查看一下当前的master：
SENTINEL get-master-addr-by-name mymaster
- 将master的节点kill掉，pid文件也删除掉。
- 查看sentinal的日志，是否出现+sdown字样，失败处理master的宕机问题；然后出现+odown字样，就是指定的quorum哨兵数量，都认为master宕机了，master就真正的宕机了。
-
三个哨兵进程都认为master是sdown了。
-
超过quorum指定的哨兵进程都认为sdown之后，就变为odown了。
-
哨兵1是被选举为要执行后续的主备切换的那个哨兵
-
哨兵1去新的master(slave)获取一个新的config version
-
尝试执行failover
-
投票选举出一个salve区切换成master，每个哨兵都会执行一次投票。
-
让slave，slaveof noone，不让它去做任何节点的slave；把slave提拔成master；旧的master认为不再是master了。
-
哨兵就自动认为之前的102:6379变成slave，111:6379变成master了。
-
哨兵去弹出以下102:6379这个slave的状态，认为他sdown了。
所有哨兵短句出了一个，来执行主备切换操作
如果哨兵的majority都存活着，那就会执行主备切换操作。
再通过哨兵看一下：SENTINEL get-master-addr-by-name mymaster
- 发现mster节点由原来的 192.168.0.103节点变成了 192.168.0.104 节点
尝试连接以下新的master(192.168.0.104)
故障恢复，在将旧的master重新启动，查看是否被哨兵启动切换成slave节点。
- 总结
1. 手动杀掉master
2. 哨兵能否执行主备切换，将slave切换为master
3. 哨兵完成主备切换后，新的master能否使用
4. 故障恢复，将旧的master启动。
5. 哨兵能否自动将旧的master变成slave节点挂载到新的master节点上面去，而且也是可以使用的。
6. 哨兵的生产环境部署
daemonize yes
logfile /var/log/sentinal/5000
mkdir -p /var/log/sentinal/5000
参考石衫老师《亿级流量》课程笔记。