MySQL에서 분할 브레인이란 고가용성(HA) 시스템에서 연결된 두 노드의 연결이 끊어지면 원래 전체였던 시스템이 두 개의 독립 노드로 분할되어 공유 리소스를 두고 경쟁하기 시작한다는 의미입니다. 시스템 혼란과 데이터 손상. 상태 비저장 서비스의 HA 시스템의 경우 분할 브레인인지 여부는 중요하지 않지만 상태 저장 서비스(예: MySQL)의 HA의 경우 분할 브레인을 엄격히 방지해야 합니다.
이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.
Split-brain
은 고가용성(HA) 시스템에서 연결된 두 노드의 연결이 끊어지면 원래 전체였던 시스템이 두 개의 독립 노드로 분할되고, 이때 두 노드가 연결되는 것을 의미합니다. 공유 리소스를 놓고 경쟁하기 시작하여 시스템 혼란과 데이터 손상이 발생합니다.
고가용성 클러스터 환경에는 활성 노드와 하나 이상의 대기 노드가 있으며 활성 노드가 실패하거나 응답이 중지되면 서비스를 대신합니다.
노드 간 네트워크 계층을 고려하기 전까지는 이는 합리적인 가정처럼 들립니다. 노드 간 네트워크 경로에 장애가 발생하면 어떻게 되나요?
이제 어느 노드도 다른 노드와 통신할 수 없습니다. 이 경우 대기 서버는 활성 노드가 실패했다고 판단한다는 사실을 기반으로 활성 서버로 승격될 수 있습니다. 이렇게 하면 각 노드가 다른 노드가 죽었다고 생각하기 때문에 두 노드가 모두 "활성" 상태가 됩니다. 결과적으로 두 노드 모두에서 데이터가 변경되므로 데이터 무결성과 일관성이 손상됩니다. 이를 "분할 브레인"이라고 합니다.
상태 비저장 서비스의 HA의 경우 분할 브레인인지 여부는 중요하지 않지만 상태 저장 서비스(예: MySQL)의 경우 분할 브레인을 엄격히 방지해야 합니다. . (그러나 프로덕션 환경의 일부 시스템은 Stateless 서비스 HA 세트에 따라 Stateful 서비스를 구성하며 그 결과는 상상할 수 있습니다...)
HA 클러스터 분할 브레인 방지 방법
일반적으로 2가지 방법을 사용합니다. 1) 중재 두 노드가 동의하지 않으면 제3자의 중재자가 누구의 결정을 들을지 결정합니다. 이 중재자는 잠금 서비스, 공유 디스크 또는 기타 것일 수 있습니다.
2)펜싱 노드의 상태를 확인할 수 없는 경우 펜싱을 통해 다른 노드를 종료하여 공유 리소스가 완전히 해제되도록 해야 합니다. 안정적인 펜스 장비가 있어야 합니다.
이상적으로는 위의 두 가지 모두 누락되어서는 안 됩니다. 그러나 노드가 마스터-슬레이브 복제 기반의 데이터베이스 HA 등 공유 자원을 사용하지 않는 경우 차단 장치를 안전하게 생략하고 쿼럼만 유지할 수 있습니다. 그리고 클라우드 호스트와 같은 우리 환경에는 사용 가능한 펜스 장치가 없는 경우가 많습니다.
그럼 중재는 생략하고 차단장치만 남겨두면 될까요? 캔트. 왜냐하면 두 노드가 서로 연결이 끊어지면 동시에 서로 펜싱을 하게 되기 때문입니다. 펜싱 방법이 재부팅되면 두 시스템이 계속해서 다시 시작됩니다. 펜싱 방법이 전원 꺼지면 결과적으로 두 노드가 함께 죽거나 하나가 살아남을 수 있습니다. 하지만 두 노드가 서로 연락이 끊기는 이유가 그 중 하나의 네트워크 카드에 장애가 발생했기 때문이고, 살아남은 노드가 우연히 결함이 있는 노드라면 결말은 비극적일 것입니다. 따라서 단순한 이중 노드로는 어떠한 경우에도 분할 브레인을 방지할 수 없습니다.
위 전략 구현 방법
위 로직에 맞는 스크립트 세트를 처음부터 구현할 수 있습니다. Pacemaker+Corosync+적절한 리소스 에이전트와 같은 성숙한 클러스터 소프트웨어를 사용하여 빌드하는 것이 좋습니다. Keepalived는 상태 저장 서비스의 HA에는 적합하지 않습니다. 솔루션에 중재 및 울타리를 추가하더라도 항상 어색함을 느낍니다.
Pacemaker+Corosync 솔루션 사용 시 주의사항도 있습니다 1) 리소스 에이전트의 기능과 원리를 이해한다. Resource Agent의 기능과 원리를 이해해야만 이를 적용할 수 있는 시나리오를 알 수 있습니다. 예를 들어, pgsql의 리소스 에이전트는 비교적 완전하고 동기 및 비동기 스트림 복제를 지원하며 둘 사이를 자동으로 전환할 수 있으며 동기 복제 중에 데이터가 손실되지 않도록 보장할 수 있습니다. 하지만 현재 MySQL의 리소스 에이전트는 매우 약합니다. GTID를 사용하지 않고 로그 보상을 하지 않으면 데이터를 잃기 쉽습니다. 이를 사용하지 않고 MHA를 계속 사용하는 것이 좋습니다(단, 배포 시 분할 브레인(split-brain)을 방지해야 합니다. MHA).
2) 법적 득표수(정족수) 보장 쿼럼은 Pacemkaer의 자체 중재 메커니즘으로 생각할 수 있으며, 클러스터에 있는 모든 노드의 대다수가 코디네이터를 선택하고 클러스터의 모든 명령은 이 코디네이터에 의해 발행되므로 분할 브레인 문제를 완벽하게 해결할 수 있습니다. 이 메커니즘이 효과적으로 작동하려면 클러스터에 3개 이상의 노드가 있어야 하며 no-quorum-policy가 기본값인 stop으로 설정되어 있어야 합니다. (많은 튜토리얼에서 시연의 편의를 위해 no-quorum-policy를 무시하도록 설정합니다. 다른 중재 메커니즘 없이 프로덕션 환경에서 동일한 작업이 수행되면 매우 위험합니다!)
하지만 노드가 2개만 있으면 어떻게 되나요?
但是如果你有很多双节点集群，找不到那么多用于凑数的节点，又不想把这些双节点集群拉到一起凑成一个大的集群（比如觉得不方便管理）。那么可以考虑第三种方法。 第三种方法是配置一个抢占资源，以及服务和这个抢占资源的colocation约束，谁抢到抢占资源谁提供服务。这个抢占资源可以是某个锁服务，比如基于zookeeper包装一个，或者干脆自己从头做一个，就像下面这个例子。这个例子是基于http协议的短连接，更细致的做法是使用长连接心跳检测，这样服务端可以及时检出连接断开而释放锁）但是，一定要同时确保这个抢占资源的高可用，可以把提供抢占资源的服务做成lingyig高可用的，也可以简单点，部署3个服务，双节点上个部署一个，第三个部署在另外一个专门的仲裁节点上，至少获取3个锁中的2个才视为取得了锁。这个仲裁节点可以为很多集群提供仲裁服务（因为一个机器只能部署一个Pacemaker实例，否则可以用部署了N个Pacemaker实例的仲裁节点做同样的事情。但是，如非迫不得已，尽量还是采用前面的方法，即满足Pacemaker法定票数，这种方法更简单，可靠。
--------------------------------------------------------------keepalived的脑裂问题----------------------------------------------
1）解决keepalived脑裂问题
检测思路：正常情况下keepalived的VIP地址是在主节点上的，如果在从节点发现了VIP，就设置报警信息。脚本（在从节点上）如下：
[root@slave-ha ~]# vim split-brainc_check.sh #!/bin/bash # 检查脑裂的脚本，在备节点上进行部署 LB01_VIP=192.168.1.229 LB01_IP=192.168.1.129 LB02_IP=192.168.1.130 while true do ping -c 2 -W 3 $LB01_VIP &>/dev/null if [ $? -eq 0 -a `ip add|grep "$LB01_VIP"|wc -l` -eq 1 ];then echo "ha is brain." else echo "ha is ok" fi sleep 5 done 执行结果如下： [root@slave-ha ~]# bash check_split_brain.sh ha is ok ha is ok ha is ok ha is ok 当发现异常时候的执行结果： [root@slave-ha ~]# bash check_split_brain.sh ha is ok ha is ok ha is ok ha is ok ha is brain. ha is brain.
2）曾经碰到的一个keepalived脑裂的问题（如果启用了iptables，不设置"系统接收VRRP协议"的规则，就会出现脑裂）
曾经在做keepalived+Nginx主备架构的环境时，当重启了备用机器后，发现两台机器都拿到了VIP。这也就是意味着出现了keepalived的脑裂现象，检查了两台主机的网络连通状态，发现网络是好的。然后在备机上抓包：
[root@localhost ~]# tcpdump -i eth0|grep VRRP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:10:17.146322 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:17.146577 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:17.146972 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:18.147136 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:18.147576 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:25.151399 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:25.151942 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:26.151703 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:26.152623 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:27.152456 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:27.153261 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:28.152955 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:28.153461 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:29.153766 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:29.155652 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:30.154275 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:30.154587 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:31.155042 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:31.155428 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:32.155539 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:32.155986 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:33.156357 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:33.156979 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 22:10:34.156801 IP 192.168.1.96 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 50, authtype simple, intvl 1s, length 20 22:10:34.156989 IP 192.168.1.54 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 160, authtype simple, intvl 1s, length 20 备机能接收到master发过来的VRRP广播，那为什么还会有脑裂现象？ 接着发现重启后iptables开启着，检查了防火墙配置。发现系统不接收VRRP协议。 于是修改iptables，添加允许系统接收VRRP协议的配置： -A INPUT -i lo -j ACCEPT ----------------------------------------------------------------------------------------- 我自己添加了下面的iptables规则： -A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT #允许组播地址通信 -A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT #允许VRRP（虚拟路由器冗余协）通信 ----------------------------------------------------------------------------------------- 最后重启iptables，发现备机上的VIP没了。 虽然问题解决了，但备机明明能抓到master发来的VRRP广播包，却无法改变自身状态。只能说明网卡接收到数据包是在iptables处理数据包之前发生的事情。
3）预防keepalived脑裂问题
1）可以采用第三方仲裁的方法。由于keepalived体系中主备两台机器所处的状态与对方有关。如果主备机器之间的通信出了网题，就会发生脑裂，此时keepalived体系中会出现双主的情况，产生资源竞争。 2）一般可以引入仲裁来解决这个问题，即每个节点必须判断自身的状态。最简单的一种操作方法是，在主备的keepalived的配置文件中增加check配置，服务器周期性地ping一下网关，如果ping不通则认为自身有问题 。 3）最容易的是借助keepalived提供的vrrp_script及track_script实现。如下所示：
# vim /etc/keepalived/keepalived.conf ...... vrrp_script check_local { script "/root/check_gateway.sh" interval 5 } ...... track_script { check_local } 脚本内容： # cat /root/check_gateway.sh #!/bin/sh VIP=$1 GATEWAY=192.168.1.1 /sbin/arping -I em1 -c 5 -s $VIP $GATEWAY &>/dev/null check_gateway.sh 就是我们的仲裁逻辑，发现ping不通网关，则关闭keepalived service keepalived stop。
4）推荐自己写脚本
写一个while循环，每轮ping网关，累计连续失败的次数，当连续失败达到一定次数则运行service keepalived stop关闭keepalived服务。如果发现又能够ping通网关，再重启keepalived服务。最后在脚本开头再加上脚本是否已经运行的判断逻辑，将该脚本加到crontab里面。
【相关推荐：mysql视频教程】
위 내용은 MySQL의 분할 브레인이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
