环境准备

三台独立的linux主机

内网IP分别为: 172.31.175.142、172.31.175.143、172.31.175.144

分别创建带主目录的普通用户, 比如useradd wx -m

安装redis

分别在各个主机上安装redis,以172.31.175.142为例,步骤如下

#下载4.0稳定版

wget

#解压到用户主目录

tar -xzvf redis-4.0.11.tar.gz -C /home/wx

#进入用户主目录

cd /home/wx

#重命名解压的文件

mv redis-4.0.11 redis

#进入redis目录

cd redis

#编译

make

#安装,PREFIX指定安装路径

make PREFIX=/home/wx/redis install

主从/哨兵配置

一主(master)二从(slave)三哨兵(sentinel)的配置目标, 如下

redis.conf配置主从, sentinel.conf配置哨兵

conf里面很多初始的配置项可以不做修改, 对于需要修改或新增的配置项, 说明如下

通用配置

下面3项,务必在每个redis.conf里进行修改,在每个sentinel.conf里新增(默认没有)

#支持内网/本地访问,比如 bind 172.31.175.142 127.0.0.1

bind 本机内网IP 127.0.0.1

#支持后台运行,默认值为no

daemonize yes

#日志文件,比如redis.log、sentinel.log

logfile xxx.log

slave的配置

在2个slave的redis.conf下指定master

#指定master

slaveof 172.31.175.142 6379

sentinel的配置

在3个sentinel.conf下指定监控的master

#指定监控的master,最后一位表示quorum(法人数量),即认定master'客观下线'成立的最低票数

sentinel monitor mymaster 172.31.175.142 6379 2

主从/哨兵运行

分别启动主从redis, 验证没问题,再分别启动哨兵,假设已进入redis/bin目录

运行redis

1, 启动redis

./redis-server ../redis.conf

2, 查看日志

tail -100f ../redis.log

3, 连接redis

./redis-cli

4, 查看主从信息

cli连接redis成功后, 输入 info replication

下面是master的replication信息

下面是其中一个slave的replication信息

5, 测试主从同步

在master上写入变量, 在slave上查看是否同步, 此过程略.

运行哨兵

./redis-sentinel ../sentinel.conf

一个哨兵的日志如下, 可以看出哨兵正在监听,并已识别到2个slave

故障转移

模拟发生故障, 进入master主机172.31.175.142, kill掉redis-server进程.

接下来, 查看各个哨兵的日志, 大抵可以看出哨兵的工作过程, 如下

1, 主观下线(sdown)

当某个哨兵心跳检测master超时后,则认定其sdown

+sdown master mymaster 172.31.175.142 6379

2, 客观下线(odown)

当认定sdown的哨兵数>=quorum时,则master下线事实最终成立,即odown

+odown master mymaster 172.31.175.142 6379 #quorum 2/2

3, 选举哨兵leader

各哨兵协商,选举出一个leader,由其进行故障转移操作

+vote-for-leader 1dd7873228b4bf30c1668d55a28b3036072ee9de 1

4, 故障转移

选择一个slave作为新的master, 并将其他节点设置为新master的slave (刚才已下线的老master的配置文件也会被设置slaveof...)

+switch-master mymaster 172.31.175.142 6379 172.31.175.144 6379

当故障转移成功后, redis就是一主一从, 如下

主机 角色172.31.175.142哨兵、master172.31.175.143哨兵、slave172.31.175.144哨兵、slave -> master

进入新的master 172.31.175.144, 查看redis的主从信息, 还剩一从172.31.175.143

故障恢复

模拟故障恢复,进入老的master 172.31.175.142, 重启刚才kill掉的redis, 之后查看其主从信息, 发现老的master已经变成slave了,如下

//因为172.31.175.142的redis.conf在故障转移时被修改了,所以重启之后就直接成了slave

进入新的master 172.31.175.144下,再去查看最新的主从信息, 发现加入了新的slave, 如下

故障恢复之后, redis恢复到了一主二从三哨兵, 只不过master/slave换了地方, 如下

//若此时想要调整master/slave, 则需要手工操作, 所以为了方便起见, 建议在故障转移之前备份配置文件.