Redis的哨兵(sentinel)配置和Python程序应用示例

294次阅读

共计 8123 个字符，预计需要花费 21 分钟才能阅读完成。

一、Sentinel 概述：
当用 Redis 做 Master-slave 的高可用方案时，假如 master 宕机了，Redis 本身 (包括它的很多客户端) 都没有实现自动进行主备切换，而 Redis-sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能进行自动切换。Sentinel 是 Redis 的高可用性（HA）解决方案，由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis 提供的 sentinel（哨兵）机制，通过 sentinel 模式启动 redis 后，自动监控 master/slave 的运行状态，基本原理是：心跳机制 + 投票裁决
l 监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
l 提醒（Notification）：当被监控的某个 Redis 服务器出现问题时，Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
l 自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
l 配置信息：哨兵提供了认证和服务发现，客户端连接到哨兵去获取当前 redis 主服务器地址，如果发生故障转移，哨兵将会汇报新的服务器地址。每次进行主从切换时，sentinel 配置文件自动更新
二、Sentinel 支持集群
很显然，只使用单个 sentinel 进程来监控 redis 集群是不可靠的，当 sentinel 进程宕掉后 (sentinel 本身也有单点问题，single-point-of-failure) 整个集群系统将无法按照预期的方式运行。所以有必要将 sentinel 集群，这样有几个好处：
1. 即使有一些 sentinel 进程宕掉了，依然可以进行 redis 集群的主备切换；
2. 如果只有一个 sentinel 进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现 redis 集群的主备切换（单点问题）;
3. 如果有多个 sentinel，redis 的客户端可以随意地连接任意一个 sentinel 来获得关于 redis 集群中的信息。
三、Sentinel 版本选择
Sentinel 当前最新的稳定版本称为 Sentinel 2(与之前的 Sentinel 1 区分开来）。随着 redis2.8 的安装包一起发行。安装完 Redis2.8 后，可以在 redis2.8/src/ 里面找到 Redis-sentinel 的启动程序。如果你使用的是 redis2.6(sentinel 版本为 sentinel 1)，你最好应该使用 redis2.8 版本的 sentinel 2，因为 sentinel 1 有很多的 Bug，已经被官方弃用，所以强烈建议使用 redis2.8 以及 sentinel 2。
四、Redis Sentinel 的配置
redis 主 ip：192.168.221.160
redis 从 ip：192.168.221.161
Sentinel 在 redis 主从的基础上继续配置，主从配置的方式这里不再赘述。详情请参考楼主另一篇文章：redis 安装及主从配置
我这里配置了两个哨兵，分别部署在两台机器上，采用了典型的配置项，配置文件如下：
[root@DB ~]# grep -Ev ‘^#|^$’ /etc/sentinel_26379.conf
port 26379
daemonize yes #程序后台执行
logfile “/var/log/sentinel.log”
dir “/tmp”
sentinel monitor mymaster 192.168.221.160 6379 2 #第一次设置哨兵时此 ip 一定要设置为 redis 集群中的主 ip
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 6000
sentinel config-epoch mymaster 7
sentinel parallel-syncs mymaster 1

下面简单解释下这些配置项：
sentinel monitor mymaster 192.168.221.160 6379 2 表示 sentinel 监控的 master 名字是 mymaster，地址为 192.168.221.160:6379。行尾最后的一个 2 代表什么意思呢？我们知道，网络是不可靠的，有时候一个 sentinel 会因为网络堵塞而误以为一个 master redis 已经死掉了，当 sentinel 集群式，解决这个问题的方法就变得很简单，只需要多个 sentinel 互相沟通来确认某个 master 是否真的死了，这个 2 代表，当集群中有 2 个 sentinel 认为 master 死了时，才能真正认为该 master 已经不可用了。（sentinel 集群中各个 sentinel 也有互相通信，通过 gossip 协议）
sentinel down-after-milliseconds mymaster 5000 Sentinel 会向 master 发送心跳 PING 来确认 master 是否存活，如果 master 在“一定时间范围”内不回应 PONG 或者是回复了一个错误消息，那么这个 sentinel 会主观地 (单方面地) 认为这个 master 已经不可用了 (subjectively down, 也简称为 SDOWN)。而这个 down-after-milliseconds 就是用来指定这个“一定时间范围”的，单位是毫秒
sentinel parallel-syncs mymaster 1 在执行故障转移时，最多可以有多少个从服务器同时从新的主服务器进行同步，数字越小，完成故障转移需要的时间越长
五、运行 Sentinel，状态检查
先启动 redis 主从程序，在启动 sentinel：
redis-server /etc/sentinel_26379.conf –sentinel

Master 机器查看进程：
root 84286 57342 0 Oct18 pts/2 00:00:00 redis-cli -h 192.168.221.160 -p 26379
root 84302 1 0 Oct18 ? 00:03:41 redis-server *:26379
redis 84328 1 0 Oct18 ? 00:03:01 /usr/sbin/redis-server 192.168.221.160:6379
root 84391 83553 0 Oct18 pts/3 00:00:00 redis-cli -h 192.168.221.160
root 86746 86651 0 09:35 pts/6 00:00:00 grep redis

Slave 机器查看进程：
redis 53505 1 0 Oct18 ? 00:02:17 /usr/sbin/redis-server 192.168.221.161:6379
root 53510 52922 0 Oct18 pts/0 00:00:00 redis-cli -h 192.168.221.161
root 53542 1 0 Oct18 ? 00:02:53 redis-server *:26379
root 54767 54723 0 09:34 pts/1 00:00:00 grep redis

查看 master 状态：
[root@MidApp ~]# redis-cli -h 192.168.221.160
192.168.221.160:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.221.161,port=6379,state=online,offset=9243499,lag=0
master_repl_offset:9243644
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8195069
repl_backlog_histlen:1048576

查看 slave 状态：
[root@DB ~]# redis-cli -h 192.168.221.161 -p 6379
192.168.221.161:6379> info replication
# Replication
role:slave
master_host:192.168.221.160
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:9200304
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 状态：
[root@DB ~]# redis-cli -h 192.168.221.160 -p 26379
192.168.221.160:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=192.168.221.160:6379,slaves=1,sentinels=2

六、Redis-Sentinel 主从切换测试
首先手动关闭主 redis(192.168.221.160), 查看 sentinel 日志，可以看到 192.168.221.161 已经变成了主 redis，自动完成了切换：
[84302] 18 Oct 15:22:31.539 * +failover-state-wait-promotion slave 192.168.221.161:6379 192.168.221.161 6379 @ mymaster 192.168.221.160 6379
[84302] 18 Oct 15:22:32.434 # +promoted-slave slave 192.168.221.161:6379 192.168.221.161 6379 @ mymaster 192.168.221.160 6379
[84302] 18 Oct 15:22:32.434 # +failover-state-reconf-slaves master mymaster 192.168.221.160 6379
[84302] 18 Oct 15:22:32.498 # +failover-end master mymaster 192.168.221.160 6379
[84302] 18 Oct 15:22:32.499 # +switch-master mymaster 192.168.221.160 6379 192.168.221.161 6379
[84302] 18 Oct 15:22:32.500 * +slave slave 192.168.221.160:6379 192.168.221.160 6379 @ mymaster 192.168.221.161 6379
[84302] 18 Oct 15:22:37.552 # +sdown slave 192.168.221.160:6379 192.168.221.160 6379 @ mymaster 192.168.221.161 6379

把刚才关闭的 redis 再次启动之后检查 redis 主从状态：
[root@DB ~]# redis-cli -h 192.168.221.160 -p 6379
192.168.221.160:6379> info replication
# Replication
role:slave
master_host:192.168.221.161
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:9200304
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@MidApp ~]# redis-cli -h 192.168.221.161
192.168.221.161:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.221.160,port=6379,state=online,offset=9243499,lag=0
master_repl_offset:9243644
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8195069
repl_backlog_histlen:1048576

