REDIS 哨兵 DOWN DOWN 灾难恢复方法记录
为什么近文章都开始在写灾难恢复，主要是DB TEAM 的每个DB 要掌握主机DOWN机后的恢复, 目前单位的虚拟机不是太稳定, 这边会遇到各种状况的DOWN ,可能是1 台可能是2台 可能全挂.
目前我们REDIS 的结构是哨兵 + VIP 的方式, 通过REDIS 的哨兵配合VIP 脚本的方式.
主要我们测试的几种故障的情况
1 一个从库DOWN
2 2个从库DOWN
3 主库DOWN
4 一主一从DOWN
5 全部DOWN
实验的机器主要
10.50.132.163 设置为主
10.50.132.164
10.50.132.165
1 一个从库DOWN机的情况下,如果程序并未指定此库为只读库的情况下不会影响业务
我们确认三台机器都是 redis 服务和 sentinel 服务都是工作中的.并且 VIP 也在主库上进行了登记
我们随机关闭一个从库 目前选择 10.50.132.165
相关的sential 服务会在其他的两台机器上 10.50.132.163 和 10.50.132.164 发现相关的 165 关闭的sdown 信息
但从库DOWN 机并不会影响整体的业务运行(假设,业务不会访问从库)
我们只需要恢复从库,将redis 和 sentinel 服务拉起
redis-server /usr/local/redis/etc/6379.conf
redis-sentinel /usr/local/redis/etc/sentinel.conf
并且在主库上访问 redis-cli 并且查看 info replication 项目中的连接数据库的情况
也可以通过sentinal 里面的信息判断整个集群的从库数量 和 sentinal 的数量
2 两个从库DOWN
此时主库继续工作
并且我们并未从sentinal 的日志中获得变化的信息, 这与sentinal 使用的raft协议有关,raft 需要大多数节点进行投票,而此时2个节点同时失效,则导致剩余的sentinal 没有任何响应.数据库仍然提供数据库服务, 我们仅仅需要重新启动两个从库的REDIS 和 sentinal 服务即可.
在启动redis 从库后我们会从主库的sentinal中看到两个从库sentinal 在主库sentinal中的日志信息.
然后在去主库,中键入 info replication, 会观察到 redis 的两个从库的信息
在这样的情况下仅仅需要将两个从库的服务拉起来 ,sentinal服务拉起来即可.
应用在两个从库DOWN的情况下,业务不会被影响.
3 主库DOWN
在REDIS 主库DOWN 之后, 会应该发生以下事件
1 REDIS 哨兵中会在选举出一个新的主库, 从已有的从库中选出
2 REDIS 会将VIP 从原主库 迁移至 新的主库中
VIP 已经从10.50.132.163 迁移到10.50.132.165 的新的REDIS 主库中
在从库中键入info replication 会查到新的主的redis 的地址 10.50.132.165
然后我们从相关的 10.50.132.164 中的 sentinal 信息中
在新主的sentinal 中会发现信息
1 主库 10.50.132.163 sdown
2431:X 17 May 2021 11:48:39.561 # -sdown sentinel 8b30336470b96b234f98248114735fdec027afcf 10.50.132.164 26379 @ mymaster 10.50.132.163 6379
2431:X 17 May 2021 13:10:21.871 # +sdown sentinel b552d809f176eb0e8470c9783f50f2362be52792 10.50.132.163 26379 @ mymaster 10.50.132.163 6379
2431:X 17 May 2021 13:10:22.009 # +sdown master mymaster 10.50.132.163 6379
开始进行选举活动
2431:X 17 May 2021 13:10:22.123 # +new-epoch 1
开始进行投票,选举出新的REDIS 的sentinal 的 leader ,并开始进行新主的提升的工作
2431:X 17 May 2021 13:10:22.124 # +vote-for-leader 8b30336470b96b234f98248114735fdec027afcf 1
2431:X 17 May 2021 13:10:22.518 # +config-update-from sentinel 8b30336470b96b234f98248114735fdec027afcf 10.50.132.164 26379 @ mymaster 10.50.132.163 6379
开始进行切换,将原163 主库迁移到 165
2431:X 17 May 2021 13:10:22.518 # +switch-master mymaster 10.50.132.163 6379 10.50.132.165 6379
重新写入新的从库信息
2431:X 17 May 2021 13:10:22.519 * +slave slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.165 6379
2431:X 17 May 2021 13:10:22.519 * +slave slave 10.50.132.163:6379 10.50.132.163 6379 @ mymaster 10.50.132.165 6379
然后在写入163 已经DOWN掉的信息
2431:X 17 May 2021 13:10:52.544 # +sdown slave 10.50.132.163:6379 10.50.132.163 6379 @ mymaster 10.50.132.165 6379
从另一个从库上看到的sentinal 的信息如下
从另一个从库中的sentinal 信息
接受到 163 DOWN
2363:X 17 May 2021 13:10:21.806 # +sdown sentinel b552d809f176eb0e8470c9783f50f2362be52792 10.50.132.163 26379 @ mymaster 10.50.132.163 6379
164 上的sentinal 发现并开始标注163 主观DOWN 客观 DOWN
2363:X 17 May 2021 13:10:22.072 # +sdown master mymaster 10.50.132.163 6379
获得 2票信息确认 163 已经DOWN机
2363:X 17 May 2021 13:10:22.134 # +odown master mymaster 10.50.132.163 6379 #quorum 2/2
剩下的工作主题是在这个SENTINAL进行的
2363:X 17 May 2021 13:10:22.134 # +new-epoch 1
开始进行主从的切换
2363:X 17 May 2021 13:10:22.134 # +try-failover master mymaster 10.50.132.163 6379
投票先出新的SENTINAL LEADER
2363:X 17 May 2021 13:10:22.136 # +vote-for-leader 8b30336470b96b234f98248114735fdec027afcf 1
2363:X 17 May 2021 13:10:22.139 # 56d6c01d3b27dff3552d63c0d211a77726e4c5a3 voted for 8b30336470b96b234f98248114735fdec027afcf 1
下面的过程为将 163 变为从库 ,然后提升165 为主库
2363:X 17 May 2021 13:10:22.191 # +elected-leader master mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.191 # +failover-state-select-slave master mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.243 # +selected-slave slave 10.50.132.165:6379 10.50.132.165 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.244 * +failover-state-send-slaveof-noone slave 10.50.132.165:6379 10.50.132.165 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.320 * +failover-state-wait-promotion slave 10.50.132.165:6379 10.50.132.165 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.467 # +promoted-slave slave 10.50.132.165:6379 10.50.132.165 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.467 # +failover-state-reconf-slaves master mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:22.531 * +slave-reconf-sent slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:23.123 * +slave-reconf-inprog slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:23.123 * +slave-reconf-done slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:23.195 # +failover-end master mymaster 10.50.132.163 6379
2363:X 17 May 2021 13:10:23.195 # +switch-master mymaster 10.50.132.163 6379 10.50.132.165 6379
2363:X 17 May 2021 13:10:23.195 * +slave slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.165 6379
2363:X 17 May 2021 13:10:23.195 * +slave slave 10.50.132.163:6379 10.50.132.163 6379 @ mymaster 10.50.132.165 6379
2363:X 17 May 2021 13:10:53.210 # +sdown slave 10.50.132.163:6379 10.50.132.163 6379 @ mymaster 10.50.132.165 6379
此时由于主库DOWN 机后整体业务不会受到影响, 但之前正在 163 工作的线程会报错,应用会报错.
现在我们开始恢复 163
redis-server /usr/local/redis/etc/6379.conf
redis-sentinel /usr/local/redis/etc/sentinel.conf
在执行如上命令后, 164 和 165 均发现了新加入的 163
登陆到新主165上确认 163
整体数据库redis sentinal 模式集群恢复完毕.
4 一主一从 DOWN
下面模拟一主一从down机, 将 主库 165 和 从库 164 关闭,
1 无法选出新的主, 并且IP 无法进行切换, 剩下的一台主机,作为从库运行
此时我们有两个可能性
1 两个机器立即可以启动并恢复
在两台机器恢复后,(先恢复原来为主的机器 10.50.132.165, 然后在恢复 10.50.132.164)
2 从10.50.132.163 上查看sentinal 日志信息
记录 165 sentinel Down 机
+sdown sentinel 56d6c01d3b27dff3552d63c0d211a77726e4c5a3 10.50.132.165 26379 @ mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:45:00.000 # +sdown master mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:45:02.009 # +sdown sentinel 8b30336470b96b234f98248114735fdec027afcf 10.50.132.164 26379 @ mymaster 10.50.132.165 6379
记录 10.50.132.164 Down机
11418:X 17 May 2021 13:45:02.145 # +sdown slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.165 6379
记录 10.50.132.165 启动
11418:X 17 May 2021 13:57:44.277 * +reboot master mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:57:44.332 # -sdown master mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:57:45.359 # -sdown sentinel 56d6c01d3b27dff3552d63c0d211a77726e4c5a3 10.50.132.165 26379 @ mymaster 10.50.132.165 6379
记录 10.50.132.164 启动
11418:X 17 May 2021 13:57:48.360 * +reboot slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:57:48.421 # -sdown slave 10.50.132.164:6379 10.50.132.164 6379 @ mymaster 10.50.132.165 6379
11418:X 17 May 2021 13:57:48.422 # -sdown sentinel 8b30336470b96b234f98248114735fdec027afcf 10.50.132.164 26379 @ mymaster 10.50.132.165 6379
从10.50.132.163 查看复制信息, 此时 165还为 整体REDIS sentinel 的主库.
我们在添加 VIP 到 10.50.132.165 上后
sudo /sbin/ip addr add 10.50.132.126/24 dev ens192
整体集群恢复完毕
2 两台机器无法理解启动并恢复
继续关闭 10.50.132.165 和 10.50.132.164 ,然后163 机器上的sentinel 会发现主库DOWN
此时为了保证业务持续运行, 需要将复制解体, 将集群变为单库运行.
只需要在10.50.132.163 上执行 SLAVEOF NO ONE
在 10.50.132.163 上配置 VIP
sudo /sbin/ip addr add 10.50.132.126/24 dev ens192
业务恢复
5 三台机器均挂机
首先三台机器挂掉后,业务会中断, 在等待三台机器恢复后,.重建集群
如果仅仅恢复一台机器 ,或者两台机器,可以按照第四中情况中的第二个方法进行单机的恢复.
这里我们先确认 10.50.132.165 为新的主节点 并在其上执行SLAVEOF NO ONE 的命令. 将其先变为单机, 然后在 10.50.132.164 163 两台机器上修改
redis 配置文件中的replicaof 变更IP地址改为 replicaof 10.50.132.165 6379
启动服务,
redis-server /usr/local/redis/etc/6379.conf
redis-sentinel /usr/local/redis/etc/sentinel.conf
数据库集群就恢复了.
这里注意, 如果是突然断点则REDIS 不保证即时在集群状态下的信息是完整的,可能会根据相关设置丢失1-2秒的数据.
另注: 如果AOF 文件损坏的情况下 ,需要通过 redis-check-aof --fix 来修复AOF 文件,让REDIS 正常启动.
下面通过一个思维导图来将上面的知识总结
相关文章