025. 对项目中的哨兵节点进行管理以及高可用 redis 集群的容灾演练

• redis slave 的永久下线
• slave 切换为 Master 的优先级
• 基于哨兵集群架构下的安全认证
• 容灾演练
• 哨兵的生产环境部署

哨兵节点的增加和删除

首先增加 sentinal 有自动发现功能，发现之后就把该哨兵信息添加到自己信息中了，这个可以通过一个实验来证明：

1. 上一章启动了 3 台 sentinal，

2. 在机器重启之后，只启动其中的一台机器

   [root@eshop-cache03 ~]# redis-sentinel /etc/sentinal/5000.conf
   

3. 连接上查看 sentinals 信息

   redis-cli -p 5000 -h eshop-cache03
   
   eshop-cache03:5000> sentinel sentinels mymaster
   会发现出现了 01 和 02 的信息，但是此时 01 和 02 并没有启动
   

4. 执行 SENTINEL RESET * 命令

   执行之后，再次查看 sentinel sentinels mymaster 信息，会发现变成空的了，消失了

删除 sentinal 的步骤

1. 停止 sentinal 进程

2. SENTINEL RESET * （重要）

   在所有存活的 sentinal 上执行，清理所有的 master 状态

3. SENTINEL MASTER mastername

   在所有存活的 sentinal 上执行，查看自己对 mastername 的集群信息是否与其他 sentinal 一致

redis slave 的永久下线

让 master 摘除某个已经下线的 slave：SENTINEL RESET mastername，在所有的哨兵上面执行

其实还是重置检查一下的有意思

slave 切换为 Master 的优先级

slave->master 选举优先级：slave-priority，值越小优先级越高

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

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

master 上启用安全认证，requirepass master 连接口令，masterauth

在 sentinal 的配置文件里面配置密码： sentinel auth-pass <master-group-name> <pass>

容灾演练

通过哨兵看一下当前的 master：SENTINEL get-master-addr-by-name mymaster

这里的 master 在 02 上面，直接 kill 掉 master；查看 哨兵的日志变化

[root@eshop-cache02 ~]# ps -ef | grep redis
root       960     1  2 01:00 ?        00:00:42 /usr/local/bin/redis-server 127.0.0.1:6379      
root      1049  1009  3 01:21 pts/0    00:00:26 redis-sentinel eshop-cache02:5000 [sentinel]
root      1068  1054  0 01:33 pts/1    00:00:00 grep redis
[root@eshop-cache02 ~]# kill 960

等待一会，该配置时间 sentinel down-after-milliseconds mymaster 30000 30 秒后， 可以看到哨兵日志发生了变化

注意：下面的日志是在切换 master 的哨兵上看到的。非切换的哨兵日志上不会有这么多信息

1037:X 24 Mar 01:55:05.525 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1037:X 24 Mar 01:55:05.525 # Sentinel ID is 507b3bc6e379011b990bda44b73221b8f7b305c1
1037:X 24 Mar 01:55:05.525 # +monitor master mymaster 192.168.99.171 6379 quorum 2
1037:X 24 Mar 01:55:15.551 * +convert-to-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:07.924 # +sdown master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.013 # +odown master mymaster 192.168.99.171 6379 #quorum 2/2
1037:X 24 Mar 01:57:08.013 # +new-epoch 3
1037:X 24 Mar 01:57:08.013 # +try-failover master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.027 # +vote-for-leader 507b3bc6e379011b990bda44b73221b8f7b305c1 3
1037:X 24 Mar 01:57:08.138 # a1cd62295346683bcd8f8b388ac64e83897a13dd voted for a1cd62295346683bcd8f8b388ac64e83897a13dd 3
1037:X 24 Mar 01:57:08.152 # d7a9812a3f905d07df46986f1b21388a16df39b4 voted for 507b3bc6e379011b990bda44b73221b8f7b305c1 3
1037:X 24 Mar 01:57:08.207 # +elected-leader master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.207 # +failover-state-select-slave master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.291 # +selected-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.291 * +failover-state-send-slaveof-noone slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.351 * +failover-state-wait-promotion slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.947 # +promoted-slave slave 192.168.99.170:6379 192.168.99.170 6379 @ mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.947 # +failover-state-reconf-slaves master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.979 # +failover-end master mymaster 192.168.99.171 6379
1037:X 24 Mar 01:57:08.982 # +switch-master mymaster 192.168.99.171 6379 192.168.99.170 6379
1037:X 24 Mar 01:57:08.983 * +slave slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379
1037:X 24 Mar 01:57:39.038 # +sdown slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379

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. 哨兵就自动认为之前的 171:6379 变成了 slave 了，190:6379 变成了 master 了
9. 哨兵去探查了一下 171:6379 这个 salve 的状态，认为它 sdown 了

此时再查看 /etc/sentinal/5000.conf 中的配置文件的时候，会发现一些配置跟着改变了，比如

# 最开始我们配置的是 hostname，这里被更新成了 ip
sentinel monitor mymaster 192.168.99.170 6379 2

将旧的 master 重新启动，查看变化

[root@eshop-cache02 ~]# /etc/init.d/redis_6379 start
/var/run/redis_6379.pid exists, process is already running or crashed
[root@eshop-cache02 ~]# rm -rf /var/run/redis_6379.pid
[root@eshop-cache02 ~]# /etc/init.d/redis_6379 start
Starting Redis server...
[root@eshop-cache02 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave      // 这里，重启之后变成了 slave
master_host:192.168.99.170
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:1160
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

看看之前执行故障转移的哨兵日志

# sdown 状态变成了减号
1037:X 24 Mar 02:09:43.363 # -sdown slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379
# 并且转换成了 slave
1037:X 24 Mar 02:09:53.373 * +convert-to-slave slave 192.168.99.171:6379 192.168.99.171 6379 @ mymaster 192.168.99.170 6379

小结：

1. 手动杀掉master
2. 哨兵能否执行主备切换，将 slave 切换为 master
3. 哨兵完成主备切换后，新的 master 能否使用
4. 故障恢复，将旧的 master 重新启动
5. 哨兵能否自动将旧的 master 变为 slave，挂接到新的 master 上面去，而且也是可以使用的

哨兵的生产环境部署

在 /etc/sentinal/5000.conf 中增加两个配置

# 后台启动
daemonize yes
# 把日志打印到指定位置
logfile /var/log/sentinal/5000/sentinal.log

记得要把目录创建好

mkdir -p /var/log/sentinal/5000