哨兵机制介绍
单机版的 Redis 存在性能瓶颈, Redis 通过提高主从复制实现读写分离, 提高了了 Redis 的可用性, 另一方便也能实现数据在多个 Redis 直接的备份.
上一篇文章我们通过配置 Redis 的主从复制机制来提高了 Redis 的可用性, 但是一旦主节点出现问题, 就需要运维手工切换主从服务节点, 即增加了人工成本, 且容易出错, 而且无法自动化切换, Redis 的哨兵机制就能实现自动的主从切换, 以及实现对 Redis 服务的切换, 那就让我们来感受下哨兵机制的强大吧.
准备条件
搭建主从服务
这一步在上篇文章以及详细介绍了, 这里就简答提一下, 细节具体可以翻看上一篇.
- # 启动 Redis 主从复制集群机制
- [[email protected] Redis-5.0.7]# src/Redis-server redis6379.conf
- [[email protected] Redis-5.0.7]# src/Redis-server redis6380.conf
- [[email protected] Redis-5.0.7]# src/Redis-server redis6381.conf
查看主从复制集群
- 127.0.0.1:6379> INFO replication
- # Replication
- role:master
- connected_slaves:2
- slave0:ip=127.0.0.1,port=6380,state=online,offset=14,lag=0
- slave1:ip=127.0.0.1,port=6381,state=online,offset=14,lag=0
- master_replid:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
- master_replid2:0000000000000000000000000000000000000000
- master_repl_offset:14
- second_repl_offset:-1
- repl_backlog_active:1
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:1
- repl_backlog_histlen:14
可以看到, 我们的主从服务 (一主二从) 已经搭建完毕.
准备哨兵配置文件
我们下载的 Redis.tar.gz 解压后里面是有一个 senitel.conf 配置文件的, 我们复制一个然后进行配置修改.
- # 复制配置文件
- [[email protected] Redis-5.0.7]# cp sentinel.conf sentinel26379conf
- # 修改 sentinel26379conf 配置文件
- bind 0.0.0.0
- port 26379
- daemonize yes
- pidfile /var/run/Redis-sentinel26379.pid
- logfile "/usr/local/redis/logs/sentinel-26379.log"
- dir /tmp
- # 哨兵 监控 主节点名称 IP 地址 端口 判断失效的哨兵个数
- sentinel monitor mymaster 127.0.0.1 6379 2
- # 配置主服务的密码(如果主节点设置密码这块必须要进行配置)
- sentinel auth-pass mymaster enjoyitlife
- sentinel down-after-milliseconds mymaster 1000
- sentinel parallel-syncs mymaster 1
- sentinel failover-timeout mymaster 5000
将配置文件 sentinel26379.conf 在复制两份, sentinel26380,sentinel26381.conf. 这两个配置文件 值需要修改里的端口号就可以.
- # sentinel26380 配置文件内容 26381 配置文件就不在赘述了.
- bind 0.0.0.0
- port 26380
- daemonize yes
- pidfile /var/run/Redis-sentinel26380.pid
- logfile "/usr/local/redis/logs/sentinel-26380.log"
- dir /tmp
- sentinel monitor mymaster 127.0.0.1 6379 2
- sentinel down-after-milliseconds mymaster 1000
- sentinel parallel-syncs mymaster 1
- sentinel failover-timeout mymaster 5000
- sentinel auth-pass mymaster enjoyitlife
运行哨兵
运行哨兵
- # 开启三个哨兵监控主节点
- [[email protected] Redis-5.0.7]# src/Redis-sentinel sentinel26379.conf
- [[email protected] Redis-5.0.7]# src/Redis-sentinel sentinel26380.conf
- [[email protected] Redis-5.0.7]# src/Redis-sentinel sentinel26381.conf
也可以通过 Redis-server /path/to/sentinel.conf --sentinel 运行哨兵.
查看哨兵状态
- # 通过 ps 指令
- [[email protected] Redis-5.0.7]# ps -ef | grep Redis
- root 7929 1 0 07:49 ? 00:00:01 src/Redis-server 0.0.0.0:6379
- root 7933 7772 0 07:49 pts/5 00:00:00 src/Redis-cli -p 6379 -a enjoyitlife
- root 7935 1 0 07:50 ? 00:00:01 src/Redis-server 127.0.0.1:6380
- root 7941 1 0 07:50 ? 00:00:01 src/Redis-server 127.0.0.1:6381
- root 7949 1 0 08:00 ? 00:00:00 src/Redis-sentinel 0.0.0.0:26379 [sentinel]
- root 7954 1 0 08:00 ? 00:00:00 src/Redis-sentinel 0.0.0.0:26380 [sentinel]
- root 7959 1 0 08:00 ? 00:00:00 src/Redis-sentinel 0.0.0.0:26381 [sentinel]
- root 7978 7686 0 08:01 pts/4 00:00:00 grep --color=auto Redis
- # 通过客户端 哨兵机制本质也是 Redis 服务的一种模式 可以通过客户端指令
- [[email protected] ~]# cd /opt/software/Redis/Redis-5.0.7
- [[email protected] Redis-5.0.7]# src/Redis-cli -p 26379
- 127.0.0.1:26379> INFO sentinel
- # Sentinel
- sentinel_masters:1
- sentinel_tilt:0
- sentinel_running_scripts:0
- sentinel_scripts_queue_length:0
- sentinel_simulate_failure_flags:0
- master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
可以看到至此, 我们的哨兵机制已经正确搭建完毕, 当前有三个哨兵, 一主多从, 3 个服务节点.
哨兵机制验证
我们关闭主节点, 然后等待 1S 后再进行查看.
- # 关闭主节点
- 127.0.0.1:6379> SHUTDOWN
- # 在从节点 6380 上进行查看
- 127.0.0.1:6380> INFO replication
- # Replication
- role:master
- connected_slaves:0
- master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
- master_replid2:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
- master_repl_offset:78278
- second_repl_offset:69478
- repl_backlog_active:1
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:1
- repl_backlog_histlen:78278
可以看到现在的 6380 节点已经有从节点升级为了主节点. 我们再次启动 6379 节点.
- # 启动 6379 端口节点
- [[email protected] Redis-5.0.7]# src/Redis-server redis6379.conf
- [[email protected] Redis-5.0.7]# src/Redis-cli -p 6379 -a enjoyitlife
- # 查看集群信息
- 127.0.0.1:6379> info replication
- # Replication
- role:slave
- master_host:127.0.0.1
- master_port:6380
- master_link_status:up
- master_last_io_seconds_ago:0
- master_sync_in_progress:0
- slave_repl_offset:107428
- slave_priority:100
- slave_read_only:1
- connected_slaves:0
- master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
- master_replid2:0000000000000000000000000000000000000000
- master_repl_offset:107428
此时即使 6379 端口节点恢复正常了, 但是它已经失去了主节点的身份, 目前降级为了从节点了. 下面就哨兵机制的原理在进行说明下.
哨兵机制相关原理
主要功能
监控 检查主从服务节点是否服务正常
提醒 当被监控的节点出现问题时, 哨兵机制可以发送通知
自动故障转移 主节点不可以用时, 自动进行节点升级和故障转移.
提供配置 作为客户端的配置提供者.
故障转移流程
每个 Sentinel 每秒钟向主节点, 从节点, 其他 sentinel 实例发送 PING 命令.
如果一个 Sentinel 发现主服务节点不可用, 会将主节点标记为主观下线, 并通知其他 Sentinel 实例向主节点发送消息.
如果有足够数量的 Sentinel 实例, 满足配置文件中需要的个数
sentinel monitor mymaster 127.0.0.1 6379 2
这里配置的是 2, 那就将主服务标记为客观下线.
Sentinel 通过选举机制选举出一个 Lead Sentinel, 负责本次故障转移.
Sentinle 选择一个从服务节点, 向其发送 SALVE NO ONE 命令, 使其升级为主节点.
通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新.
向从服务器发送 [SLAVEOF] 命令, 让他们的主服务节点更新为上一步新主节点.
当所有从服务器都已经开始复制新的主服务器时, 复制本次故障转移的 Sentinel 终止这次故障迁移操作.
注意要点
Sentinel 会在运行中自动的修改配置文件并进行持久化, 主要涉及主从配置点.
每一次故障转移 Sentinel 都会用过选举机制选举从本次故障转移的领头 Sentinel, 从而有领头的 Sentinel 来负责故障转移过程.
Sentinel 之间通过订阅发布来进行消息传输.
Sentinel 机制很大程度依赖计算机时间, 如果计算机出现故障, 或者进程被阻塞, Sentinel 可能也会出现故障, 从而进入 TLTL 保护模式, 进入 TILT 模式后, 哨兵就不会在起作用. 如果在 30S 内恢复正常, 就会退出 TITL 模式.
以上就是 Redis 哨兵模式操作的相关介绍了, 更多其他指令可以参考官网, Redis 官网 https://redis.io/commands , 谢谢阅读, 希望对你有所帮助.
来源: http://www.bubuko.com/infodetail-3316802.html