（十八）高并发redis学习笔记：哨兵模式的管理以及容灾演练实验

文章目录

• 1、哨兵节点的增加和删除
  • 1.1 增加sentinal
  • 1.2 删除sentinal
• 2、slave的永久下线
• 3、基于哨兵集群架构下的安全认证
• 4、容灾演练
  • 4.1 master发生故障
  • 4.2 故障恢复
• 5、哨兵的生产环境部署

1、哨兵节点的增加和删除1.1 增加sentinal

当我们增加哨兵的时候，会自动识别到并添加到其他的哨兵的发现信息中。

1.2 删除sentinal

（1）停止sentinal进程，我们选择第三台机器kill -9停掉


（2）SENTINEL RESET \*，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mymaster，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致

2、slave的永久下线

如果是某个slave下线，让master摘除某个已经下线的slave，在所有的哨兵上面执行。

SENTINEL RESET mymaster

3、基于哨兵集群架构下的安全认证

每个slave都有可能切换成master，所以每个实例都要配置两个指令。

• 在master上启用安全认证，requirepass
  -在slave配置master连接口令，masterauth

然后在sentinel的机器上配置认证的密码：是master名字，是密码。

sentinel auth-pass

4、容灾演练4.1 master发生故障

首先我们现在是启动了一主一从，加上三个哨兵，刚刚干掉了一个哨兵，注意重新启动。

通过哨兵看一下当前的master：

SENTINEL get-master-addr-by-name mymaster

把master节点kill -9掉，pid文件也删除掉。

查看sentinal的日志，是否出现+sdown字样，识别出了master的宕机问题; 然后出现+odown字样，就是指定的quorum哨兵数量，都认为master宕机了。

第二个哨兵的日志：

（1）三个哨兵进程都认为master是sdown了
（2）超过quorum指定的哨兵进程都认为sdown之后，就变为odown
（3）哨兵1是被选举为要执行后续的主备切换的那个哨兵
（4）哨兵1去新的master（slave）获取了一个新的config version
（5）尝试执行failover
（6）投票选举出一个slave区切换成master，每个哨兵都会执行一次投票
（7）让salve，slaveof noone，不让它去做任何节点的slave了; 把slave提拔成master; 旧的master认为不再是master了
（8）哨兵就自动认为之前的187:6379变成了slave了，19:6379变成了master了
（9）哨兵去探查了一下187:6379这个salve的状态，认为它sdown了

再通过哨兵看一下master：

SENTINEL get-master-addr-by-name mymaster

我们如果直接看配置也能看出来其实master已经改掉了。

我们连接到新的master看看：

本身成为master，没有slave连接上来。

4.2 故障恢复

故障恢复，再将旧的master重新启动，查看是否被哨兵自动切换成slave节点。

我们使用info replication查看信息,发现已经有slave连接上来了。

再查看master哨兵的信息：

在新的slave上执行，发现它确实切换成为slave了。

5、哨兵的生产环境部署

生产环境，不能启动的时候就把日志直接打出来，这样会有影����,����响，需要以后台进程运行，配置日志文件，日志文件夹我们需要先创建。

mkdir -p /var/log/sentinal/5000

修改配置5000.conf：

daemonize yeslogfile /var/log/sentinal/5000/sentinal.log

重新启动后，日志在日志文件中了：

查看哨兵信息，一切正常：

此文章仅代表自己（本菜鸟）学习积累记录，或者学习笔记，如有侵权，请联系作者删除。人无完人，文章也一样，文笔稚嫩，在下不才，勿喷，如果有错误之处，还望指出，感激不尽~

技术之路不在一时，山高水长，纵使缓慢，驰而不息。

公众号：秦怀杂货店