Was ist Split-Brain in MySQL?

In MySQL bedeutet Split-Brain, dass in einem Hochverfügbarkeitssystem (HA) das System, das ursprünglich ein Ganzes war, in zwei unabhängige Knoten aufgeteilt wird, die um gemeinsam genutzte Ressourcen konkurrieren Systemchaos und Datenkorruption. Für das HA-System zustandsloser Dienste spielt es keine Rolle, ob es Split-Brain ist oder nicht; für das HA-System zustandsbehafteter Dienste (wie MySQL) muss Split-Brain jedoch strikt verhindert werden.

Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.

Split-Brain

bedeutet, dass in einem Hochverfügbarkeitssystem (HA) beim Trennen der beiden verbundenen Knoten das System, das ursprünglich ein Ganzes war, in zwei unabhängige Knoten aufgeteilt wird, zu diesem Zeitpunkt die beiden Knoten beginnen, um gemeinsame Ressourcen zu konkurrieren, was zu Systemchaos und Datenkorruption führt.

In einer Hochverfügbarkeits-Clusterumgebung gibt es einen aktiven Knoten und einen oder mehrere Standby-Knoten, die den Dienst übernehmen, wenn der aktive Knoten ausfällt oder nicht mehr reagiert.

Das klingt nach einer vernünftigen Annahme, bis man die Netzwerkschichten zwischen Knoten berücksichtigt. Was passiert, wenn der Netzwerkpfad zwischen Knoten ausfällt?

Keiner der Knoten kann jetzt mit dem anderen Knoten kommunizieren. In diesem Fall kann sich der Standby-Server selbst zum aktiven Server hochstufen, weil er glaubt, dass der aktive Knoten ausgefallen ist. Dies führt dazu, dass beide Knoten „lebendig“ werden, da jeder Knoten denkt, der andere Knoten sei tot. Infolgedessen werden Datenintegrität und -konsistenz beeinträchtigt, wenn sich Daten auf beiden Knoten ändern. Dies wird als „Split-Brain“ bezeichnet.

Für HA von zustandslosen Diensten spielt es keine Rolle, ob es sich um Split-Brain handelt oder nicht, aber für HA von zustandsbehafteten Diensten (wie MySQL) muss es unbedingt Split-Brain sein verhindert. (Einige Systeme in Produktionsumgebungen konfigurieren jedoch zustandsbehaftete Dienste gemäß dem HA-Satz zustandsloser Dienste, und die Ergebnisse sind vorstellbar ...)

So verhindern Sie HA-Cluster-Brainsplit

Im Allgemeinen werden 2 Methoden verwendet 1) Schiedsverfahren Wenn sich zwei Knoten nicht einig sind, entscheidet der Schiedsrichter des Dritten, auf wessen Entscheidung er hört. Dieser Arbiter kann ein Sperrdienst, eine gemeinsam genutzte Festplatte oder etwas anderes sein.

2)Fechten Wenn der Status eines Knotens nicht bestimmt werden kann, töten Sie den anderen Knoten durch Fencing, um sicherzustellen, dass gemeinsam genutzte Ressourcen vollständig freigegeben werden. Voraussetzung ist, dass zuverlässige Fencing-Geräte vorhanden sind.

Idealerweise sollte keines der oben genannten Dinge fehlen. Wenn der Knoten jedoch keine gemeinsam genutzten Ressourcen nutzt, wie z. B. Datenbank-HA auf Basis der Master-Slave-Replikation, kann das Fencing-Gerät getrost weggelassen werden und nur das Quorum bleibt erhalten. Und oft sind in unserer Umgebung keine Fence-Geräte verfügbar, beispielsweise in Cloud-Hosts.

Können wir also auf die Schlichtung verzichten und nur die Zaunanlage behalten? Kippen. Denn wenn zwei Knoten den Kontakt zueinander verlieren, grenzen sie sich gleichzeitig gegenseitig ein. Wenn die Fencing-Methode „Neustart“ lautet, werden die beiden Maschinen fortlaufend neu gestartet. Wenn die Fencing-Methode ausgeschaltet ist, kann es dazu kommen, dass zwei Knoten gleichzeitig sterben oder einer überlebt. Aber wenn der Grund dafür, dass zwei Knoten den Kontakt zueinander verlieren, darin besteht, dass einer der Knoten einen Netzwerkkartenfehler hat und derjenige, der überlebt, zufällig der fehlerhafte Knoten ist, dann wird das Ende tragisch sein. Daher kann ein einfacher Doppelknoten eine Spaltung des Gehirns in keinem Fall verhindern.

So implementieren Sie die obige Strategie

Sie können eine Reihe von Skripten implementieren, die der obigen Logik von Grund auf entsprechen. Es wird empfohlen, zum Erstellen ausgereifte Cluster-Software zu verwenden, z. B. Pacemaker+Corosync+geeigneter Ressourcenagent. Keepalived ist nicht für HA von zustandsbehafteten Diensten geeignet. Selbst wenn der Lösung Schlichtung und Zäune hinzugefügt werden, fühlt es sich immer umständlich an.

Bei der Verwendung der Pacemaker+Corosync-Lösung sind auch einige Vorsichtsmaßnahmen zu beachten 1) Verstehen Sie die Funktionen und Prinzipien von Ressourcenagenten Nur wenn Sie die Funktionen und Prinzipien des Resource Agent verstehen, können Sie die Szenarien kennen, in denen er anwendbar ist. Beispielsweise ist der Ressourcenagent von pgsql relativ vollständig, unterstützt die synchrone und asynchrone Stream-Replikation, kann automatisch zwischen beiden wechseln und sicherstellen, dass während der synchronen Replikation keine Daten verloren gehen. Der aktuelle Ressourcenagent von MySQL ist jedoch sehr schwach. Ohne GTID und ohne Protokollkompensation kann es leicht zu Datenverlusten kommen. Es ist besser, ihn nicht zu verwenden und weiterhin MHA zu verwenden (achten Sie jedoch darauf, sich bei der Bereitstellung vor Split-Brain zu schützen). MHA).

2) Sicherstellung der gesetzlichen Stimmenzahl (Quorum) Quorum kann als Pacemkaers eigener Schlichtungsmechanismus betrachtet werden. Die Mehrheit aller Knoten im Cluster wählt einen Koordinator aus, und alle Anweisungen im Cluster werden von diesem Koordinator ausgegeben, wodurch das Split-Brain-Problem perfekt beseitigt werden kann. Damit dieser Mechanismus effektiv funktioniert, müssen mindestens 3 Knoten im Cluster vorhanden sein und die No-Quorum-Policy ist auf „Stopp“ eingestellt, was auch der Standardwert ist. (In vielen Tutorials wird zur Vereinfachung der Demonstration die No-Quorum-Policy auf Ignorieren festgelegt. Wenn dasselbe in der Produktionsumgebung ohne andere Schlichtungsmechanismen durchgeführt wird, ist dies sehr gefährlich!)

Aber was ist, wenn es nur zwei Knoten gibt?

• 一是拉一个机子借用一下凑足3个节点，再设置location限制，不让资源分配到那个节点上。
• 二是把多个不满足quorum小集群拉到一起，组成一个大的集群，同样适用location限制控制资源的分配的位置。

但是如果你有很多双节点集群，找不到那么多用于凑数的节点，又不想把这些双节点集群拉到一起凑成一个大的集群（比如觉得不方便管理）。那么可以考虑第三种方法。 第三种方法是配置一个抢占资源，以及服务和这个抢占资源的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视频教程】

Das obige ist der detaillierte Inhalt vonWas ist Split-Brain in MySQL?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!