【Redis主从架构】Redis集群和哨兵集群的容灾测试

12. 【Redis主从架构】Redis集群和哨兵集群的容灾测试

1. 哨兵节点的增加和删除

1.1 增加sentinal，会自动发现

会基于master-slave的pub/sub机制，进行sentinal的发现

1.2 删除sentinal

1. 停止sentinal进程
2. SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态。
3. 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就真正的宕机了。

1. 三个哨兵进程都认为master是sdown了。

2. 超过quorum指定的哨兵进程都认为sdown之后，就变为odown了。

3. 哨兵1是被选举为要执行后续的主备切换的那个哨兵

4. 哨兵1去新的master(slave)获取一个新的config version

5. 尝试执行failover

6. 投票选举出一个salve区切换成master，每个哨兵都会执行一次投票。

7. 让slave，slaveof noone，不让它去做任何节点的slave；把slave提拔成master；旧的master认为不再是master了。

8. 哨兵就自动认为之前的102:6379变成slave，111:6379变成master了。

9. 哨兵去弹出以下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

参考石衫老师《亿级流量》课程笔记。