检查 sentinel 配置文件：
[root@DB ~]# grep -Ev ‘^#|^$’ /etc/sentinel_26379.conf
port 26379
daemonize yes
logfile “/var/log/sentinel.log”
dir “/tmp”
sentinel monitor mymaster 192.168.221.161 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 6000
sentinel config-epoch mymaster 7
sentinel known-slave mymaster 192.168.221.160 6379
sentinel known-sentinel mymaster 192.168.221.161 26379 74f54a23bf06b57ce1618ee48f42a09a11522bb9

可以看到配置文件监控的 master 机器也变成了 192.168.221.161:6379。

七、Python 程序访问 sentinel 集群
由于很好奇连入的程序是如何访问 sentinel 集群的，自己用 python 验证了一下。
Python 下需要安装 redis 相关的 lib 库，我这里使用的是 redis-2.10.5 版本
[root@DB ~]# python
Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from redis.sentinel import Sentinel #加载 redis 模块
>>> sentinel = Sentinel([(‘192.168.221.160’, 26379),
… (‘192.168.221.161’, 26379)],
… socket_timeout=0.1) #连接哨兵服务器
>>> sentinel.discover_master(‘mymaster’) #获取主 redis 服务器地址
(‘192.168.221.161’, 6379)
>>> sentinel.discover_slaves(‘mymaster’)# 获取从 redis 服务区地址
[(‘192.168.221.160’, 6379)]
>>> master = sentinel.master_for(‘mymaster’, socket_timeout=0.1)
>>> master.set(‘foo’,’bar’) #获取主 redis 服务器并进行写入
True
>>> slave = sentinel.slave_for(‘mymaster’, socket_timeout=0.1)
>>> slave.get(‘foo’)# 获取从 redis 服务器进行获取
‘bar’
>>>