1 哨兵模式能做什么？
在上一篇文章中介绍的redis主从复制(http://blog.csdn.net/hylexus/article/details/69360701)虽然可以达到主从复制的目的。
但是并没有考虑高可用，也就是说：当主机宕机后，备机不能及时自动顶替主机，这当然不行的。
这里介绍的redis的哨兵模式能够在后台监控主机是否发生故障，如果发生故障了，可以及时根据投票数自动将从库转换为主库。从而在一定意义上达到高可用。
2 哨兵模式相关的知识点
2.1 哨兵提供的功能
- 监控(monitoring)
- 定期检查监控的master和slave的状态
- 通知(notification)
- 当检测到故障时可以发送通知
- 自动故障转移(auto-failover)
- 检测到master不能工作时,可以将master的下属slave中的一个升级为master
- 客户端连接已经不可用的master时,想客户端返回新的master地址
- 自动发现其他sentinel和从服务器
- Sentinel 可以通过
发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel - Sentinel 可以通过询问主服务器来获得
所有从服务器的信息
- Sentinel 可以通过
- sentinel配置自动持久化
- 当 Sentinel 接收到一个新的配置， 或者当领头 Sentinel 为主服务器创建一个新的配置时， 这个配置会与配置纪元一起被保存到磁盘里面
- 停止和重启 Sentinel 进程都是安全的
2.2 主观下线和客观下线
sentinel会定时向其所监控的服务器发送ping命令以询问服务器是否还正常地活着.
如果服务器的回应是有效回复,则认为该服务器还正常地活着.有效回复有以下三类:
- 返回
+PONG - 返回
-LOADING - 返回
-MASTERDOWN
换言之:如果服务器的回应不是以上三种之一，或者在指定的时间内没有回复，都将被认为是无效的回复.
另外需要注意的是：
如果 master-down-after-milliseconds 选项的值为 60000 ms（60 s）， 那么即使服务器在第59 s时返回至少一次有效回复， 这个服务器就仍然会被认为是处于正常状态的。
主观下线和客观下线
- 主观下线(Subjectively Down==sdown)：单个 Sentinel 实例对服务器做出的下线判断
- 客观下线(Objectively Down==odown)：多个 Sentinel 实例都对某服务器得出
sdown的判断
2.3 哨兵配置文件
配置文件中的选项
- down-after-milliseconds : 多少
毫秒内得不到服务器的回应时sentinel可以认为该服务器已经下线 - parallel-syncs : 在完成故障转移时最多可以有几个slave从新的master同步数据
- myid ：sentinel自身的ID,和zookeeper集群中的myid类似
- port ：指定sentinel的端口(默认是redis示例端口前加个2比如26379)
一点说明
其实你可以指定一个最小化的配置,其他的配置项redis会帮你生成。
比如，你可以只指定sentinel monitor <name> <host> <port> <count>.其他项都会自动生成.
当然，你最好将保护模式关闭。
配置文件示例
# 哨兵自己的id,和zookeeper中的myid类似
sentinel myid 37a94ac96520c311ca2976d56e716e3bbb4e9111
# 关闭保护模式(和redis.conf中的配置类似)
protected-mode no
# 监控名为master-test的集群
sentinel monitor master-test 192.168.1.131 6379 2
# 多少毫秒内sentinel可以认为他监控的对象已经断线
sentinel down-after-milliseconds master-test 10000
# 故障转移的超时时间
sentinel failover-timeout master-test 100002.4 故障转移过程
- 检测到
master已经进入sdown(客观下线)状态 - 对
当前纪元进行自增，并尝试成为leader-sentinel
- 没能成为
leader-sentinel
- 在设定的
failover-timeout的两倍之后， 重新尝试
- 在设定的
- 成功成为
leader-sentinel
- 选出一个
slave，并升级为master - 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新
- 向已下线主服务器的从服务器发送
SLAVEOF命令， 让它们去复制新的主服务器 - 当所有从服务器都已经开始复制新的主服务器时,
leader-sentinel终止这次故障转移操作
- 选出一个
- 没能成为
3 配置示例
3.1 说明
- 为方便操作此处用主机名代替IP操作
- 整个结构还是上一篇文章中的一主二从
- 三个redis分别位于三台主机上
3.2 配置
- 哨兵配置文件(三台主机是一致的)
sentinel monitor master-test h1 6379 2
protected-mode no
# 以下两项不是必须的(此处只是为了较快的看到变化才缩短了时间配置)
sentinel down-after-milliseconds master-test 10000
sentinel failover-timeout master-test 100003.3 启动
- 启动redis实例
# 启动master
[root@h1 redis]$ redis-server redis.conf
# 启动slave h1
[root@h2 redis]$ redis-server redis.conf --slaveof h1 6379
# 启动slave h2
[root@h3 redis]$ redis-server redis.conf --slaveof h1 6379- 启动sentinel实例(三台机器一样的命令)
[root@h1 redis]$ redis-sentinel sentinel.conf此时可以看看redis自动生成的哨兵配置文件内容:
[root@h1 redis]$ cat sentinel.conf
port 26379
sentinel myid 37a94ac96520c311ca2976d56e716e3bbb4e9111
protected-mode no
# Generated by CONFIG REWRITE
dir "/data/redis"
sentinel monitor master-test 192.168.1.131 6379 2
sentinel down-after-milliseconds master-test 10000
sentinel failover-timeout master-test 10000
sentinel config-epoch master-test 4
sentinel leader-epoch master-test 4
sentinel known-slave master-test 192.168.1.132 6379
sentinel known-slave master-test 192.168.1.133 6379
sentinel known-sentinel master-test 192.168.1.132 26379 ac72dd0def3cf1ee47bab9dba9d4454693a2c222
sentinel known-sentinel master-test 192.168.1.133 26379 3dcc2ef2b3aff48d61afb0ae041ce08e59e4b333
sentinel current-epoch 4- sentinel的日志输出
# 当前sentinel的ID
Sentinel ID is 37a94ac96520c311ca2976d56e716e3bbb4e9111
# 当前监控的master
+monitor master master-test 192.168.1.133 6379 quorum 2
# 检测到了其他的sentinel
+sentinel sentinel ac72dd0def3cf1ee47bab9dba9d4454693a2c222 192.168.1.132 26379 @ master-test 192.168.1.133 6379
# 检测到了其他的sentinel
+sentinel sentinel 3dcc2ef2b3aff48d61afb0ae041ce08e59e4b333 192.168.1.133 26379 @ master-test 192.168.1.133 6379
# 检测到的master的下属slave
+slave slave 192.168.1.132:6379 192.168.1.132 6379 @ master-test 192.168.1.131 6379
+slave slave 192.168.1.133:6379 192.168.1.133 6379 @ master-test 192.168.1.131 63793.4 测试
- 手动停止主机h1
[root@h1 redis]$ redis-cli shutdown此时看看h1上哨兵的日志输出：
# h1主观下线
+sdown master master-test 192.168.1.131 6379
# h1客观下线
+odown master master-test 192.168.1.131 6379 #quorum 3/2
# 开始尝试故障转移
+try-failover master master-test 192.168.1.131 6379
………………
# 最终将h2选为新的master
+switch-master master-test 192.168.1.131 6379 192.168.1.132 6379- 再次启动h1
[root@h1 redis]$ redis-server redis.conf此时可以看到类似如下输出:
# h1的主观下线状态被取消
-sdown slave 192.168.1.131:6379 192.168.1.131 6379 @ master-test 192.168.1.132 6379
# 原来的master(h1)回来后被转成了当前master(h2)的slave
+convert-to-slave slave 192.168.1.131:6379 192.168.1.131 6379 @ master-test 192.168.1.132 6379- 同时还有一点更牛逼的是：
# 此时查看h1上redis的配置文件中关于slave的配置已经被自动修改了
[root@h1 redis]$ cat redis.conf | grep slaveof
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# slaveof <masterip> <masterport>
# slaveof h1 6379
slaveof 192.168.1.132 6379 # *****这个是自动修改过的****
[root@h1 redis]$
# h3的配置文件也被修改过了
[root@h3 redis]$ cat redis.conf | grep slaveof
# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# slaveof <masterip> <masterport>
slaveof 192.168.1.132 6379
[root@h3 redis]$ 3.5 sentinel日志输出
以下内容来自:http://www.redis.cn/topics/sentinel.html
- +reset-master ：主服务器已被重置
- +slave ：一个新的从服务器已经被 Sentinel 识别并关联。
- +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
- +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
- failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
- failover-end-for-timeout ：故障转移因为超时而中止
- failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了
- no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
- +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
- +sdown ：给定的实例现在处于主观下线状态。
- -sdown ：给定的实例已经不再处于主观下线状态。
- +odown ：给定的实例现在处于客观下线状态。
- -odown ：给定的实例已经不再处于客观下线状态。
总结
主从复制+哨兵可以解决高可用和部分高性能。
之所以说是部分高性能是因为主从复制可以提供读的性能，但是写操作依然是单点master负责。
后续的有关redis集群的文章将介绍这方面的内容。
扫一扫
956
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
