1. Redis主从配置 1.1. 设置主从复制
Master <= Salve
10.24.6.5:6379 <= 10.24.6.7:6379
flushdb:删除这个db下的。
flushall:删除所有
Sentinel服务器地址:
10.24.6.7
启动
Redis-sentinel sentinel.conf
或者
Redis-server sentinel.conf –sentinel
Redis服务器:
Master <= Salve
10.24.6.5:6379 <= 10.24.6.7:6379
10.24.6.4:6379
10.24.6.6:6379
2.1. Sentinel客户端: 2.1.1. Redis-DeskopMaster
有两种方式，一种是通过配置文件，如何配置参考附录的sentinel.conf。这种方式主要是面向预配置的redis群集。
另外一种方式使用redis-cli做热配置：
127.0.0.1:26381> sentinel monitor mymaster 172.18.18.207 6501 1 OK
命令的格式如下：
SENTINEL MONITOR <name> <ip> <port> <quorum>
注：quorum表示发起failover需要的sentinel数量，看sentinel群集的数量决定。
从sentinel中删除群集，命令： 172.18.18.207:26381> sentinel remove mymaster OK
from redis.sentinel import Sentinel
sentinel = Sentinel([('10.24.6.7', 26379)], socket_timeout=0.1)
master = sentinel.master_for('10.24.6.5master', socket_timeout=0.1)
print master
master.set('foo', 'bar')
print master.get('foo')
首先解释2个名词:SDOWN和ODOWN.
SDOWN:subjectively down,直接翻译的为"主观"失效,即当前sentinel实例认为某个redis服务为"不可用"状态.
ODOWN:objectively down,直接翻译为"客观"失效,即多个sentinel实例都认为master处于"SDOWN"状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为"不可用",将会开启failover.
SDOWN适合于master和slave,但是ODOWN只会使用于master;当slave失效超过"down-after-milliseconds"后,那么所有sentinel实例都会将其标记为"SDOWN".
1) SDOWN与ODOWN转换过程:
每个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< ip> <port>"指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN...其他sentinel实例做同样的交互操作.配置项"sentinel monitor <mastername> <masterip> <masterport>< quorum>",如果检测到master处于SDOWN状态的slave个数达到<quorum>,那么此时此sentinel实例将会认为master处于ODOWN.
每个sentinel实例将会间歇性(10秒)向master和slaves发送"INFO"指令,如果master失效且没有新master选出时,每1秒发送一次"INFO";"INFO"的主要目的就是获取并确认当前集群环境中slaves和master的存活情况.
经过上述过程后,所有的sentinel对master失效达成一致后,开始failover.
2) Sentinel与slaves"自动发现"机制: