Sentinel验证

测试Failover

我们让dev-master-01主机上的redis-master主动休眠30秒来观察failover过程：

$ redis-cli -p 6379 -h 192.168.2.210 -a 000000 DEBUG sleep 30

我们可以看到每个Sentinel进程都监控到Master挂掉，从sdown状态进入odown，然后选举了一个leader来进行failover，最终192.168.2.212成为新的Master， Sentinel的日志输出：

日志的几个主要事件

在Redis Master角色上主要有以下几个事件：

在Redis Slave角色上主要有以下几个事件：

 

Redis Slave上大多数都和Redis Master上的事件类似，不同的是Redis Slave还多了一步配置更新。

+config-update-from sentinel 192.168.2.210:26379 192.168.2.210 26379 @ redis-master 192.168.2.210 6379

查看Sentinel配置文件变更

经过一次failover后，会发现Sentinel配置文件变更了以下一些内容。可以看到Sentinel将最新的集群状态写入了配置文件。

$ cat /etc/redis/sentinel.conf # Generated by CONFIG REWRITE maxclients 4064 sentinel leader-epoch redis-master 1 sentinel known-slave redis-master 192.168.2.211 6379 sentinel known-slave redis-master 192.168.2.210 6379 sentinel known-sentinel redis-master 192.168.2.212 26379 bbf85fae74692d9527e77c5b0bb83a2b5db40dd2 sentinel known-sentinel redis-master 192.168.2.210 26379 2b2446b24a2bd01b9f54a6b2ca4f945a3480dd7e sentinel current-epoch 1

验证下三台主机上的角色

dev-node-02

以下输出信息，表明192.168.2.212上的Redis是Master角色。

$ redis-cli -p 6379 -h 192.168.2.212 -a 000000 info Replication # Replication role:master connected_slaves:2 slave0:ip=192.168.2.211,port=6379,state=online,offset=2312008,lag=0 slave1:ip=192.168.2.210,port=6379,state=online,offset=2312008,lag=0 master_repl_offset:2312008 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1639828 repl_backlog_histlen:672181

dev-master-01

以下输出信息，表明192.168.2.210上的Redis是Slave角色。

$ redis-cli -p 6379 -h 192.168.2.210 -a 000000 info Replication # Replication role:slave master_host:192.168.2.212 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:2222825 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:593455 repl_backlog_histlen:1048576

dev-node-01

以下输出信息，表明192.168.2.211上的Redis是Slave角色。

$ redis-cli -p 6379 -h 192.168.2.211 -a 000000 info Replication # Replication role:slave master_host:192.168.2.212 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:2283392 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 Sentinel日常运维 Sentinel常用命令

以下列出的是Sentinel接受的命令：

增加和移除监控以及修改配置参数 SENTINEL MONITOR <name> <ip> <port> <quorum> SENTINEL REMOVE <name> SENTINEL SET <name> <option> <value>

增加和移除Sentinel

增加新的Sentinel实例非常简单，修改好配置文件，启动即可，其他Sentinel会自动发现该实例并加入集群。如果要批量启动一批Sentinel节点，最好以30秒的间隔一个一个启动为好，这样能确保整个 Sentinel集群的大多数能够及时感知到新节点，满足当时可能发生的选举条件。

移除一个Sentinel实例会相对麻烦一些，因为Sentinel不会忘记已经感知到的Sentinel实例，所以最好按照下列步骤来处理：

生产环境推荐

对于一个最小集群，Redis应该是一个Master带上两个Slave，并且开启下列选项：

min-slaves-to-write 1 min-slaves-max-lag 10

这样能保证写入Master的同时至少写入一个Slave，如果出现网络分区阻隔并发生failover的时候，可以保证写入的数据最终一致而不是丢失，写入老的Master会直接失败。

Slave可以适当设置优先级，除了0之外(0表示永远不提升为Master)，越小的优先级，越有可能被提示为Master。如果Slave分布在多个机房，可以考虑将和Master同一个机房的Slave的优先级设置的更低以提升他被选为新的Master的可能性。

考虑到可用性和选举的需要，Sentinel进程至少为3个，推荐为5个。如果有网络分区，应当适当分布(比如2个在A机房， 2个在B机房，一个在C机房)等。

客户端实现

客户端从过去直接连接Redis ，变成：