Redis 主从复制架构中出现宕机怎么办?以及哨兵功能

如果主从复制架构中出现宕机的情况,需要分情况看:

1. 从Redis宕机

  相对而言比较简单,Redis从库重新启动后会自动加入到主从架构中,自动完成同步数据;

  存在的问题是,如果从库在断开期间,主库变化不大,从库再启动后,主库依然会将所有的数据做RDB操作吗?还是增量更新?(从库在有做持久化的前提下)

    不会的,因为在Redis2.8版本后酒实现了,主从断线后恢复的情况下实现增量复制。

2. 主Redis宕机

  相对而言复杂一些,需要以下两个步骤才能完成

    第一步:在从数据库中执行SLAVE ON ONE 命令,断开主从关系并且提升为主库继续服务

    第二步:将主库重新启动后,执行SLAVEOF 命令,将其设置为其他库的从库,这是数据就能更新回来。

 

从上看出,主Redis宕机恢复较麻烦,并且容易出错,有没有更好的解决办法呢?当然有,Redis的哨兵(sentinel)功能

 

哨兵(Sentinel)

什么是哨兵

顾名思义,哨兵的作用就是对Redis的系统的运行情况进行监控,他是一个独立的进程。他的功能有两个:

1. 监控主库和从库是否运行正常

2. 主库出现故障后自动将从库转化为主库

 

原理:

单个哨兵的架构:

 

 多个哨兵的架构

 

 多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控。

 

环境处于一主多从的环境中

 

 配置哨兵

启动哨兵进程首选需要创建哨兵配置文件; 

vi sentinel.conf

写入配置:

sentinel monitor  RedisMaster 127.0.0.1 6379 1

说明:

MyMonitorMaster:监控主数据库的名称 ,自定义即可,可以使用大小姐字母和“.-_”符号
127.0.0.1:监控的主数据库的IP
6379:监控主数据库的端口
1:最低通过票数

启动哨兵:
redis-sentinel ../sentinel.conf

 

 上图信息:

1. 哨兵已经启动,id为6460dde23def7ac277edba60b0cec14e44b2aca7

2.为master添加一个监控

3.发现了一个slave,哨兵无需配置slave,只需要指定master,哨兵会自动发现slave

 

从库宕机模拟:

kill -9 掉从库的redis进程30秒后,哨兵控制台输出:

48013:X 29 Nov 2019 17:41:23.390 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

说明已经监控到slave宕机了,那么,我们将6380实例重新启动后,会自动加入主从复制么?

./redis-server ../redis.conf

48013:X 29 Nov 2019 17:44:30.178 * +reboot slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
48013:X 29 Nov 2019 17:44:30.257 # -sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

可以看出,slave从新加入主从复制中,-sdown:说明服务恢复。

主库宕机模拟:

 停止主Redis的进程:哨兵输出如下:

48013:X 29 Nov 2019 17:46:55.897 # +sdown master mymaster 127.0.0.1 6379   说明6379 master服务已经宕机 
48013:X 29 Nov 2019 17:46:55.897 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1  
48013:X 29 Nov 2019 17:46:55.897 # +new-epoch 1
48013:X 29 Nov 2019 17:46:55.897 # +try-failover master mymaster 127.0.0.1 6379   开始恢复故障
48013:X 29 Nov 2019 17:46:55.900 # +vote-for-leader 6460dde23def7ac277edba60b0cec14e44b2aca7 1  投票选举哨兵leader,现在就一个哨兵所以leader就是自己
48013:X 29 Nov 2019 17:46:55.900 # +elected-leader master mymaster 127.0.0.1 6379  选中leader
48013:X 29 Nov 2019 17:46:55.900 # +failover-state-select-slave master mymaster 127.0.0.1 6379  选中其中的一个slave当作master
48013:X 29 Nov 2019 17:46:55.973 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 选中6380
48013:X 29 Nov 2019 17:46:55.973 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379   发送slaveof no one命令
48013:X 29 Nov 2019 17:46:56.056 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 等待升级master
48013:X 29 Nov 2019 17:46:56.509 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379  升级6380为master
48013:X 29 Nov 2019 17:46:56.509 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
48013:X 29 Nov 2019 17:46:56.611 # +failover-end master mymaster 127.0.0.1 6379 故障恢复完成
48013:X 29 Nov 2019 17:46:56.611 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380 主数据库从6379转变为6380
48013:X 29 Nov 2019 17:46:56.611 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380 添加6379为6380的从库
48013:X 29 Nov 2019 17:47:13.013 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380  

 

 

 可以看出,目前,6380为master,拥有一个slave为6379

 

配置多个哨兵

vi sentinel.conf

输入内容:

sentinel monitor taotaoMaster 127.0.0.1 6381 2
sentinel monitor taotaoMaster2 127.0.0.1 6381 1

 

 

 

 





posted @ 2019-11-29 16:46  天蓝隐湘  阅读(1162)  评论(0编辑  收藏  举报