互联网架构Redis程序员

Redis Sentinel(哨兵)部署

2016-04-08  本文已影响7268人  dzgdp888

Redis-sentinel是Redis实例的监控管理、通知和实例失效备援服务,是Redis集群的管理工具。在一般的分布式中心节点数据库中,Redis-sentinel的作用是中心节点的工作,监控各个其他节点的工作情况并且进行故障恢复,来提高集群的高可用性。

一、Redis Sentinel规划

IP 端口号 角色
192.168.1.51 7000 Redis Master
192.168.1.52 7000 Redis Master
192.168.1.53 7000 Redis Master
192.168.1.51 27000 Sentinel
192.168.1.52 27000 Sentinel
192.168.1.53 27000 Sentinel

一个一主多从的Redis系统中,可以使用多个哨兵进行监控任务以保证系统足够稳健。此时,不仅哨兵会同时监控主数据库和从数据库,哨兵之间也会相互监控。在这里,建议大家哨兵至少部署3个,并且使用奇数个哨兵。

二、RedisSentinel部署

1、安装Redis

在3台服务器上分别安装Redis。需要注意的是,如果要给Redis设置密码,需要在3个Redis的配置文件中设置相同的密码。

requirepass"Redis-Password"

2、设置主从复制

在2个SlaveRedis的配置文件中声明所从属的主数据库。

 slaveof192.168.1.51 7000

这里需要注意一点,如果主数据库设置了密码,需要所有Redis的配置文件中设置masterauth"Redis-Password",包括主数据库。Sentinel可以切换主从数据库,主数据库可能会变成从数据库,因此也需要设置主数据库密码。

3、配置Sentinel.config

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"

1)daemonize yes

– 以后台进程模式运行

2)port 27000

– 哨兵的端口号,该端口号默认为26379。

3)logfile"/data/bd/redis/sentinel/sentinel.log"

– log文件所在地

4)sentinel monitor redis-master 192.168.1.517000 2

– redis-master是主数据的别名,考虑到故障恢复后主数据库的地址和端口号会发生变化,哨兵提供了命令可以通过别名获取主数据库的地址和端口号。

– 192.168.1.51 7000为初次配置时主数据库的地址和端口号,当主数据库发生变化时,哨兵会自动更新这个配置,不需要我们去关心。

–2,该参数用来表示执行故障恢复操作前至少需要几个哨兵节点同意,一般设置为N/2+1(N为哨兵总数)。

5)sentinel down-after-milliseconds redis-master 1000

– 如果master在多少秒内无反应哨兵会开始进行master-slave间的切换,使用“选举”机制

6)sentinel failover-timeout redis-master 5000

– 如果在多少秒内没有把宕掉的那台master恢复,那哨兵认为这是一次真正的宕机,而排除该宕掉的master作为节点选取时可用的node然后等待一定的设定值的毫秒数后再来探测该节点是否恢复,如果恢复就把它作为一台slave加入哨兵监测节点群并在下一次切换时为他分配一个“选取号”。

4、Sentinel运行

redis-sentinel /data/bd/redis/sentinel/sentinel.conf

启动成功后可以通过redis客户端工具查看当前Sentinel的信息,终端输入:

redis-cli -p 27000-h 192.168.1.51 INFO Sentinel
# Sentinel

sentinel_masters:1

sentinel_tilt:0

sentinel_running_scripts:0

sentinel_scripts_queue_length:0

master0:name=redis-master,status=ok,address=192.168.1.51:7000,slaves=2,sentinels=3
tail -f/data/bd/redis/sentinel/sentinel.log
3273:X 08 Apr 10:44:14.733 # Sentinel runid is 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1

3273:X 08 Apr 10:44:14.733 # +monitor master redis-master 192.168.1.51 7000 quorum 2

