所谓脑裂问题就是在多机热备的高可用HA系统中,当两个结点心跳突然断开,纠纷列为两个独立的个体,由于互相失去联系,都认为对方出现了故障,因此都会争抢对方的资源,这就是脑裂问题
举个栗子:
A和B作为一个双机而被集群的两个节点,各自持有集群的一本分数据 a和b ,这时,两机器之间突然无法通信,A认为B挂了,B认为A挂了于是出现:
(1)若A拥有b数据的备份,则A将完整的运行数据,B也同样完整运行数据,这很可能导致两节点同时读写共享数据造成数据损坏
(2)A、B各自仅拥有a、b数据,那么两节点要么均无法启动,要么以瓜分完整共享数据的方式启动
产生脑裂问题的原因:
1.网络问题->网络异常问题造成集群发生物理分离,造成脑裂
2.节点负载->若master结点负载过高,可能造成master结点停止响应,从而脱离集群,集群重新选主,恢复响应后出现脑裂问题
解决措施:
1.集群尽量部署在同一个内网环境中,从而保证各节点通讯的可靠性
2.master结点与data结点分离,保证master结点响应能力
(通过node.master :true 与 node.data:false 来决定是否有成为master结点的资格)
Redis脑裂
解释一下哨兵的作用:
- 每隔一段事件发送信息查看主服务器是否还健在,如果出现了不可控原因导致主服务器死亡,会影响整个集群
- 所以哨兵就会从从服务器中选举一个当主服务器基于上边的环境,这时候网络环境发生了波动导致了主服务器的死亡,这时候哨兵就会开始选举
- 选举完成后一个从服务器变成了主服务器,而恰好这时候原主服务器,重启了,但是这时候只能变成从服务器
总结:
原主服务器接受到客户端的信息后,还未同步到从服务器上就是去连接了,但是重启后又由主变为了从服务器,无法同步数据了,所以这部分数据就丢失了,这就是脑裂问题
解决方法
在配置文件中添加如下配置
min-slaves-to-write 1
min-slaves-max-lag 10第一个参数表示连接到master的最少slave数量(判断有多少个从服务器,达到了要求才发送信息避免了主服务器失连后依旧写入数据)
第二个参数表示slave连接到master的最大延迟时间(减少同步间隔时间,在失连前同步完成)
ES脑裂问题
主动选举机制:
- elasticsearch集群一旦建立起来以后,会选举出一个master,其他都为slave节点。但是具体操作的时候,每个节点都提供写和读的操作。就是说,你不论往哪个节点中做写操作,这个数据也会分配到集群上的所有节点中
- 这里有某个节点挂掉的情况,如果是slave节点挂掉了,那么首先关心,数据会不会丢呢?不会。如果你开启了replicate,那么这个数据一定在别的机器上是有备份的。别的节点上的备份分片会自动升格为这份分片数据的主分片。这里要注意的是这里会有一小段时间的yellow状态时间
当从节点们发现和主节点连接不上了,那么他们会自己决定再选举出一个节点为主节点
- 有5台机器,3台在一个机房,2台在另一个机房,当两个机房之间的联系断了之后,每个机房的节点会自己聚会,推举出一个主节点。这个时候就有两个主节点存在了,当机房之间的联系恢复了之后,这个时候就会出现数据冲突了
解决的办法就是设置参数:
discovery.zen.minimum_master_nodes