redis主从哨兵搭建
1. 为什么要有哨兵机制
哨兵机制是对Redis系统的运行情况的监控，解决主从复制的缺点的。
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
作用：
a、 监控主数据库和从数据库是否运行正常；b、 主数据出现故障后自动将从数据库转化为主数据库
2.redis Sentinel模式配置
一主(master)二从(slave)三哨兵(sentinel)的配置目标
sentinel master 6380
sentinel slave 6381
sentinel slave 6382
2.1 复制3个哨兵节点
cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6380.conf
cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6381.conf
cp -a /usr/local/redis40/sentinel.conf /usr/local/redis-sentinel/sentinel-6382.conf
2.2 conf配置项
（1）下面3项,务必在每个redis.conf里进行修改,在每个sentinel.conf里新增(默认没有)
#支持内网/本地访问,比如 bind 192.168.1.100/127.0.0.1bind 127.0.0.1#支持后台运行,默认值为nodaemonize yes#日志文件,比如redis.log、sentinel.loglogfile xxx.log
（2）在Slave的redis.conf配置文件中新增加指定的master
#指定masterslaveof 127.0.0.1 6380
（3）在每个sentinel的配置增加指定监控的master
#指定监控的master,最后一位表示quorum(法人数量),即认定master'客观下线'成立的最低票数sentinel monitor mymaster 127.0.0.1 6380 2
2.3 启动事例
分别启动主从redis, 验证没问题,再分别启动哨兵
(1)启动redis事例
src/redis-server /usr/local/Master-Slave/redis-master/master.confsrc/redis-server /usr/local/Master-Slave/redis-slave/slave.confsrc/redis-server /usr/local/Master-Slave/redis-slave2/slave2.conf
(2)连接客户端查看主从配置信息
启动三个redis客户端
[root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6380[root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6381[root@localhost redis40]# ./src/redis-cli -h 127.0.0.1 -p 6382
（3）查看主从信息 info replication
(4)测试主从同步
在6380上写入信息
分别在6381和6382上取数据
2.4 运行哨兵
./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26380.conf./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26381.conf./src/redis-sentinel /usr/local/redis-sentinel/sentinel-26382.conf
查看哨兵监控日志(26380,26381,26382)
2.5故障转移
模拟故障发生, 进入master主机127.0.0.1:6380, kill掉redis-server进程.
查看各个哨兵的日志, 哨兵的工作过程, 如下
1, 主观下线(sdown)
当某个哨兵心跳检测master超时后,则认定其sdown
+sdown master mymaster 127.0.0.1 6380
2, 客观下线(odown)
当认定sdown的哨兵数>=quorum时,则master下线事实最终成立,即odown
+odown master mymaster 172.31.175.142 6380 #quorum 2/2
3, 选举哨兵leader
各哨兵协商,选举出一个leader,由其进行故障转移操作
+vote-for-leader a30f83f1c2cd2c71beba4d390cf670c7b83c77f1 1
4, 故障转移
选择一个slave作为新的master, 并将其他节点设置为新master的slave (刚才已下线的老master的配置文件也会被设置slaveof…)
+switch-master mymaster 127.0.0.1 6380 127.0.0.1 6382
当故障转移成功后, redis就是一主一从, 如下
| 主机 | 角色 |
| 6380 | 哨兵、master |
| 6381 | 哨兵、slave |
| 6382 | 哨兵、slave -> master |
进入新的master 127.0.0.1:6382, 查看redis的主从信息, 还剩一从127.0.0.1:6381
2.6故障恢复
模拟故障恢复,进入老的master 127.0.0.1:6380, 重启刚才kill掉的redis, 之后查看其主从信息, 发现老的master已经变成slave了,如下
因为172.0.0.1:6380的redis.conf在故障转移时被修改了,所以重启之后就直接成了slave
进入新的master 127.0.0.1:6382下,再去查看最新的主从信息, 发现加入了新的slave, 如下
故障恢复之后, redis恢复到了一主二从三哨兵, 只不过master/slave换了地方, 如下
sentinel slave 6380
sentinel master 6382
sentinel slave 6381
注：若此时想要调整master/slave, 则需要手工操作, 所以为了方便起见, 建议在故障转移之前备份配置文件.
比眉伴天荒
ゞ 浴缸里的玫瑰
傷城~
还没有评论，来说两句吧...