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