Redis哨兵集群(sentinel)原理解释与实战配置部署

Redis-哨兵简介:

(redis-sentinel)

哨兵作用:
1)Master状态检测
2)如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave
3)Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
端口:26379
配置文件:sentinel.conf
使用协议:tcp

Sentinel系统时刻监控着主和从,当主挂掉后选择其中一个从来升任成主,可以启动多个Sentinel来避免监控挂掉,但多个Sentinel它们要投票

哨兵工作原理:
  • 01 在一般情况下,每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令来获得redis主从的节点信息
  • 02 当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
  • 03 每2秒,会订阅获取一下主节点的哨兵信息,来了解哨兵们的信息,有新的哨兵加入,将会记录新哨兵信息,并与他建立连接
  • 04 每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
  • 05 如果一个 实例 距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。
  • 06 当主观下线的节点是 Master 时,则询问其他哨兵,超过一定个数则判断主节点挂掉,进行客观下线。
  • 07 当需要对一个 Master 进行客观下线,就需要在 Sentinel 们中选举一个领导者来执行这个操作,对 Master 进行下线,选举才用Raft算法
  • 08 若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
  • 09 若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
  • 10 当对一个 Master 进行客观下线后,会从其它从中选择出一个执行slaveof no one命令,使其升级为主节点。
  • 11 向其它从节点发送命令,指定新主,并对新主进行数据复制
  • 12 当原坏掉的主恢复后,将会作为新主的从节点
  • 13 如果原坏掉的主删除不恢复,Sentinel依然会定期检测,会造成一定资源浪费

主观下线和客观下线:

主观下线:

Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断,这个判断只是认为,但并不做任何动作

客观下线:

Objectively Down, 简称 ODOWN,指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的Master Server下线判断,然后开启failover

应用场景:

适合使用单点的redis,并有高可用需求的。因为始终是单台的redis,性能是有限度的,有更高需求可以选择集群。

在代码中,用jedis之类工具读取 Sentinel 的信息,获取当前没问题的主节点,进行写入操作即可。
当主挂掉,Sentinel会自动切换,只要对最新的主节点进行读写即可。

如果将主从做高可用,需要监控Sentinel的信息输出,将所有从节点做一个资源池,读将从资源池里找从节点进行。

Redis-哨兵部署:

  • 假设三台redis服务器做哨兵,也可以部署部署三个哨兵同时监测redis集群主从状态。(暂时有问题)

  • 当前文章基于redis主从复制集群之上部署,如为不是主从复制请移步:点击跳转

系统:CentOS-7.5
地址:

10.0.0.10   redis-01(master)
10.0.0.20   redis-02(slave)
10.0.0.30   redis-03(slave)

基于Redis主从复制环境的三台服务器操作

配置哨兵:(redis-01)
[root@db01 ~]# mkdir /data/26380 && vim /data/26380/sentinel.conf

#监听端口
port 26380
#数据存放目录
dir "/data/26380"
#定义Redis主库的地址与端口,名称为mymaster,(名称可以自定义),1代表是只要有1台sentinel认为主库宕机,那就切换
sentinel monitor mymaster 10.0.0.10 6379 1
#定义5000毫秒联系不上mymaster主库,就认为主库宕机了
sentinel down-after-milliseconds mymaster 5000
#告诉哨兵自定义的mymaster的认证密码
sentinel auth-pass mymaster redhat
其他配置:
# 守护进程模式
daemonize yes

# 指明日志文件名
logfile "/usr/local/redis/26379/sentinel.log"
创建命令软链接:(redis-01)
[root@db01 ~]# ln -s /usr/local/redis-5.0.2/src/redis-sentinel /usr/sbin/
启动哨兵:(redis-01)
[root@db01 ~]# redis-sentinel /data/26380/sentinel.conf &

测试哨兵可用性:
#'停掉主库,测试能否自定切换
[root@db01 ~]# redis-cli -h 10.0.0.10 -p 6379 -a redhat shutdown

重启源主库edis后:
#自动切换源主库为从库

