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 正常启动.

下面通过一个思维导图来将上面的知识总结