转自:http://blog.sina.com.cn/s/blog_4cfe78830101p031.html
此文章翻译redis.io上的原文章:http://redis.io/topics/sentinel
Redissentinel(哨兵)模块已经被集成在redis2.4+的版本中,尽管目前不是release,不过可以尝试去使用和了解,事实上sentinel还是有点复杂的.
一.环境部署
- ##redis.conf
- ##redis-0,默认为master
- port
6379 - ##授权密码,请各个配置保持一致
- requirepass
012_345^678-90 - masterauth
012_345^678-90 - ##暂且禁用指令重命名
- ##rename-command
- ##开启AOF,禁用snapshot
- appendonly
yes - save
“” - ##slaveof
no one - slave-read-only
yes
- ##redis.conf
- ##redis-1,通过启动参数配置为slave,配置文件保持独立
- port
6479 - slaveof
127.0.0.1 6379 - ##-----------其他配置和master保持一致-----------##
- ##redis.conf
- ##redis-1,通过启动参数配置为slave,配置文件保持独立
- port
6579 - slaveof
127.0.0.1 6379 - ##-----------其他配置和master保持一致-----------##
- ##redis-0
- ##sentinel实例之间的通讯端口
- port
26379 - sentinel
monitor def_master 127.0.0.1 6379 2 - sentinel
auth-pass def_master 012_345^678-90 - sentinel
down-after-milliseconds def_master 30000 - sentinel
can-failover def_master yes - sentinel
parallel-syncs def_master 1 - sentinel
failover-timeout def_master 900000
- ##redis-0(默认为master)
- >
./redis-server --include ../redis.conf - ##启动sentinel组件
- >
./redis-sentinel ../local-sentinel.conf
- >
./redis-cli -h 127.0.0.1 -p 6379 - ##如下为打印信息摘要:
- #Replication
- role:master
- connected_salves:2
- slave0:127.0.0.1,6479,online
- slave1:127.0.0.1.6579,online
二.sentinel原理
- SDOWN:subjectivelydown,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
- ODOWN:objectivelydown,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.
- 每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒)
- 在交互中,如果redis-server无法在"down-after-milliseconds"时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.
- 如果2)中SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送"is-master-down-by-addr"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinelmonitor",如果检测到master处于SDOWN状态的slave个数达到,那么此时此sentinel实例将会认为master处于ODOWN.
- 每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
- 经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.
三.Sentinel.conf详解
- ##sentinel实例之间的通讯端口
- ##redis-0
- port
26379 - ##sentinel需要监控的master信息:<mastername>
<masterIP> <masterPort> <quorum> - ##<quorum>应该小于集群中slave的个数,只有当至少<quorum>个sentinel实例提交"master失效"
- ##才会认为master为O_DWON("客观"失效)
- sentinel
monitor def_master 127.0.0.1 6379 2 -
- sentinel
auth-pass def_master 012_345^678-90 -
- ##master被当前sentinel实例认定为“失效”的间隔时间
- ##如果当前sentinel与master直接的通讯中,在指定时间内没有响应或者响应错误代码,那么
- ##当前sentinel就认为master失效(SDOWN,“主观”失效)
- ##<mastername>
<millseconds> - ##默认为30秒
- sentinel
down-after-milliseconds def_master 30000 -
- ##当前sentinel实例是否允许实施“failover”(故障转移)
- ##no表示当前sentinel为“观察者”(只参与"投票".不参与实施failover),
- ##全局中至少有一个为yes
- sentinel
can-failover def_master yes -
- ##当新master产生时,同时进行“slaveof”到新master并进行“SYNC”的slave个数。
- ##默认为1,建议保持默认值
- ##在salve执行salveof与同步时,将会终止客户端请求。
- ##此值较大,意味着“集群”终止客户端请求的时间总和和较大。
- ##此值较小,意味着“集群”在故障转移期间,多个salve向客户端提供服务时仍然使用旧数据。
- sentinel
parallel-syncs def_master 1 -
- ##failover过期时间,当failover开始后,在此时间内仍然没有触发任何failover操作,
- ##当前sentinel将会认为此次failoer失败。
- sentinel
failover-timeout def_master 900000 -
- ##当failover时,可以指定一个“通知”脚本用来告知系统管理员,当前集群的情况。
- ##脚本被允许执行的最大时间为60秒,如果超时,脚本将会被终止(KILL)
- ##脚本执行的结果:
- ##
1 -> 稍后重试,最大重试次数为10; - ##
2 -> 执行结束,无需重试 - ##sentinel
notification-script mymaster /var/redis/notify.sh -
- ##failover之后重配置客户端,执行脚本时会传递大量参数,请参考相关文档
- #
sentinel client-reconfig-script <master-name> <script-path>