加入systemd管理:

配置文件:
  • 要指定pid文件
port 26379
daemonize yes
logfile "/usr/local/redis/26379/sentinel.log"
pidfile /usr/local/redis/26379/sentinel.pid
dir "/usr/local/redis-4.0.10/26379"
sentinel monitor mymaster 10.0.0.10 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel auth-pass mymaster 123456
加入systemd:
[root@db01 ~]# vim /lib/systemd/system/redis-26379.service
[Unit]
Description=Redis
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/usr/local/redis/26379/sentinel.pid
ExecStart=/usr/sbin/redis-sentinel /usr/local/redis/26379/sentinel.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target
使用systemd管理哨兵:
[root@db01 ~]# systemctl restart redis-26379.service

哨兵常用参数与命令:

常用命令:

sentinel的基本状态信息
INFO

列出所有被监视的主服务器,以及这些主服务器的当前状态
SENTINEL masters

列出指定主redis的从节点状态情况
SENTINEL slaves <master-name>

列出指定主redis的监控哨兵信息,不包含他自己
SENTINEL sentinels <master-name>

返回给定名字的主服务器的 IP 地址和端口号
SENTINEL get-master-addr-by-name <master-name>

重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态,包括正在执行中的故障转移,并移除目前已经发现和关联的,主服务器的所有从服务器和 Sentinel 。
SENTINEL <master-name>

当主服务器失效时 在不询问其他 Sentinel 意见的情况下,强制开始一次自动故障迁移,但是它会给其他sentinel发送一个最新的配置,其他sentinel会根据这个配置进行更新
SENTINEL failover <master-name>

检查当前在线的哨兵节点。如果一共有5个节点,设置4票,但检查后只有3节点在线,那一直无法进行监控切换
sentinel ckquorum <master-name>

将配置强制刷新到本地文件
sentinel flushconfig

取消当前哨兵对某主节点的监控
sentinel remove <master name>

配置文件参数:

#<master-name>是主节点的名称,也就是可以同时监控多组主从
#主节点的地址和端口
#quorum是票数,需要几个哨兵节点认为有问题才进行操作
sentinel monitor <master-name> <ip> <port> <quorum>

#哨兵每隔一段时间就检测主节点是否存活,当超过<times>指定的时间,则认为主节点死掉
#虽然看似是对主控制,其实对从节点,其他哨兵节点也是这个参数控制
#默认30000,单位毫秒
sentinel down-after-milliseconds <master-name> <times>

#当主节点挂掉,新的主节点接替时,从节点会向新的主节点发起复制操作。这个参数控制同时发起复制操作的从节点个数。
#如果有一个新主,3个从,而<nums>设置为1。从节点会轮询复制
sentinel parallel-syncs <master-name> <nums>

#选出合适从节点,切换从为主,让其他从复制新主,让上线的坏主复制新主
#以上4部每个阶段故障时间超过<times>则认为失败
sentinel failover-timeout <master-name> <times>

#如果主节点有密码,需要配置密码,防止无法获取主节点信息
sentinel auth-pass <master-name> <password>

#当有重要事件,例如客观下线,主观下线时,将执行指定的脚本,并将一些相关参数传进去,可以发送邮件来通知
sentinel notification-script <master-name> <script-path>

#当故障转移结束后触发的脚本,并将一些相关参数传进去
sentinel client-reconfig-script <master-name> <script-path>

#脚本必须可以执行,开头必须有 #!/bin/bash 脚本头
#脚本最大执行时间不能超过一分钟,超过将杀死脚本
#如果shell脚本以exit 1结束,那么脚本稍后重试执行。如果以exit 2或者更高的值结束,那么脚本不会重试。正常返回值是exit 0
#脚本将传入如下参数
#<master-name> 主节点名称
#<role> 当前哨兵的角色是leader还是observer
#<state> 状态,是关闭还是启动
#<from-ip> 原主节点的ip
#<from-port> 原主节点的端口
#<to-ip> 新主节点的ip
#<to-port> 新主节点的端口

哨兵日志:


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论