大型电商缓存框架-系统环境搭建-redis 哨兵模式配置以及主备切换测试

不说废话，上至少三台服务器，因为是选举机制，两台选也没啥意义

在安装的redis的安装目录下有个sentinel.conf配置文件

新建目录 /etc/sentinel（存放配置文件）/var/sentinel/5000（存放数据文件和日志），将sentinel.conf复制到 /etc/sentinel/下面，改名为5000.conf，5000是端口号，其他端口可以改为其他名称

编辑配置文件

#绑定为本机ip
bind vm001
#端口
port 5000
#后台运行，初次配置不建议先加这个参数，因为看日志不方便
daemonize yes
#数据存储位置
dir "/var/sentinel/5000"
#日志位置
logfile "/var/sentinel/5000/sentinel.log"
#监听的redis master的ip 端口 指定人数（多少个哨兵sdown之后变为odown）
sentinel monitor mymaster 192.168.1.254 6379 3
#连接master和slave时的密码
sentinel auth-pass mymaster 123456

其他几台服务器也这么搞，唯一变动的就是band参数要绑定为本机ip，启动第一个哨兵服务

[root@vm001 ~]# redis-sentinel /etc/sentinel/5000.conf

查看日志，我redis配置的是一台master+3台slave，sentinel启动日志会展示出redis的节点信息

 

启动其他几个个哨兵服务，查看第一个哨兵的日志，会提示有新的哨兵加入+sentinel

到现在四个哨兵服务已经启动完，整个哨兵服务搭建已完成，下面测试一下redis master节点故障后主备切换情况，首先看一下现在的主备情况

第一台 master节点，可以看到该节点是master节点，其他三台服务器是slave节点

[root@vm001 bin]# redis-cli -a 123456 -h vm001
vm001:6379> info replication
# Replication
role:master
connected_slaves:3
slave0:ip=192.168.1.252,port=6379,state=online,offset=225578,lag=1
slave1:ip=192.168.1.253,port=6379,state=online,offset=225298,lag=1
slave2:ip=192.168.1.254,port=6379,state=online,offset=225298,lag=1
master_repl_offset:225718
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:225717
vm001:6379> 

第二台 slave节点，可以看到该节点是slave（role:slave），master节点地址（master_host:192.168.1.199）以及master状态（master_link_status:up），其他几台slave节点信息是一样的

[root@vm002 ~]# redis-cli -h vm002 -a 123456
vm002:6379> info replication
# Replication
role:slave
master_host:192.168.1.199
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:227972
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
vm002:6379> 

下面使用kill命令杀掉master节点的redis模拟reids故障、

[root@vm001 bin]# ps -ef |grep redis
root      1105  1092  0 14:44 pts/2    00:00:00 tail -f /var/redis/6379/sentinel.log
root      1479     1  0 16:23 ?        00:00:00 redis-server vm001:6379          
root      1498     1  0 16:23 ?        00:00:00 redis-sentinel vm001:5000 [sentinel]  
root      1505  1016  0 16:24 pts/0    00:00:00 grep redis
[root@vm001 bin]# kill -9 1479

然后就会看到reids slave节点不断的提示连接异常

此时需要等待一段时间，等待哨兵检查到节点故障

几台服务器依次发现节点异常，提示sdown，当超过3个哨兵发现节点异常后出现odown，然后哨兵开始投票选举master，选完之后提拔选举的slave节点为master节点，之后将其他几个slave连接到新的master，最后哨兵再去检查一下挂掉的节点，确定确实是sdown了，到此主备切换已完成，然后看一下节点信息

发现master已经切换为了254，master下面挂有剩余的两个slave，然后在将之前故障的redis启动，模拟故障恢复

[root@vm001 ~]# redis-server /etc/redis/6379.conf 
[root@vm001 ~]# 

查看哨兵日志，发现其中一个哨兵输出了-sdown，并将原来的master转换为了slave

查看新的master节点的日志，发现数据已经同步到故障恢复节点上了

最后说明一下几个问题

1. 每个redis节点的requirepass必须设为一致
2. masterauth参数必须设置，即使是master节点，否则故障切换的时候，新加的配置没有这个参数（不知是我配置错了？）导致无法访问新的master