redis主从能加哨兵么 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.1
bind 127.0.0.1
#支持后台运行,默认值为no
daemonize yes
#日志文件,比如redis.log、sentinel.log
logfile xxx.log

（2）在Slave的redis.conf配置文件中新增加指定的master

#指定master
slaveof 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.conf
src/redis-server /usr/local/Master-Slave/redis-slave/slave.conf 
src/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, 则需要手工操作, 所以为了方便起见, 建议在故障转移之前备份配置文件.