目录
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宕机时可以切换。M1是master节点,R1是slave节点,S1和S2是两个哨兵节点。
举例:如果M1:master宕机,s1和s2中只要有1个哨兵认为master宕机就可进行切换,同时s1和s2中会选举出一个哨兵来执行故障转移。同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=2),必须2个哨兵都运行着都同意故障转移,就可以允许执行故障转移将R1切换为M1。
但是如果整个M1和S1运行的机器宕机,那么哨兵只有1个了,此时就没有majority来允许执行故障转移,虽然另外一台机器还有一个R1,但是故障转移不会执行。
4、经典的3节点哨兵集群
+----+
| M1 |
| S1 |
+----+
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
故一般使用3节点哨兵集群,配置Configuration: quorum = 2,majority=2即可。
如果M1所在机器宕机了,那么三个哨兵还剩下2个,S2和S3可以一致认为master宕机,然后选举出一个来执行故障转移。同时3个哨兵的majority是2,所以还剩下的2个哨兵运行着,就可以允许执行故障转移。
5、两种数据丢失的情况
5.1、主备切换的过程,可能会导致数据丢失
(1)异步复制导致的数据丢失
因为master -> slave的复制是异步的,所以可能有部分数据还没复制到slave,master就宕机了,此时这些部分数据就丢失了。
客户端向master node写成功后就返回给客户端OK,接着异步复制给slave node,当还没复制时master宕机则数据丢失。此时sentinal集群检测到master node故障,将slave提升为master node,后续所有的读都基于新的master node。但旧的masternode内存中数据没异步给slave,则丢失。
(2)脑裂导致的数据丢失
脑裂:就是某个master所在机器突然脱离了正常的网络,跟其他slave机器不能连接,但是实际上master还运行着,此时哨兵可能就会认为master宕机了,然后开启选举,将其他slave切换成了master,这个时候,集群里就会有两个master,也就是所谓的脑裂。client与master联通,sentinal与slave联通。
此时虽然某个slave被切换成了master,但是可能client还没来得及切换到新的master,还继续写向旧master,这部分数据可能也丢失,因为旧master再次恢复的时候,会被作为一个slave挂到新的master上去,自己的数据会清空,重新从新的master复制数据,而之前client继续写向旧master的那部分数据没同步给slave,故丢失了。
5.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宕机后损失的数据太多了,那么就拒绝写请求,此时client可能写本地。这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。
当master写入1000条,slave同步900条。如果slave落后master超过10s了,则master就拒绝写请求,则client在自己内存中暂时缓存停顿一会再写等。如果没有该min-slaves-max-lag 10参数,那么等到30分钟时可能master和slave相差800条数据,会导致丢失800条数据。
一般来说,会在client做降级,写到本地磁盘里,在client对外接收请求在做降级即限流,减慢请求涌入的速度。或者client采用将数据临时灌入一个kafka,每隔10分钟到队列取一次数据,尝试重新发回master。
(2)减少脑裂的数据丢失
如果一个master出现了脑裂,跟其他slave丢了连接,那么上面两个配置可以确保说,如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己ack消息,那么就直接拒绝客户端的写请求。这样脑裂后的旧master就不会接受client的新数据,也就避免了数据丢失。
上面的配置就确保了,如果跟任何一个slave丢了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的写请求。因此在脑裂场景下,最多就丢失10秒的数据。
6、redis哨兵核心底层原理
6.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宕机。
6.2、哨兵集群的自动发现机制
哨兵之间的发现是通过redis的pub/sub系统实现,每个哨兵都会往__sentinel__:hello这个channel里发送一个消息,此时所有其他哨兵都可消费到这个消息,并感知到其他的哨兵的存在。
发消息:每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息,内容是自己的host、ip和runid以及对这个master的监控配置。
监听消息: 每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在。
每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步。
个人理解:感觉像一个群聊,每个人每隔2s往群里发送自己信息,其他人也能看到其他人的信息。
6.3、slave配置的自动纠正
哨兵会负责自动纠正slave的一些配置,比如slave如果要成为潜在的master候选人,哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上,比如故障转移之后,那么哨兵会确保它们连接到正确的master上。哨兵自动发现将某个slave提升master,哨兵负责让其他slave修改各自配置连接到正确的master。
6.4、slave->master选举算法
如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个slave来,会考虑slave的一些信息:
- 跟master断开连接的时长
- slave优先级
- 复制offset
- run id
过滤操作:如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍,外加master宕机的时长,那么slave就被认为不适合选举为master:
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下来会对slave进行排序:
slave priority 100
- 按照slave优先级进行排序,slave priority越低,优先级就越高;
- 如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高;
- 如果上面两个条件都相同,那么选择一个run_id比较小的那个slave。
6.5、quorum和majority
每次一个哨兵要做主备切换,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换。
如果quorum < majority,比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换。
但是如果quorum >= majority,那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换。
6.6、configuration epoch
哨兵会对一套redis master+slave进行监控,有相应的监控的配置
执行切换的那个哨兵,会从要切换到的新master(salve->master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的
如果第一个选举出的哨兵切换失败了,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号
6.7、configuraiton传播
哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制。这里之前的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的。其他的哨兵都是根据版本号的大小来更新自己的master配置的
7、动手实操
练习如何操作部署哨兵集群,如何基于哨兵进行故障转移,还有一些企业级的配置方案
7.1、哨兵的配置文件
sentinel.conf 最小的配置
每一个哨兵都可以去监控多个maser-slaves的主从架构,因为可能你的公司里,为不同的项目,部署了多个master-slaves的redis主从集群,相同的一套哨兵集群,就可以去监控不同的多个redis主从集群,你自己给每个redis主从集群分配一个逻辑的名称
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
sentinel monitor mymaster 127.0.0.1 6379
类似这种配置,来指定对一个master的监控,给监控的master指定的一个名称,因为后面分布式集群架构里会讲解,可以配置多个master做数据拆分
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
上面的三个配置,都是针对某个监控的master配置的,给其指定上面分配的名称即可。
上面这段配置,就监控了两个master node
这是最小的哨兵配置,如果发生了master-slave故障转移,或者新的哨兵进程加入哨兵集群,那么哨兵会自动更新自己的配置文件
sentinel monitor master-group-name hostname port quorum
quorum的解释如下:
(1)至少多少个哨兵要一致同意,master进程挂掉了,或者slave进程挂掉了,或者要启动一个故障转移操作
(2)quorum是用来识别故障的,真正执行故障转移的时候,还是要在哨兵集群执行选举,选举一个哨兵进程出来执行故障转移操作。
(3)假设有5个哨兵,quorum设置了2,那么如果5个哨兵中的2个都认为master挂掉了; 2个哨兵中的一个就会做一个选举,选举一个哨兵出来,执行故障转移; 如果5个哨兵中有3个哨兵都是运行的,那么故障转移就会被允许执行。
down-after-milliseconds,超过多少毫秒跟一个redis实例断了连接,哨兵就可能认为这个redis实例挂了。
parallel-syncs,新的master切换之后,同时有多少个slave被切换到去连接新master,重新做同步,数字越低,花费的时间越多。
假设你的redis是1个master,4个slave,然后master宕机了,4个slave中有1个切换成了master,剩下3个slave就要挂到新的master上面去,这个时候,如果parallel-syncs是1,那么3个slave,一个一个地挂接到新的master上面去,1个挂接完,而且从新的master sync完数据之后,再挂接下一个。如果parallel-syncs是3,那么一次性就会把所有slave挂接到新的master上去。
failover-timeout,执行故障转移的timeout超时时长
7.2、在eshop-cache03上再部署一个redis
只要安装redis就可以了,不需要去部署redis实例的启动
wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd /usr/local/tcl8.6.1/unix/
./configure
make && make install
使用redis-3.2.8.tar.gz(截止2017年4月的最新稳定版)
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test
make install
7.3、正式的配置
哨兵默认用26379端口,默认不能跟其他机器在指定端口连通,只能在本地访问
mkdir /etc/sentinal
mkdir -p /var/sentinal/5000
/etc/sentinel/5000.conf
port 5000
bind 192.168.31.187
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.19
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.227
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
7.4、启动哨兵进程
在eshop-cache01、eshop-cache02、eshop-cache03三台机器上,分别启动三个哨兵进程,组成一个集群,观察一下日志的输出
redis-sentinel /etc/sentinal/5000.conf
redis-server /etc/sentinal/5000.conf --sentinel
日志里会显示出来,每个哨兵都能去监控到对应的redis master,并能够自动发现对应的slave
哨兵之间,互相会自动进行发现,用的就是之前说的pub/sub,消息发布和订阅channel消息系统和机制.
7.5、检查哨兵状态
redis-cli -h 192.168.31.187 -p 5000
sentinel master mymaster
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
SENTINEL get-master-addr-by-name mymaster
8、哨兵节点的增加和删除
8.1、增加sentinal,会自动发现
删除sentinal的步骤
(1)停止sentinal进程
(2)SENTINEL RESET *,在所有sentinal上执行,清理所有的master状态
(3)SENTINEL MASTER mastername,在所有sentinal上执行,查看所有sentinal对数量是否达成了一致
8.2、slave的永久下线
让master摘除某个已经下线的slave:SENTINEL RESET mastername,在所有的哨兵上面执行
8.3、slave切换为Master的优先级
slave->master选举优先级:slave-priority,值越小优先级越高
8.4、基于哨兵集群架构下的安全认证
每个slave都有可能切换成master,所以每个实例都要配置两个指令
master上启用安全认证,requirepass
master连接口令,masterauth
sentinal,sentinel auth-pass <master-group-name> <pass>
8.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)哨兵就自动认为之前的187:6379变成了slave了,19:6379变成了master了
(9)哨兵去探查了一下187: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上面去,而且也是可以使用的
8.6、哨兵的生产环境部署
daemonize yes
logfile /var/log/sentinal/5000
mkdir -p /var/log/sentinal/5000