Dalam MySQL, split-brain bermaksud bahawa dalam sistem ketersediaan tinggi (HA), apabila dua nod yang disambungkan diputuskan, sistem yang pada asalnya keseluruhannya terbahagi kepada dua nod bebas Pada masa ini, kedua-duanya nod mula bersaing untuk mendapatkan sumber yang dikongsi, mengakibatkan kekacauan sistem dan rasuah data. Untuk sistem HA perkhidmatan tanpa kewarganegaraan, tidak kira sama ada ia adalah split-brain atau tidak tetapi untuk HA perkhidmatan stateful (seperti MySQL), split-brain mesti dihalang dengan ketat.
Persekitaran pengendalian tutorial ini: sistem windows7, versi mysql8, komputer Dell G3.
Split-brain
merujuk kepada sistem ketersediaan tinggi (HA) apabila dua nod yang disambungkan diputuskan sambungan apabila sambungan dibuka sistem yang pada asalnya keseluruhan dipecahkan kepada dua nod bebas Pada masa ini, kedua-dua nod mula bersaing untuk sumber yang dikongsi, yang akan membawa kepada kekacauan sistem dan kerosakan data.
Dalam persekitaran kluster ketersediaan tinggi terdapat nod aktif dan satu atau lebih nod siap sedia yang mengambil alih perkhidmatan apabila nod aktif gagal atau berhenti bertindak balas.
Ini kelihatan seperti andaian yang munasabah sehingga anda mempertimbangkan lapisan rangkaian antara nod. Bagaimana jika laluan rangkaian antara nod gagal?
Kedua-dua nod kini tidak boleh berkomunikasi dengan nod yang lain, dalam hal ini pelayan siap sedia boleh mempromosikan dirinya kepada pelayan aktif atas dasar bahawa ia percaya nod aktif telah gagal. Ini menyebabkan kedua-dua nod menjadi "hidup" kerana setiap nod akan menganggap nod yang lain telah mati. Akibatnya, integriti dan konsistensi data terjejas apabila data berubah pada kedua-dua nod. Ini dipanggil "split-brain".
Untuk HA perkhidmatan tanpa kewarganegaraan, tidak kira sama ada terdapat split-brain atau tidak tetapi untuk HA perkhidmatan stateful (seperti MySQL), otak berpecah mesti dicegah dengan ketat. (Tetapi sesetengah sistem dalam persekitaran pengeluaran mengkonfigurasi perkhidmatan stateful mengikut set HA perkhidmatan tanpa kewarganegaraan, dan hasilnya boleh dibayangkan...)
Cara mencegah otak berpecah kelompok HA
Secara amnya, 2 kaedah digunakan 1) Timbangtara Apabila dua nod tidak bersetuju, penimbang tara pihak ketiga memutuskan keputusan siapa untuk mendengar. Pengadil ini mungkin perkhidmatan kunci, cakera kongsi atau sesuatu yang lain.
2) pagar Apabila status nod tidak dapat ditentukan, bunuh nod yang lain melalui pagar untuk memastikan sumber yang dikongsi dilepaskan sepenuhnya. Premisnya ialah mesti ada peralatan pagar yang boleh dipercayai.
Sebaik-baiknya, kedua-dua perkara di atas tidak sepatutnya hilang. Walau bagaimanapun, jika nod tidak menggunakan sumber yang dikongsi, seperti pangkalan data HA berdasarkan replikasi tuan-hamba, peranti pagar boleh ditinggalkan dengan selamat dan hanya timbang tara dikekalkan. Dan banyak kali tiada peranti pagar tersedia dalam persekitaran kita, seperti dalam hos awan.
Jadi bolehkah kita meninggalkan timbang tara dan hanya menyimpan peranti pagar? tak boleh. Kerana apabila dua nod terputus hubungan antara satu sama lain, mereka akan memagar satu sama lain pada masa yang sama. Jika kaedah pagar adalah but semula, maka kedua-dua mesin akan dimulakan semula secara berterusan. Jika kaedah pagar dimatikan, maka hasilnya mungkin dua nod mati bersama, atau satu boleh bertahan. Tetapi jika sebab dua nod terputus hubungan antara satu sama lain ialah salah satu nod mengalami kegagalan kad rangkaian, dan nod yang terselamat adalah nod yang rosak, maka pengakhirannya akan menjadi tragis. Oleh itu, nod berganda mudah tidak dapat menghalang otak berpecah dalam apa jua keadaan.
Cara melaksanakan strategi di atas
Anda boleh melaksanakan skrip yang mematuhi logik di atas dari awal. Adalah disyorkan untuk menggunakan perisian kluster matang untuk membina, seperti Pacemaker Corosync dan ejen sumber yang sesuai. Keepalived tidak sesuai untuk HA perkhidmatan stateful Walaupun timbang tara dan pagar ditambah kepada penyelesaian, ia sentiasa berasa janggal.
Terdapat juga beberapa langkah berjaga-jaga apabila menggunakan Perentak Jantung Corosync. 1) Memahami fungsi dan prinsip ejen sumber Hanya dengan memahami fungsi dan prinsip Ejen Sumber anda boleh mengetahui senario di mana ia boleh digunakan. Sebagai contoh, ejen sumber pgsql agak lengkap, menyokong replikasi strim segerak dan tak segerak, dan boleh bertukar secara automatik antara keduanya, dan boleh memastikan bahawa data tidak akan hilang semasa replikasi segerak. Tetapi ejen sumber semasa MySQL sangat lemah Tanpa GTID dan tanpa pampasan log, adalah lebih baik untuk tidak menggunakannya dan terus menggunakan MHA (tetapi pastikan anda berjaga-jaga terhadap split-brain apabila menggunakan MHA. ).
2) Pastikan bilangan undi (kuorum) yang sah Kuorum boleh dianggap sebagai mekanisme timbang tara Pacemkaer sendiri Sebilangan besar daripada semua nod dalam kluster memilih penyelaras, dan semua arahan dalam kluster dikeluarkan oleh penyelaras ini, yang dapat menghapuskan masalah otak berpecah dengan sempurna. Agar mekanisme ini berfungsi dengan berkesan, mesti ada sekurang-kurangnya 3 nod dalam gugusan dan tiada dasar kuorum ditetapkan untuk berhenti, yang juga merupakan nilai lalai. (Banyak tutorial menetapkan polisi tiada-kuorum untuk diabaikan demi kemudahan demonstrasi. Jika persekitaran pengeluaran melakukan ini dan tiada mekanisme timbangtara lain, ia sangat berbahaya!)
Namun, jika terdapat hanya 2 nod apa yang perlu dilakukan?
但是如果你有很多双节点集群，找不到那么多用于凑数的节点，又不想把这些双节点集群拉到一起凑成一个大的集群（比如觉得不方便管理）。那么可以考虑第三种方法。 第三种方法是配置一个抢占资源，以及服务和这个抢占资源的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视频教程】
Atas ialah kandungan terperinci Apakah split-brain dalam MySQL?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
mysql mengubah suai nama jadual data
MySQL mencipta prosedur tersimpan
Pangkalan data tiga paradigma
Perbezaan antara mongodb dan mysql
Bagaimana untuk menyemak sama ada kata laluan mysql terlupa
mysql mencipta pangkalan data
tahap pengasingan transaksi lalai mysql
Perbezaan antara sqlserver dan mysql
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
