Redis哨兵模式（sentinel）部署

1 主机环境

我这里使用的操作系统是centos 6.5，安装在vmware上，共三台。

主机名	IP	操作系统	用户名	安装目录
node1	192.168.1.101	centos 6.5	wxyuan	/redis
node2	192.168.1.102	centos 6.5	wxyuan	/redis
node3	192.168.1.103	centos 6.5	wxyuan	/redis

2 进程端口规划

node1	node2	node3
redis，6379	redis，6379	redis，6379
sentinel，26379	sentinel，26379	sentinel，26379

redis下载地址：http://download.redis.io/releases/，选择需要的版本下载，我使用的版本是redis-3.2.1.tar.gz

3 安装redis

3.1 检查是否安装了gcc

[wxyuan@node1 ~]$ rpm -qa|grep gcc
libgcc-4.4.7-4.el6.x86_64
gcc-4.4.7-4.el6.x86_64
gcc-c++-4.4.7-4.el6.x86_64

如果未安装，可使用yum install gcc 命令安装

3.2 编译安装redis

(1). 解压redis安装包tar -zxvf redis-3.2.1.tar.gz

(2). 编译安装redis

[wxyuan@node1 ~]$ cd redis-3.2.1
[wxyuan@node1 ~]$ make
[wxyuan@node1 ~]$ make install PREFIX=/redis # PREFIX指定安装目录

安装完成后，在/redis目录下会新增bin目录，这里面是启动redis服务的相关脚本。

创建/redis/conf、/redis/data、/redis/log目录。

3.3 修改配置文件redis.conf

拷贝redis-3.2.1/redis.conf文件到/redis/conf目录下，编辑/redis/conf/redis.conf文件

node1主机上修改内容如下

bind 192.168.1.101 127.0.0.1 #绑定多个IP，既可以远程访问，也可以本地客户端访问
port 6379 #指定端口
appendonly yes #开启aof持久化
daemonize yes
pidfile "/redis/redis_6379.pid"
logfile "/redis/log/redis_6379.log"
dir "/redis/data"

node2主机上修改内容如下

bind 192.168.1.102 127.0.0.1 #绑定多个IP，既可以远程访问，也可以本地客户端访问
port 6379 #指定端口
appendonly yes #开启aof持久化
daemonize yes
pidfile "/redis/redis_6379.pid"
logfile "/redis/log/redis_6379.log"
dir "/redis/data"
slaveof 192.168.1.101 6379

node3主机上修改内容如下

bind 192.168.1.103 127.0.0.1 #绑定多个IP，既可以远程访问，也可以本地客户端访问
port 6379 #指定端口
appendonly yes #开启aof持久化
daemonize yes
pidfile "/redis/redis_6379.pid"
logfile "/redis/log/redis_6379.log"
dir "/redis/data"
slaveof 192.168.1.101 6379

3.4 增加配置文件sentinel.conf

在/redis/conf下增加配置文件sentinel.conf，文件内容为：

node1主机上内容如下

bind 192.168.1.101
port 26379
daemonize yes
logfile "/redis/log/sentinel.log"
dir "/redis/data"
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

node2主机上内容如下

bind 192.168.1.102
port 26379
daemonize yes
logfile "/redis/log/sentinel.log"
dir "/redis/data"
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

node3主机上内容如下

bind 192.168.1.103
port 26379
daemonize yes
logfile "/redis/log/sentinel.log"
dir "/redis/data"
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

部分参数说明：

(1) sentinel monitor <masterName> <ip> <port> <quorum>

-masterName 指定maser的名字

-ip 指定master的IP

-port 指定maseter的端口

-quorum quorum是Sentinel需要协商同意master是否可到达的数量。为了真正的标记slave为失败，并最终是否需要启动一个故障转移进程。无论怎样，quorum只用于检测故障。为了实际执行故障转移，Sentinel需要选举leader并进行授权。这只发生在大多数Sentinel进程的选举。

(2) down-after-milliseconds选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。

如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下（subjectively down，简称 SDOWN ）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。

(3) parallel-syncs选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

关于sentinel的详细配置说明请参考Sentinel配置详解

4 启动redis和sentinel

在三台主机上分别执行下述命令，启动redis服务和sentinel服务

[wxyuan@node1 ~]$ cd /redis
[wxyuan@node1 redis$ ./bin/redis-server conf/redis.conf
[wxyuan@node1 redis$ ./bin/redis-sentinel conf/sentinel.conf

5 故障转移测试

在node1使用redis-cli命令查看主从信息

[wxyuan@node1 redis]$ ./bin/redis-cli -p 6379 info replication
# Replication
role:master
connected_slaves:2

可以看到node1上的redis进程为master，现在kill掉node1上的redis进程，观察故障转移情况。

使用redis-cli命令查看主从信息

[wxyuan@node1 redis]$ ./bin/redis-cli -p 6379 -h 192.168.1.102 info replication
# Replication
role:master
connected_slaves:1
slave1:ip=192.168.1.103,port=6379,state=online,offset=13836,lag=1

[wxyuan@node1 redis]$ ./bin/redis-cli -p 6379 -h 192.168.1.103 info replication
# Replication
role:slave
master_host:192.168.1.102
master_port:6379

可以看到node2上的redis进程已经变成了master。重启node1上的redis进程后，会发现该redis进程已经变成了slave。

另外，可以通过sentinel.log文件观察故障转移过程。

注意：此时打开sentinel文件，会发现内容已经被改变了；sentinel进程启动后，会根据redis进程的运行情况修改sentinel.conf文件内容。