Redis入门指南之哨兵

[导读]Redis复制的原理和使用方式，在一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数

Redis复制的原理和使用方式，在一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。

当主数据库遇到异常中断服务后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入。为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

1.监控主数据库和从数据库是否正常运行。

2.主数据库出现故障时自动将从数据库转换为主数据库。

在一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健，此时不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监控。

配置哨兵

[root@TA30-53 redis_master]# vi sentinel.conf

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 123456

其中mymaster表示要监控的主数据库的名字，可以自定义。这个名字必须仅由大小写字母、数字和“.-_”这 3 个字符组成。

后两个参数表示主数据库的地址和端口。

最后的1表示最低通过票数。

接下来执行来启动Sentinel进程，并将上述配置文件的路径传递给哨兵：

[root@TA30-53 local]# cd redis_master/src/
[root@TA30-53 src]# ./redis-sentinel ../sentinel.conf

配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。

启动哨兵后，哨兵输出如下内容：

[root@TA30-53 redis_master]# ./src/redis-sentinel ./sentinel.conf  
30327:X 26 Jun 16:49:08.340 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.0.7 (00000000/0) 64 bit
  .-`` .-```.  ```/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 30327
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

30327:X 26 Jun 16:49:08.342 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
30327:X 26 Jun 16:49:08.342 # Sentinel runid is 9bcfa5e06a5218120fb698fb41fce1cc7dc41251
30327:X 26 Jun 16:49:08.342 # +monitor master mymaster 127.0.0.1 6379 quorum 1
30327:X 26 Jun 16:49:08.353 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
30327:X 26 Jun 16:49:08.354 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

其中+slave 表示新发现了从数据库。

现在哨兵已经在监控这3个Redis实例了，这时我们将主数据库（即运行在6379端口上的Redis实例）关闭，等待指定时间后（可以配置，默认为 30 秒），哨兵会输出如下内容：

30553:X 26 Jun 16:58:52.100 # +sdown master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.100 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1

+sdown表示哨兵主观认为主数据库停止服务了，+odown则表示哨兵客观认为主数据库停止服务了。

此时哨兵开始执行故障恢复，即挑选一个从数据库，将其升格为主数据库。同时输出如下内容：

30553:X 26 Jun 16:57:45.646 # Sentinel runid is cbf8017edb7e379fef7d2984be1d2a22c95f7835
30553:X 26 Jun 16:57:45.646 # +monitor master mymaster 127.0.0.1 6379 quorum 1
30553:X 26 Jun 16:58:52.100 # +sdown master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.100 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
30553:X 26 Jun 16:58:52.100 # +new-epoch 1
30553:X 26 Jun 16:58:52.100 # +try-failover master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.109 # +vote-for-leader cbf8017edb7e379fef7d2984be1d2a22c95f7835 1
30553:X 26 Jun 16:58:52.109 # +elected-leader master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.109 # +failover-state-select-slave master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.171 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.171 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:52.243 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:53.163 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:53.163 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:53.246 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:54.211 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:55.240 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:55.331 # +failover-end master mymaster 127.0.0.1 6379
30553:X 26 Jun 16:58:55.331 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
30553:X 26 Jun 16:58:55.331 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
30553:X 26 Jun 16:58:55.331 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
30553:X 26 Jun 16:59:25.352 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

+try-failover表示哨兵开始进行故障恢复，

+failover-end表示哨兵完成故障恢复，期间涉及领头哨兵的选举、备选从数据库的选择等

+switch-master表示主数据库从6379迁移到6381，即6381的从数据库被升为主数据库，同时两个+slave则列出了新的主数据库的两个从数据库，为6380和6379。

6379就是之前停止服务的主数据库，停止服务了，而6381端口的从数据库已经升为主数据库，当6379端口的实例恢复服务后，会转变为6381端口实例的从数据库来运行，所以哨兵将6379端口实例的信息修改成了6381端口实例的从数据库。

故障恢复完成后，可以使用Redis命令行客户端重新检查6380和6381两个端口上的实例的复制信息：

[root@TA30-53 local]# ./redis_slave1/src/redis-cli -p 6380 -a 123456
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:54239
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

[root@TA30-53 redis_slave2]# ./src/redis-cli -p 6381 -a 123456 info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=57634,lag=1
master_repl_offset:57767
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:57766

可以看到6381端口上的实例已经确实升格为主数据库了，同时6380端口上的实例是其从数据库。整个故障恢复过程就此完成。

此时将6379端口上的实例重新启动，

[root@TA30-53 local]# ./redis_master/src/redis-server ./redis_master/redis.conf

哨兵会监控到这一变化，并输出：

