Redis 的哨兵机制中, 如果是多哨兵模式, 哨兵节点之间也是可以相互感知的, 各种搜索之后出来的是千篇一律的一个基础配置文件,
在配置当前哨兵节点的配置文件中, 并没有配置其他哨兵节点的任何信息.
如下是一个哨兵节点的配置信息, 可以看到, 哨兵与哨兵之间没有任何配置, 死活想不明白, 哨兵之间是如何自动识别的.
- #sentinel 端口
- port 26379
- # 工作路径, 注意路径不要和主重复
- dir "./"
- # 守护进程模式
- daemonize yes
- # 关闭保护模式
- protected-mode no
- # 指明日志文件名
- logfile "./sentinel.log"
- # 哨兵监控的 master, 主从配置一样, 这里只用输入 Redis 主节点的 ip/port 和法定人数.
- sentinel monitor mymaster 127.0.0.1 6379 2
- # master 或 slave 多长时间 (默认 30 秒) 不能使用后标记为 s_down 状态.
- sentinel down-after-milliseconds mymaster 5000
- # 若 sentinel 在该配置值内未能完成 failover 操作(即故障时 master/slave 自动切换), 则认为本次 failover 失败.
- sentinel failover-timeout mymaster 18000
- # 设置 master 和 slaves 验证密码
- sentinel auth-pass mymaster root
那么哨兵节点直接是如何自动发现的呢, 或者说从哪里可以体现出来哨兵节点之间的自动发现呢?
既然会自动识别, 因此就怀疑, 哨兵节点启动之后, 会将自动将这些信息记录到配置文件中去, 试了一把, 果不其然.
如下是在 Redis 主从复制的基础上, 依次启用三个哨兵节点的后, sentinel.cnf 的变化情况
可以发现, 当启用了三个哨兵节点之后, sentinel.cnf 配置文件会被自动重写, 主要有一下几点, 如截图从 #Generated by CONFIG REWRITE 开始
1, 增加了一个 sentinel myid (标识哨兵节点的唯一性)
2, 自动追加哨兵节点本身的信息(这样哨兵节点之间就会相互自动发现), 以及 Redis 数据服务的 slave 的信息
3, 自动移除主节点的密码
4,dir 的相对路径被修改为绝对路径
可见, Redis 的哨兵不仅是 Redis 自动故障转义, 而且实现了哨兵节点自己的高可用. 同时对于密码之类的信息, 也是在哨兵节点初始化之后自动移除.
主节点自动故障转移的效果.
来源: http://www.linuxidc.com/Linux/2018-11/155607.htm