3273:X 08 Apr 10:44:14.735 * +slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:44:14.744 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:12.733 * +sentinel sentinel 192.168.1.52:27000 192.168.1.52:27000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:48:20.533 * +sentinel sentinel 192.168.1.53:27000 192.168.1.53:27000 @ redis-master 192.168.1.51 7000

+slave和+sentinel分别代表成功发现了从数据库和其他Sentinel。

##sentinel实例之间的通讯端口

daemonize yes

port 27000

#redis-master

sentinel monitor redis-master 192.168.1.51 7000 2

sentinel down-after-milliseconds redis-master 5000

sentinel failover-timeout redis-master 900000

sentinel parallel-syncs redis-master 2

sentinel auth-pass redis-master 123456

logfile "/data/bd/redis/sentinel/sentinel.log"

# Generated by CONFIG REWRITE

dir "/soft/sentinel"

sentinel config-epoch redis-master 0

sentinel leader-epoch redis-master 0

sentinel known-slave redis-master 192.168.1.52 7000

sentinel known-slave redis-master 192.168.1.53 7000

sentinel known-sentinel redis-master 192.168.1.52 27000 ef356da8dadb6a16268d25611942ecf001d5cb2e

sentinel known-sentinel redis-master 192.168.1.53 27000 188fa69f695fd17639ce1ee38592e894d8a14331

sentinel current-epoch 0                         

三、Sentinel验证

按照之前的步骤我们已经配置好了3台Redisnode和Sentinel集群,Redis主数据库为192.168.1.51:7000。

1、模拟主数据库故障

这里直接关闭主数据库,终端输入:

redis-cli -p 7000 shutdown

经过一段时间后,我们可以看到sentinel.log文件中增加了以下内容:

3273:X 08 Apr 10:58:08.330 # +sdown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.385 # +odown master redis-master 192.168.1.73 7000 #quorum 2/2

3273:X 08 Apr 10:58:08.385 # +new-epoch 1

3273:X 08 Apr 10:58:08.385 # +try-failover master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.388 # +vote-for-leader 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.392 # 192.168.1.52:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.393 # 192.168.1.53:27000 voted for 725b3bc06f18e8db913a44bbbdbc23a3be54c4d1 1

3273:X 08 Apr 10:58:08.489 # +elected-leader master redis-master 192.168.1.51 7001

3273:X 08 Apr 10:58:08.489 # +failover-state-select-slave master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 # +selected-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.580 * +failover-state-send-slaveof-noone slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:08.633 * +failover-state-wait-promotion slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +promoted-slave slave 192.168.1.52:7000 192.168.1.52 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.561 # +failover-state-reconf-slaves master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:09.612 * +slave-reconf-sent slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.517 # -odown master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-inprog slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.576 * +slave-reconf-done slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +failover-end master redis-master 192.168.1.51 7000

3273:X 08 Apr 10:58:10.643 # +switch-master redis-master 192.168.1.51 7000 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.53:7000 192.168.1.53 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:10.643 * +slave slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

3273:X 08 Apr 10:58:15.654 # +sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

+sdown 表示哨兵主观认为数据库下线
+odown 表示哨兵客观认为数据库下线
+try-failover 表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障修复,其中包括了领头哨兵的选举、备选从数据库的选择等等较为复杂的过程
+switch-master表示主数据库从51服务器迁移到52服务器
+slave列出了新的主数据库的2个从数据库,而哨兵并没有彻底清除51服务器的实力信息,这是因为停止的实例有可能会在将来恢复,哨兵会让其重新加入进来

2、恢复故障数据库

重新启动192.168.1.51上的Redis数据库,查看sentinel.log文件,日志中增加了以下的内容:

3273:X 08 Apr 11:19:44.847 # -sdown slave 192.168.1.51:7000 192.168.1.51 7000 @ redis-master 192.168.1.52 7000

-sdown 哨兵将下线的Redis实例重新加入,并且作为新的主数据库的从数据库存在

上一篇下一篇

猜你喜欢

热点阅读