30553:X 26 Jun 17:17:07.568 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
30553:X 26 Jun 17:17:17.528 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

-sdown表示实例6379已经恢复服务了（与+sdown相反），

+convert-to-slave表示将6379端口的实例设置为6381端口实例的从数据库。

这时使用Redis命令行客户端查看6379端口实例的复制信息为：

[root@TA30-53 local]# ./redis_master/src/redis-cli -p 6379 -a 123456 info replication            
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1498469302
slave_priority:100
slave_read_only:1
connected_slaves:0
min_slaves_good_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

同时6381端口实例的复制信息为：

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=8683,lag=0
master_repl_offset:8683
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:8682

为什么不是俩，后面再研究。。。。

原理

一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：

sentinel monitor master-name ip redis-port quorum

其中 master-name 是一个由大小写字母、数字和“.-_”组成的主数据库的名字，

考虑到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可以通过主数据库的名字获取当前系统的主数据库的地址和端口号。

ip 表示当前系统中主数据库的地址，redis-port 表示端口号，quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意。

一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个sentinel monitor配置即可，例如：

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel monitor othermaster 192.168.1.3 6380 4

同时多个哨兵节点也可以同时监控同一个 Redis 主从系统，从而形成网状结构。

哨兵启动后，会与要监控的主数据库建立两条连接，这两个连接的建立方式与普通的Redis客户端无异。其中一条连接用来订阅该主数据的__sentinel__:hello频道以获取其他同样监控该数据库的哨兵节点的信息，另外哨兵也需要定期向主数据库发送 INFO 等命令来获取主数据库本身的信息

和主数据库的连接建立完成后，哨兵会定时执行下面3个操作。（1）每10秒哨兵会向主数据库和从数据库发送INFO命令。（2）每 2 秒哨兵会向主数据库和从数据库的__sentinel__:hello 频道发送自己的信息。（3）每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。

首先，发送INFO命令使得哨兵可以获得当前数据库的相关信息（包括运行ID、复制信息等）从而实现新节点的自动发现。

配置哨兵监控 Redis 主从系统时只需要指定主数据库的信息即可，哨兵借助 INFO 命令来获取所有复制该主数据库的从数据库信息的。

启动后，哨兵向主数据库发送 INFO 命令，通过解析返回结果来得知从数据库列表，而后对每个从数据库同样建立两个连接，两个连接的作用和前文介绍的与主数据库建立的两个连接完全一致。在此之后，哨兵会每 10 秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据库的角色变化（由故障恢复操作引起）进行信息更新等。

接下来哨兵向主从数据库的__sentinel__:hello 频道发送信息来与同样监控该数据库的哨兵分享自己的信息。

发送的消息内容为：

可以看到消息包括的哨兵的基本信息，以及其监控的主数据库的信息。哨兵会订阅每个其监控的数据库的__sentinel__:hello频道，所以当其他哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。如果是则将其加入已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送 PING命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其他哨兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版本高，则更新主数据库的数据。

实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。

每隔一定时间向这些节点发送PING命令。

时间间隔与down-after-milliseconds选项有关，当down-after-milliseconds的值小于1秒时，哨兵会每隔down-after-milliseconds指定的时间发送一次PING命令，

当down-after-milliseconds的值大于1秒时，哨兵会每隔1秒发送一次PING命令。

例如：

//每隔 1 秒发送一次 PING命令

sentinel down-after-milliseconds mymaster 60000

//每隔 600 毫秒发送一次 PING命令

sentinel down-after-milliseconds othermaster 600

当超过down-after-milliseconds选项指定时间后，如果被PING的数据库或节点仍然未进行回复，则哨兵认为其主观下线（subjectively down）。

主观下线表示从当前的哨兵进程看来，该节点已经下线。

如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送 SENTINEL is-master-down-by-addr命令询问其他哨兵节点以了解他们是否也认为该主数据库主观下线，如果达到指定数量时，哨兵会认为其客观下线（objectively down），并选举领头的哨兵节点对主从系统发起故障恢复。这个指定数量即为quorum参数。

例如，

sentinel monitor mymaster 127.0.0.1 6379 2

该配置表示只有当至少两个 Sentinel 节点（包括当前节点）认为该主数据库主观下线时，当前哨兵节点才会认为该主数据库客观下线。

进行接下来的选举领头哨兵步骤。

虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要由领头的哨兵来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。

选举领头哨兵的过程使用了Raft算法，具体过程如下。

（1）发现主数据库客观下线的哨兵节点（下面称作A）向每个哨兵节点发送命令，要求对方选自己成为领头哨兵。

（2）如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。

（3）如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A成功成为领头哨兵。

（4）当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。

故障恢复的过程相如下。