Redis容灾部署哨兵(sentinel)机制配置详解及原理介绍

来源:http://blog.csdn.net/robertohuang/article/details/70768922

说明:这篇博文写的使用,对于初学者来说很实用,推荐学习,文章中重点是关于sentinel的介绍还不错,学到了很多.

1.为什么要用到哨兵

哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况:1.从Redis宕机这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据。在Redis2.8版本后,主从断线后恢复的情况下实现增量复制。2.主Redis宕机这个相对而言就会复杂一些,需要以下2步才能完成i.第一步,在从数据库中执行SLAVEOF NO ONE命令,断开主从关系并且提升为主库继续服务ii.第二步,将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来由于这个手动完成恢复的过程其实是比较麻烦的并且容易出错,所以Redis提供的哨兵(sentinel)的功能来解决
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14

2.什么是哨兵

Redis-Sentinel是用于管理Redis集群,该系统执行以下三个任务:1.监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否运作正常2.提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知3.自动故障迁移(Automatic failover):当一个主服务器不能正常工作时,Sentinel 会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9

3.Sentinel集群搭建

3.1 Sentinel集群拓扑图 
 
多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控

3.2 在保证Redis主从架构集群可用的前提下,复制三份配置文件

进入redis所在目录# cd /opt/redis/redis-3.2.8创建6379、6380、6381目录,分别将安装目录下的sentinel.conf拷贝到这三个目录下# mkdir -p /opt/redis/6379 && cp sentinel.conf /opt/redis/6379/26379.conf# mkdir -p /opt/redis/6380 && cp sentinel.conf /opt/redis/6380/26380.conf# mkdir -p /opt/redis/6381 && cp sentinel.conf /opt/redis/6381/26381.conf
1
2
3
4
5
6
7
1
2
3
4
5
6
7

3.3 分别配置哨兵

修改sentinel配置文件vim /opt/redis/6379/26379.conf修改内容：# 添加守护进程模式daemonize yes# 添加指明日志文件名logfile "/opt/redis/6379/sentinel26379.log"# 修改工作目录dir "/opt/redis/6379"# 修改启动端口port 26379# 关闭保护模式protected-mode no# 修改sentinel monitorsentinel monitor redis-test-master 192.168.29.128 6379 2# 将配置文件中mymaster全部替换redis-test-master依次修改26380,26381配置说明：redis-test-master:监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号192.168.29.128:监控的主数据库的IP6379:监控的主数据库的端口2:最低通过票数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

3.4 启动哨兵进程

redis-sentinel /opt/redis/6379/26379.conf 或者 redis-server /opt/redis/6379/26379.conf --sentinelredis-sentinel /opt/redis/6380/26380.conf 或者 redis-server /opt/redis/6380/26380.conf --sentinelredis-sentinel /opt/redis/6380/26380.conf 或者 redis-server /opt/redis/6381/26381.conf --sentinel
1
2
3
1
2
3

3.5 哨兵模式常用命令

1.查看sentinel的基本状态信息127.0.0.1:26379> INFO2.列出所有被监视的主服务器,以及这些主服务器的当前状态 127.0.0.1:26379> SENTINEL MASTERS redis-test-master3.列出给定主服务器的所有从服务器,以及这些从服务器的当前状态 127.0.0.1:26379> SENTINEL SLAVES redis-test-master4.返回给定名字的主服务器的IP地址和端口号127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME redis-test-master5.重置所有名字和给定模式pattern相匹配的主服务器,重置操作清除主服务器目前的所有状态,包括正在执行中的故障转移,并移除目前已经发现和关联的,主服务器的所有从服务器和Sentinel127.0.0.1:26379> SENTINEL RESET redis-test-master 6.当主服务器失效时,在不询问其他Sentinel意见的情况下,强制开始一次自动故障迁移,但是它会给其他Sentinel发送一个最新的配置,其他sentinel会根据这个配置进行更新127.0.0.1:26379> SENTINEL FAILOVER redis-test-master7.查看其它哨兵信息127.0.0.1:26379> SENTINEL sentinels redis-test-master
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

3.6 查看配置中是否多了如下内容 

3.7 Java代码测试哨兵

public class RedisTest {    public static void main(String[] args) {        Set<String> sentinels = new HashSet<String>();        sentinels.add(new HostAndPort("192.168.29.128", 26379).toString());        sentinels.add(new HostAndPort("192.168.29.128", 26380).toString());        sentinels.add(new HostAndPort("192.168.29.128", 26381).toString());        JedisSentinelPool sentinelPool = new JedisSentinelPool("redis-test-master", sentinels);        System.out.println("Current master: " + sentinelPool.getCurrentHostMaster().toString());        Jedis master = sentinelPool.getResource();        master.set("username", "RobertoHuang");        sentinelPool.returnResource(master);        Jedis master2 = sentinelPool.getResource();        String value = master2.get("username");        System.out.println("username: " + value);        master2.close();        sentinelPool.destroy();    }}输出结果:Current master: 192.168.29.128:6379username: RobertoHuang
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

3.8 测试Sentinel是否正常工作

3.8.1 测试集群环境如下 

3.8.2 关闭端口为6379的redis 

3.8.3 查看新的集群架构 

3.8.4 重新启动端口号为6379的Redis 查看集群架构 

该过程是6379Redis宕机->6380切换成Master->6379和6381切换为6380的SLAVE->6379重新启动->6379为6380SLAVE

3.8.5 Sentinel日志分析 
26379日志 

26380日志 

26381日志 

4.Sentinel原理介绍 
首先解释2个名词:SDOWN和ODOWN.

SDOWN:subjectively down,直接翻译的为”主观”失效,即当前sentinel实例认为某个redis服务为”不可用”状态.

ODOWN:objectively down,直接翻译为”客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启failover

SDOWN与ODOWN转换过程: 
i.每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒),在交互中,如果redis-server无法在”down-after-milliseconds”时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态.

ii.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.

Sentinel与slaves”自动发现”机制: 
在sentinel的配置文件中,都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口.在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送”PING”以及类似于”is-master-down-by-addr”指令集,可用用来检测其他sentinel实例的有效性以及”ODOWN”和”failover”过程中信息的交互.在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接.sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口.