redis哨兵架构的基础知识及部署和管理
Posted Mr. Pan
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了redis哨兵架构的基础知识及部署和管理相关的知识，希望对你有一定的参考价值。
一、前言
1、哨兵的介绍
sentinal，中文名是哨兵 哨兵是redis集群架构中非常重要的一个组件，主要功能如下 （1）集群监控，负责监控redis master和slave进程是否正常工作 （2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员 （3）故障转移，如果master node挂掉了，会自动转移到slave node上 （4）配置中心，如果故障转移发生了，通知client客户端新的master地址 哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作 （1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题 （2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了 目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单
2、哨兵的核心知识
（1）哨兵至少需要3个实例，来保证自己的健壮性 （2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性 （3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
3、为什么redis哨兵集群只有2个节点无法正常工作？
哨兵集群必须部署2个以上节点 如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1 +----+ +----+ | M1 |---------| R1 | | S1 | | S2 | +----+ +----+ Configuration: quorum = 1 master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移 同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移 但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行
4、经典的3节点哨兵集群
+----+
| M1 |
| S1 |
+----+
|
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
Configuration: quorum = 2，majority
如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
二、redis哨兵主备切换的数据丢失问题及解决方法
1、两种数据丢失的情况
主备切换的过程，可能会导致数据丢失 （1）异步复制导致的数据丢失 因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了 （2）脑裂导致的数据丢失 脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着 此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master 这个时候，集群里就会有两个master，也就是所谓的脑裂 此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了 因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
2、解决异步复制和脑裂导致的数据丢失
min-slaves-to-write 1 min-slaves-max-lag 10 要求至少有1个slave，数据复制和同步的延迟不能超过10秒 如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了 上面两个配置可以减少异步复制和脑裂导致的数据丢失 （1）减少异步复制的数据丢失 有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内 （2）减少脑裂的数据丢失 如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求 这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失 上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求 因此在脑裂场景下，最多就丢失10秒的数据
三、redis哨兵的核心底层原理
1、sdown和odown转换机制
sdown和odown两种失败状态 sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机 odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机 sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机 sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕
2、哨兵集群的自动发现机制
哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在 每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置 每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在 每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
3、slave配置的自动纠正
哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上
4、slave->master选举算法
如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来 会考虑slave的一些信息 （1）跟master断开连接的时长 （2）slave优先级 （3）复制offset （4）run id 如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下来会对slave进行排序
（1）按照slave优先级进行排序，slave priority越低，优先级就越高
（2）如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
（3）如果上面两个条件都相同，那么选择一个run id比较小的那个slave
5、quorum和majority
每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换 如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换 但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换
6、configuration epoch
哨兵会对一套redis master+slave进行监控，有相应的监控的配置 执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的 如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号
7、configuraiton传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制
这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的
其他的哨兵都是根据版本号的大小来更新自己的master配置的
四、部署sentinel(三节点)
OS：centos7
redis：4.0.12
1、安装redis并配置主从
参考https://www.cnblogs.com/panwenbin-logs/p/10242027.html
https://www.cnblogs.com/panwenbin-logs/p/10257741.html
2、配置sentinel(所有节点，注意bind地址)
[root@redis-master ~]# cd /usr/local/redis #redis解压目录 [root@redis-master redis]# cp sentinel.conf sentinel.conf-bak [root@redis-master redis]# mkdir /etc/sentinal [root@redis-master redis]# mkdir -p /var/sentinal/26379 [root@redis-master redis]# cp sentinel.conf /etc/sentinal/ [root@redis-master redis]# cd /etc/sentinal/ [root@redis-master sentinal]# cat sentinel.conf port 26379 bind 192.168.1.132 #本机地址 dir /var/sentinal/26379 sentinel monitor mymaster 192.168.1.132 6379 2 #mymaster是集群的名称可自定义，IP地为集群中master的地址，注意与bind的区别 6379表示端口 2表示 需要多少哨兵同意才能执行故障转移操作 sentinel down-after-milliseconds mymaster 30000 #超过多少毫秒跟一个redis实例断了连接，哨兵就可能认为这个redis实例挂了 sentinel failover-timeout mymaster 60000 #failover转移时间，超出此时间认为master转移失效，重新开始转移
sentinel parallel-syncs mymaster 1 #新的master别切换之后，同时有多少个slave被切换到去连接新master，重新做同步，数字越低，花费的时间越多
protected-mode no #关闭安全模式，否则会报错
sentinel auth-pass mymaster redis-pass #如果集群设置了密码，需要添加
daemonize yes #后台进程
logfile /var/log/sentinal/sentinal.log #日志路径
启动
[root@redis-master sentinal]# redis-sentinel /etc/sentinal/sentinel.conf #测试，生产应该将命令放入后台执行 22120:X 13 Jan 14:33:30.411 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 22120:X 13 Jan 14:33:30.411 # Redis version=4.0.12, bits=64, commit=00000000, modified=0, pid=22120, just started 22120:X 13 Jan 14:33:30.411 # Configuration loaded 22120:X 13 Jan 14:33:30.413 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._ _.-``__ \'\'-._ _.-`` `. `_. \'\'-._ Redis 4.0.12 (00000000/0) 64 bit .-`` .-```. ```\\/ _.,_ \'\'-._ ( \' , .-` | `, ) Running in sentinel mode |`-._`-...-` __...-.``-._|\'` _.-\'| Port: 26379 | `-._ `._ / _.-\' | PID: 22120 `-._ `-._ `-./ _.-\' _.-\' |`-._`-._ `-.__.-\' _.-\'_.-\'| | `-._`-._ _.-\'_.-\' | http://redis.io `-._ `-._`-.__.-\'_.-\' _.-\' |`-._`-._ `-.__.-\' _.-\'_.-\'| | `-._`-._ _.-\'_.-\' | `-._ `-._`-.__.-\'_.-\' _.-\' `-._ `-.__.-\' _.-\' `-._ _.-\' `-.__.-\' 22120:X 13 Jan 14:33:30.414 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 22120:X 13 Jan 14:33:30.414 # Sentinel ID is 704dddbb7700554d21df80d7be55830b2d4be0a7 22120:X 13 Jan 14:33:30.414 # +monitor master mymaster 192.168.1.132 6379 quorum 2 22120:X 13 Jan 14:33:30.416 * +slave slave 192.168.1.133:6379 192.168.1.133 6379 @ mymaster 192.168.1.132 6379 22120:X 13 Jan 14:33:37.775 * +sentinel sentinel d0864c9cddd5d9dd9165f8ac1c493a226189f093 192.168.1.133 26379 @ mymaster 192.168.1.132 6379 22120:X 13 Jan 14:33:42.751 * +sentinel sentinel 8ab3bf99d413a3810b7e0976fad94f88853b2445 192.168.1.134 26379 @ mymaster 192.168.1.132 6379
检查
[root@redis-master 26379]# redis-cli -h 192.168.1.132 -p 26379 192.168.1.132:26379> sentinel master mymaster #查看master的信息 192.168.1.132:26379> SENTINEL slaves mymaster #查看slave的信息 192.168.1.132:26379> SENTINEL sentinels mymaster #查看sentinel的信息，本机sentinel信息不显示 192.168.1.132:26379> SENTINEL get-master-addr-by-name mymaster #查看redis集群master的IP地址和端口
五、哨兵管理
1、哨兵节点的增加和删除
1.增加sentinal，会自动发现 2.删除sentinal的步骤 （1）停止sentinal进程 （2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态 （3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
2、slave的永久下线
让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行
3、slave切换为Master的优先级
slave->master选举优先级：slave-priority，值越小优先级越高
4、基于哨兵集群架构下的安全认证
每个slave都有可能切换成master，所以每个实例都要配置两个指令
master上启用安全认证，requirepass
master连接口令，masterauth
sentinal，sentinel auth-pass <master-group-name> <pass>
5、容灾演练
通过哨兵看一下当前的master：SENTINEL get-master-addr-by-name mymaster 把master节点kill -9掉，pid文件也删除掉 查看sentinal的日志，是否出现+sdown字样，识别出了master的宕机问题; 然后出现+odown字样，就是指定的quorum哨兵数量，都认为master宕机了 （1）三个哨兵进程都认为master是sdown了 （2）超过quorum指定的哨兵进程都认为sdown之后，就变为odown （3）哨兵1是被选举为要执行后续的主备切换的那个哨兵 （4）哨兵1去新的master（slave）获取了一个新的config version （5）尝试执行failover （6）投票选举出一个slave区切换成master，每隔哨兵都会执行一次投票 （7）让salve，slaveof noone，不让它去做任何节点的slave了; 把slave提拔成master; 旧的master认为不再是master了 （8）哨兵就自动认为之前的132:6379变成了slave了，133:6379变成了master了 （9）哨兵去探查了一下132:6379这个salve的状态，认为它sdown了 所有哨兵选举出了一个，来执行主备切换操作 如果哨兵的majority都存活着，那么就会执行主备切换操作 再通过哨兵看一下master：SENTINEL get-master-addr-by-name mymaster 尝试连接一下新的master 故障恢复，再将旧的master重新启动，查看是否被哨兵自动切换成slave节点 （1）手动杀掉master （2）哨兵能否执行主备切换，将slave切换为master （3）哨兵完成主备切换后，新的master能否使用 （4）故障恢复，将旧的master重新启动 （5）哨兵能否自动将旧的master变为slave，挂接到新的master上面去，而且也是可以使用的
[root@redis-master 26379]# ps aux|grep redis [root@redis-master 26379]# kill -9 22065 查看sentinel日志 .... 22120:X 13 Jan 15:21:35.699 # +sdown master mymaster 192.168.1.132 6379 22120:X 13 Jan 15:21:35.832 # +new-epoch 1 22120:X 13 Jan 15:21:35.834 # +vote-for-leader d0864c9cddd5d9dd9165f8ac1c493a226189f093 1 22120:X 13 Jan 15:21:36.182 # +config-update-from sentinel d0864c9cddd5d9dd9165f8ac1c493a226189f093 192.168.1.133 26379 @ mymaster 192.168.1.132 6379 22120:X 13 Jan 15:21:36.182 # +switch-master mymaster 192.168.1.132 6379 192.168.1.133 6379 22120:X 13 Jan 15:21:36.182 * +slave slave 192.168.1.132:6379 192.168.1.132 6379 @ mymaster 192.168.1.133 6379 22120:X 13 Jan 15:22:06.243 # +sdown slave 192.168.1.132:6379 192.168.1.132 6379 @ mymaster 192.168.1.133 6379
[root@redis-master 26379]# systemctl start redis #启动redis，在查看日志
22120:X 13 Jan 15:23:33.399 # -sdown slave 192.168.1.132:6379 192.168.1.132 6379 @ mymaster 192.168.1.133 6379
[root@redis-master 26379]# redis-cli -h 192.168.1.132 -p 26379
192.168.1.132:26379> SENTINEL get-master-addr-by-name mymaster #虽然旧的master恢复上线后，但是可以看到master并没有进行切换
1) "192.168.1.133"
2) "6379"
#redis状态改变在sentinel的配置文件中也会自动更改
以上是关于redis哨兵架构的基础知识及部署和管理的主要内容，如果未能解决你的问题，请参考以下文章