Redis学习之哨兵模式
上一章介绍了Redis的主从复制、读写分离,就是主机执行写命令,Slave从机能同步主机的数据,这样就是实现了主从复制,读写分离。但是万一Master主机由于某些原因挂了怎么办,这是个麻烦事情,为了解决重要问题,Redis提供了一个Sentinel机制(哨兵),以此来实现主从切换的功能,类似于zookeeper。
1、Sentinel的简介
Redis在主从复制模式中,如果出现Master主机挂掉的情况,Slave从节点并不会切换为Master主节点,那么Slave从节点会一直等待Master重新启动,这显然是不合理的,为了解决这一问题,就出现了Redis的哨兵模式(Sentinel),见名之意,哨兵巡逻监控。Sentinel主要功能:监控Redis集群中的Master主服务器时运行状态,若Master节点出现问题,能够选举出一个Slave从节点变为主节点,从而保证系统的高可用,它们通过投票的方式进行选择,但拥有50%以上投票才生效,所以至少要3个Sentinel节点,所以单个Sentinel是不可靠的。Redis哨兵模式是支持集群的,并且集群模式下的哨兵之间会自动监控。
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。Sentinel由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器。
例如下图所示:
在Server1 掉线后:
升级Server2 为新的主服务器:
2、Sentinel的作用
- 监控(Monitoring):哨兵(Sentinel)会不断地检查你的Master和Slave是否运作正常。
- 提醒(Notification):当被监控的某个Redis节点出现问题时,哨兵(Sentinel)可以通过API向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(Sentinel)会开始一次自动故障迁移操作。
- 它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master;
- 当客户端视图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用现在的Master替换失效的Master。
- Master和Slave服务器切换后,Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变,即Master主服务器的redis.conf配置文件中会多一行Slave的配置,sentinel.conf的监控目标会随之调换。
3、Sentinel的工作方式
- 每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
- 如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds (毫秒)选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。
- 如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
- 当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态,并且当哨兵认为主观下线的票数超过了quorum(选举)个数, 则Master会被标记为客观下线 。
- 在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令 。
- 当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。
- 若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
- 若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
4、Sentinel的配置(多机)
虽然哨兵模式可以切换主从节点,但是当哨兵机器挂了之后,就无法进行监控了,解决办法是哨兵也建立集群,Redis哨兵模式是支持集群的。所以配置3个哨兵和1主2从的Redis服务器来演示这个过程。
下面配置Redis的主从服务器,修改redis.conf文件如下:
(1)、配置Master节点
①、注释bind 127.0.0.1
②、禁止保护模式:protected-mode no
③、修改daemonize为yes
④、设置密码(可选,不建议设置密码,所以我就没有设置密码了):requirepass 123456
-------------------------------------------------------------
(2)配置Slave节点(在上面的基础Slave节点还需额外配置下面的信息)
①、指定主服务器。注意:只配置从服务器,主服务器不需要配置:replicaof 192.168.30.101 6379
具体可以参考上一章:Redis学习(六)----主从复制、读写分离
(3)、然后分别配置3个哨兵,每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件,copy进行修改
①、设置哨兵后台启动
②、配置哨兵输出日志
③、设置哨兵监控的节点
(4)、开启端口:需要开启6379 和 26379 这两个端口,Linux打开端口可以参考:Linux开放指定端口(CentOS6/CentOS7)(转)
# 开启6379 firewall-cmd --zone=public --add-port=6379/tcp --permanent # 开启26379 firewall-cmd --zone=public --add-port=26379/tcp --permanent # 重启防火墙 firewall-cmd –reload # 查看端口是否开放 firewall-cmd --list-ports
(5)、当上述步骤都完成之后,我们可以进入Redis的安装目录启动Redis服务和哨兵了,通过下面的命令启动服务器和哨兵
# 进入redis安装目录bin下 cd /usr/local/redis/bin # 依次启动Redis服务器进程 ./redis-server redis.conf # 依次启动哨兵进程 ./redis-sentinel sentinel.conf # 进入redis客户端 ./redis-cli -h 192.168.30.101 -p 6379 ./redis-cli -h 192.168.30.102 -p 6379 ./redis-cli -h 192.168.30.103 -p 6379
通过 info replication 可以发现Redis主从和哨兵都启动了,并且主从关系以及建立起来了。
然后我们将Master服务关闭(即:192.168.30.101:6379),通过ShutDown命令。
这时Master主机就挂了,哨兵监控到就会马上进行投票选出一个从机作为新的Master主机,稍微等待几秒钟之后,通过查看日志可以发现,IP地址为 192.168.30.103:6379 成为了新的主机,同时,192.168.30.102:6379 和挂掉的主机成为了 192.168.30.102:6379 的从机,我们看看哨兵打印的日志:
随后如果Master主机又复活了呢?当之前挂掉的Master主机重新连接上会发生什么情况呢?我们来看一下:
可以发现原来挂掉的Master现在已经成为了192.168.30.103:6379的从节点,这样就通过Sentinel机制完成了Redis的高可用性(HA)解决方案。
自此已经完成Redis的状态:“三哨兵集群”、“一主”、“二从”的模式。
5、Sentinel的配置文件参数介绍
最后再来把哨兵机制的配置文件sentinel.conf中常用配置项说明一下:
# 打开非保护模式 protected-mode no ----------------------------------------------------- # Sentinel使用端口,默认26379 port 26379 ----------------------------------------------------- # 守护线程启动(即后台启动) daemonize yes ----------------------------------------------------- # 守护进程会使用到的一个文件 pidfile /var/run/redis-sentinel.pid ----------------------------------------------------- # 指定哨兵输出的日志文件名,默认为"",空字符串也可用于强制Sentinel登录标准输出, # 指定后我们可以通过tail -f xxx.log查看日志 logfile "/usr/local/redis/bin/sentinel.log" ----------------------------------------------------- # 哨兵sentinel的工作目录 dir "/tmp" ----------------------------------------------------- # 是否拒绝从新配置通知脚本,默认拒绝(yes). sentinel deny-scripts-reconfig yes ----------------------------------------------------- # 这个配置非常重要!!! # sentinel monitor <master-name> <ip> <redis-port> <quorum> # 告诉sentinel去监听地址为ip:port的一个master # master-name:可以自己命名的主节点名字,只能由字母A-z、数字0-9 、这三个字符".-_"组成。 # quorum:当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # 有多少个sentinel认为一个master失效时,master才算真正失效.需要注意的是master-ip 要写真实的ip地址而不要用回环地址(127.0.0.1)。 sentinel monitor mymaster 192.168.30.103 6379 1 ----------------------------------------------------- # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 必须为主从设置一样的验证密码,注意:这一步必须在sentinel monitor后面 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster MySUPER--secret-0123passw0rd ----------------------------------------------------- # 故障转移的超时时间 failover-timeout 可以用在以下这些方面: # 1.同一个sentinel对同一个master两次failover之间的间隔时间。 # 2.当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同 步数据时。 # 3.当想要取消一个正在进行的failover所需要的时间。 # 4.当进行failover时,配置所有slaves指向新的master所需的大时间。 # 不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了 # 时间默认三分钟,单位为毫秒 # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000 ----------------------------------------------------- # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下.单位是毫秒,默认为30秒 # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000 ----------------------------------------------------- # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,这个数字越小, # 完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用. # 可以通过将这个值设为1(默认就是1)来保证每次只有一个slave处于不能处理命令请求的状态 # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster 1 ----------------------------------------------------- # 通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本, # 这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本 时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。 # 如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。 # 通知脚本,该配置项可选,比较常用 # sentinel notification-script <master-name> <script-path> sentinel notification-script mymaster /var/redis/notify.sh ----------------------------------------------------- # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生 改变的信息。 # 以下参数将会在调用脚本时传给脚本: # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # 目前<state>总是“failover”, # <role>是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的 # 这个脚本应该是通用的,能被多次调用,不是针对性的。 # sentinel client-reconfig-script <master-name> <script-path> sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
参考链接: