Galera Cluster for MySQL 安裝手冊文字版 https://galeracluster.com/library/documentation/install-mysql.html
Galera Cluster for MySQL 安裝手冊PPT版 {% pdf /images/galera/galera-mysql-installing.pdf %}
Galera Cluster for MySQL 安裝手冊視頻版 https://galeracluster.com/library/training/videos/galera-mysql-installing.html
配置參數：https://galeracluster.com/library/documentation/mysql-wsrep-options.html#
2.集群安裝詳細步驟2.1 在/etc/yum.repos.d/ 的目錄下新增gelare.repo文件[galera]name = Galerabaseurl = https://releases.galeracluster.com/galera-3/DIST/RELEASE/ARCHgpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.comgpgcheck = 1
[mysql-wsrep]name = MySQL-wsrepbaseurl = https://releases.galeracluster.com/mysql-wsrep-VERSION/DIST/RELEASE/ARCHgpgkey = https://releases.galeracluster.com/GPG-KEY-galeracluster.comgpgcheck = 1注意需要替換掉相應的參數，針對自己的環境作出相應的更改。
VERSION是mysql-wsrep的版本，如5.7；DIST是作業系統，如centos；RELEASE是作業系統版本，如7；ARCH是系統架構，如x86_64；2.2 一鍵安裝源配置好之後，就可以安裝了，只需執行以下命令：
# yum install galera-3 mysql-wsrep-5.7若網絡環境不允許，則可以離線安裝，需要按照下面步驟進行安裝：使用 (yum install -y 包名)命令進行安裝。
安裝順序： 1、 mysql-wsrep-libs-compat-5.7-5.7.23-25.15.el7.x86_64.rpm 2、 mysql-wsrep-common-5.7-5.7.23-25.15.el7.x86_64.rpm 3、 mysql-wsrep-libs-5.7-5.7.23-25.15.el7.x86_64.rpm 4、 mysql-wsrep-devel-5.7-5.7.23-25.15.el7.x86_64.rpm 5、 mysql-wsrep-client-5.7-5.7.23-25.15.el7.x86_64.rpm 6、 mysql-wsrep-server-5.7-5.7.23-25.15.el7.x86_64.rpm 7、 mysql-wsrep-5.7-5.7.23-25.15.el7.x86_64.rpm 8、 mysql-wsrep-test-5.7-5.7.23-25.15.el7.x86_64.rpm（該包在安裝時會提示沒有 mysql-wsrep-server的依賴，使用rpm 加上–nodeps參數安裝，該安裝可忽略） 9、 galera-3-25.3.24-2.el7.x86_64不推薦使用離線安裝方式：雖然yum配置的目錄中存儲的就是離線安裝的包，但是每個作業系統版本不同，需要安裝不同的包；避免後面發生問題，無法定位是否是安裝包版本的問題。
2.3 MySQL初始化--①.初始化mysql# mysqld --initialize
--②.查看默認密碼# grep 'temporary password' /var/log/mysqld.log
--③.更改權限# chown -R mysql:mysql /var/lib/mysql
--④.啟動mysql服務# service mysqld start
--⑤.進入mysql# mysql -uroot -p
--⑥.修改密碼# alter user user() identified by "新密碼";
--⑦.開放遠程登錄授權# GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;# flush privileges;
--⑧.關閉mysql服務# service mysqld stop （注意mysql5.7是mysqld）官方推薦的三步操作法：
# systemctl start mysqld# grep 'temporary password' /var/log/mysqld.log# mysql_secure_installation官方推薦步驟中 mysql_secure_installation 採用交互式設置方式，雖然簡單，但在不熟悉的情況下，建議還是逐個步驟設置，在熟悉後，再使用該命令則效果較好。並且該命令為二進位文件，無法看到具體的執行邏輯源碼。
務必注意點：防火牆狀態一定需要確認關閉，或者允許指定埠訪問，否則會影響集群正常創建！！！
2.4 網絡配置&同步工具安裝關閉防火牆(生產上可開放埠)
# setenforce 0 && systemctl stop firewalld去掉Postfix，這個可能跟MySQL配置有衝突:
安裝rsync包，後面galera集群節點間數據同步會使用該工具。rsync工具使用方法可參考：http://www.ruanyifeng.com/blog/2020/08/rsync.html
2.5 節點配置修改my.cnf
vim /etc/my.cnf，在末尾增加：!includedir /etc/my.cnf.d/修改wsrep.cnf
vim /etc/my.cnf.d/wsrep.cnf節點78上wsrep.cnf完整配置：
[mysqld]server-id=78 #每個節點一個唯一的IDbind-address=0.0.0.0
# common settinglower_case_table_names=0table_open_cache=2048query_cache_size=0query_cache_type=0back_log=500skip-name-resolvesql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
# character settingcharacter-set-server=utf8mb4collation-server=utf8mb4_general_ciinit_connect='SET NAMES utf8mb4'default-time-zone='+8:00'
# slow settingslow_query_log=1slow_query_log_file=/data/mysql_data/mysql_slow/localhost-slow.log # 手動創建目錄，需要使用chown -R mysql:mysql 該目錄權限long_query_time=1log_output=table,filelog_queries_not_using_indexes=1
# innodb settingdefault-storage-engine=innodbinnodb_autoinc_lock_mode=2innodb_locks_unsafe_for_binlog=1innodb_buffer_pool_size=12Ginnodb_max_dirty_pages_pct=75innodb_buffer_pool_chunk_size=128MBinnodb_buffer_pool_instances=8innodb_log_buffer_size=16Minnodb_flush_log_at_trx_commit=1innodb_log_file_size=3072Minnodb_log_files_in_group=2innodb_io_capacity=200innodb_print_all_deadlocks=1innodb_lock_wait_timeout = 50transaction_isolation=REPEATABLE-READ
# client connection settingmax_connections=500max_connect_errors=100000
# wsrepwsrep_on=ONwsrep_provider=/usr/lib64/galera-3/libgalera_smm.so
wsrep_node_name="node78" #node名稱，每個節點名稱唯一wsrep_node_address="192.168.36.78" #本節點地址
wsrep_cluster_name="ztgj_mysql_cluster" #集群名稱，所有節點配置為同一個wsrep_cluster_address="gcomm://192.168.36.78,192.168.36.79,192.168.36.80" #集群中所有節點地址
wsrep_provider_options="gcs.fc_limit=200;gcs.fc_factor=0.8" #修改為本節點地址
wsrep_slave_threads=40wsrep_certify_nonPK=1wsrep_max_ws_rows=131072wsrep_max_ws_size=1073741824wsrep_debug=0wsrep_convert_LOCK_to_trx=0wsrep_retry_autocommit=1wsrep_auto_increment_control=1wsrep_drupal_282555_workaround=0wsrep_causal_reads=0wsrep_notify_cmd=
wsrep_sst_method=rsyncwsrep_sst_auth=root:ztgjwq666 #數據量庫用戶名密碼wsrep_sst_donor="node78,node79,node80" #節點中所有節點的node名稱節點79上wsrep.cnf配置：
server-id=79 #每個節點一個唯一的ID....
wsrep_node_name="node79" #node名稱，每個節點名稱唯一wsrep_node_address="192.168.36.79" #本節點地址節點80上wsrep.cnf配置：
server-id=80 #每個節點一個唯一的ID....
wsrep_node_name="node80" #node名稱，每個節點名稱唯一wsrep_node_address="192.168.36.80" #本節點地址2.6 啟動集群①.啟動首節點
任意選取一個節點，執行：
參看 mysqld_bootstrap 執行內容：
[root@condition-db2 log]# whereis mysqld_bootstrapmysqld_bootstrap: /usr/bin/mysqld_bootstrap
[root@condition-db2 log]# cat /usr/bin/mysqld_bootstrap OLDVAL=$(systemctl show-environment | grep '^MYSQLD_OPTS=')
if [ -z "$OLDVAL" ]; then systemctl set-environment MYSQLD_OPTS="--wsrep-new-cluster" systemctl start mysqld systemctl unset-environment MYSQLD_OPTSelse systemctl set-environment "$OLDVAL --wsrep-new-cluster" systemctl start mysqld systemctl set-environment "$OLDVAL"fi-z 判斷 "$OLDVAL" 變量是否為空，若為空，則 set-environment MYSQLD_OPTS="--wsrep-new-cluster"，然後啟動MySQL systemctl start mysqld，啟動成功後，則 systemctl unset-environment MYSQLD_OPTS 清除設置。
防坑注意點： 若第一次執行 mysqld_bootstrap 中執行啟動mysqld失敗，則不會執行 unset-environment，則後面無論執行多少次啟動，都無法將節點加入到集群中！！！
預防方法： 在每次執行mysqld_bootstrap前，先執行systemctl show-environment | grep '^MYSQLD_OPTS='檢查結果是否為空，若不為空，則手動執行systemctl unset-environment MYSQLD_OPTS 清除參數設置。
檢查啟動結果，不出意外的話，就會顯示1，表明這個集群內現在只有一個節點.
# mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"②.啟動其它節點
登陸到其它節點上，依次執行：
然後再查看wsrep_cluster_size數量
2.7 集群狀態檢查# show status like 'wsrep%';集群完整性檢查
wsrep_cluster_state_uuid：在集群所有節點的值應該是相同的,有不同值的節點,說明其沒有連接入集群. wsrep_cluster_conf_id：正常情況下所有節點上該值是一樣的.如果值不同,說明該節點被臨時」分區」了.當節點之間網絡連接恢復的時候應該會恢復一樣的值. wsrep_cluster_size：如果這個值跟預期的節點數一致,則所有的集群節點已經連接. wsrep_cluster_status：集群組成的狀態.如果不為」Primary」,說明出現」分區」或是」split-brain」狀況.
節點狀態檢查
wsrep_ready：該值為ON,則說明可以接受SQL負載.如果為Off,則需要檢查wsrep_connected. wsrep_connected：如果該值為Off,且wsrep_ready的值也為Off,則說明該節點沒有連接到集群.(可能是wsrep_cluster_address或wsrep_cluster_name等配置錯造成的.具體錯誤需要查看錯誤日誌) wsrep_local_state_comment：如果wsrep_connected為On,但wsrep_ready為OFF,則可以從該項查看原因.
複製健康檢查
wsrep_flow_control_paused：表示複製停止了多長時間.即表明集群因為Slave延遲而慢的程度.值為0~1,越靠近0越好,值為1表示複製完全停止.可優化wsrep_slave_threads的值來改善. wsrep_cert_deps_distance：有多少事務可以並行應用處理.wsrep_slave_threads設置的值不應該高出該值太多. wsrep_flow_control_sent：表示該節點已經停止複製了多少次. wsrep_local_recv_queue_avg：表示slave事務隊列的平均長度.slave瓶頸的預兆. ps：最慢的節點的wsrep_flow_control_sent和wsrep_local_recv_queue_avg這兩個值最高.這兩個值較低的話,相對更好.
檢測慢網絡問題
wsrep_local_send_queue_avg：網絡瓶頸的預兆.如果這個值比較高的話,可能存在網絡瓶
衝突或死鎖的數目
wsrep_last_committed：最後提交的事務數目 wsrep_local_cert_failures和wsrep_local_bf_aborts：回滾,檢測到的衝突數目
3.集群運維指南3.1 Galera狀態文件通常在 /var/lib/mysql 目錄下會存儲Galera的集群信息，也可通過配置datadir來指定Galera存儲位置。在該目錄下主要有三個文件：
①.gvwstate.dat
當節點將Primary Component狀態存儲到磁碟時，會保存為gvwstate.dat文件。如果節點正常關閉，則會刪除該文件。如果群集在節點關閉後繼續運行（即，有其他節點未關閉），則剩餘節點之一將成為Primary Component的主機，並在其文件系統上創建gvwstate.dat文件。
my_uuid: af1027d0-1a04-11ec-86ca-57c930759d43#vwbegview_id: 3 af1027d0-1a04-11ec-86ca-57c930759d43 12bootstrap: 0member: af1027d0-1a04-11ec-86ca-57c930759d43 0member: bb0e7607-1a04-11ec-bd8f-af2b63e25777 0member: e8a96415-1a06-11ec-96da-76f17e3872d7 0#vwend官方文檔：https://galeracluster.com/library/documentation/pc-recovery.html
②.grastate.dat
定位最近狀態的節點、安全引導保護、定位崩潰的節點
# GALERA saved stateversion: 2.1uuid: db2e443c-1a02-11ec-986a-bbd1796395d8seqno: -1safe_to_bootstrap: 0③.galera.cache
galera緩存文件，非可讀文件
官方文檔：https://galeracluster.com/library/kb/customizing-gcache-size.html
3.2 MySQL錯誤日誌系統日誌：/var/log/mysqld.log
mysql錯誤日誌位置查看
# show variables like 'log_error';3.3 集群重啟官方文檔：https://galeracluster.com/library/training/tutorials/restarting-cluster.html
當需要重啟整個Galera群集時，若以錯誤的順序啟動節點，可能會造成災難性後果，並導致數據丟失。
3.3.1 識別最高級別的節點通過比較集群中每個節點上的全局事務ID值，來確定最高級的節點狀態ID。可以在grastate.dat文件中查找，如果grastate.dat文件如下所示，則該節點即為最高級的節點狀態ID：
# GALERA saved stateversion: 2.1uuid: db2e443c-1a02-11ec-986a-bbd1796395d8seqno: 12safe_to_bootstrap: 0若seqno非大於0的值，則需要查找上次提交的事務的序列號，使用--wsrep recover選項運行mysqld，該命令將相應的全局事務ID值列印到錯誤日誌中，然後退出。使用該命令時，mysql服務務必是停止狀態，若mysql服務還未終止，則該命令會一直卡著不會返回，需要手動kill掉該命令。
[root@db2 ~]# mysqld --wsrep-recover --user=mysql[root@db2 ~]# [root@db2 ~]# grep "Recovered position" /var/log/mysqld.log 2021-09-20T11:20:13.844208Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:02021-09-21T05:21:26.637687Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:39:42.770713Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:44:46.217621Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:15.066574Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:12[root@db2 ~]# [root@db2 ~]# mysqld --wsrep-recover --user=mysql[root@db2 ~]# [root@db2 ~]# grep "Recovered position" /var/log/mysqld.log 2021-09-20T11:20:13.844208Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:02021-09-21T05:21:26.637687Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:39:42.770713Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:44:46.217621Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:15.066574Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:122021-09-21T05:48:25.395356Z 0 [Note] WSREP: Recovered position: db2e443c-1a02-11ec-986a-bbd1796395d8:12[root@db2 ~]#該命令無論執行多少次，都只會輸出最後一次的事務ID，該值是節點狀態ID。找到該值後，然後手動更新grastate.dat文件中seqno欄位為輸出結果中的值。
作為替代方案，可以讓mysqld_safe自動恢復，並在下次啟動資料庫伺服器時將值傳遞給資料庫伺服器，通過將grastate.dat文件中safe_to_bootstrap的值設為1，使用mysqld_bootstrap命令啟動該節點，其他節點啟動與以前一致。
3.3.2 「安全引導」保護從版本3.19開始，Galera提供了一個額外的保護，以防止：嘗試使用「可能不是群集關閉之前最後一個節點」來引導啟動群集。如果Galera能夠最終確定哪個節點是最後一個存活的節點，它將被標記為「安全引導」，如下grastate.dat所示：
# GALERA saved stateversion: 2.1uuid: 5981f182-a4cc-11e6-98cc-77fabedd360dseqno: 1234safe_to_bootstrap: 1這樣的節點可用於引導集群，嘗試使用任何其他節點進行引導將導致以下錯誤消息：
2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.It was not the last one to leave the cluster and may not contain all the updates.To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .若要覆蓋此保護，可以編輯「要用作第一個節點」的grastate.dat文件中的safe_to_bootstrap。
在所有節點同時崩潰的情況下，集群找不到任何一個節點來安全引導，當手動編輯grastate.dat文件後，即可為集群指定安全引導節點。
3.3.3 Gcache恢復從版本3.19開始，Galera提供了gcache.recover參數。如果設置為「是」，Galera將在節點啟動時嘗試恢復gcache。如果gcache恢復成功，節點將能夠向其他加入節點提供IST，這可以加快整個集群的總體重啟時間。
Gcache恢復需要讀取整個Gcache文件兩次。對於位於慢速磁碟上的大型gcache文件，此操作可能需要一些時間。Gcache恢復是一項「盡力而為」的操作。如果恢復未成功，則節點將繼續正常運行，但其他節點在嘗試加入時將退回到SST。
3.3.4 識別崩潰節點通過查看grastate.dat文件的內容，可以輕鬆確定節點是否崩潰。如果看起來像下面的示例，那該節點要麼在執行非事務性操作（例如ALTER TABLE）期間崩潰，要麼由於資料庫不一致而中止。
# GALERA saved stateversion: 2.1uuid: 5ee99582-bb8d-11e2-b8e3-23de375c1d30seqno: -1cert_index:如上所述，您可以從InnoDB恢復上次提交的事務的全局事務ID。然而，恢復是毫無意義的。崩潰後，節點狀態可能已損壞，可能無法正常工作。如果群集中沒有一個具有定義良好狀態的節點，則無需保留節點狀態ID。您必須執行徹底的資料庫恢復過程，類似於在獨立資料庫伺服器上使用的過程。恢復一個節點後，將其用作新集群中的第一個節點。
3.4 故障恢復官方文檔：https://galeracluster.com/library/documentation/crash-recovery.html
Galera集群作為一個邏輯實體，控制其節點的狀態、一致性以及整個集群的狀態。與異步複製相比，這樣可以更高效地維護數據完整性，而不會同時丟失多個節點上的安全寫入。然而，可能會出現這樣的情況：資料庫服務停止，沒有節點能夠為請求提供服務，這些場景將在下面的章節中描述。
3.4.1 節點1正常停止在三節點集群（節點 1、2 和 3）中，節點 1 被優雅地停止，用於維護、配置更改等。
在這種情況下，其他節點收到停止節點的「再見」消息，集群規模減小；某些屬性（如仲裁計算或自動增量）會自動更改。一旦節點 1 再次啟動，它就會根據其wsrep_cluster_address中的變量加入集群my.cnf。
如果寫集緩存在節點2或節點3上執行時，在節點1關閉時仍然執行了所有事務，則可以通過IST加入。如果由於donor的gcache中缺少事務而無法進行IST，則由donor做出回退決定，並自動啟動SST。
3.4.2 兩個節點正常停止在3.4.1章節的情景下，集群大小減少到1個，即使是單個剩餘的節點 3 也可以構成了primary組件，可以為客戶端請求提供服務。要將其它節點重新加入集群，只需啟動它們。
但是，當新節點加入集群時，節點 3 將切換到「Donor/Desynced」狀態，因為它必須至少向第一個加入節點提供狀態轉移。在該過程中仍然可以對其進行讀/寫，但可能會慢得多，這取決於在狀態傳輸期間應該發送多少數據。此外，一些負載均衡器可能會認為donor節點無法運行並將其從池中刪除。所以，最好避免只有一個節點up的情況。
如果重新啟動節點 1 和節點 2，請確保節點 2 不使用節點 1 作為狀態轉移donor：節點 1 的 gcache 中可能沒有所有需要的寫集。在配置文件中指定節點 3 節點作為donor並啟動mysql服務：systemctl start mysql
3.4.3 所有三個節點都正常停止集群完全停止，關鍵問題是如何再次初始化。很重要的一點是：節點將其最後執行的位置寫入grastate.dat文件。通過比較此文件中的seqno編號，可以看到哪個是最先進的節點（很可能是最後一個停止的）。必須使用此節點引導集群，否則具有更高先進位置的節點將必須執行完整的 SST 才能加入從不太高級的集群初始化的集群。因此，一些事務將丟失）。要引導第一個節點，請像這樣調用啟動腳本：
//對於 MySQL：$ mysqld_bootstrap --wsrep-new-cluster
//對於 PXC：$ systemctl start mysql@bootstrap.service
//對於 MariaDB：$ galera_new_cluster注意：即使從最高級的節點引導，其他節點的序列號也較低。他們仍然必須通過完整的 SST 加入，因為 Galera Cache 在重新啟動時不會保留。為此，建議在集群完全關閉之前停止寫入集群，以便所有節點可以停在同一位置。
3.4.4 一個節點從集群中消失當一個節點由於斷電、硬體故障、內核崩潰、mysqld 崩潰或通過kill -9使mysqld pid而變得不可用時，剩下的兩個節點觀察到與節點 1 的連接已關閉，並開始嘗試重新連接它。幾次超時後，節點 1 從集群中刪除。quorum會保存更新（三個節點中有兩個已啟動），因此不會發生服務中斷。重新啟動後，節點 1 會自動加入，和「節點 1 正常停止」中所述一樣。
3.4.5 兩個節點從集群中消失兩個節點不可用，其餘節點（節點 3）無法單獨形成quorum。集群必須切換到non-primary模式，其中 MySQL 拒絕提供任何 SQL 查詢。在這種狀態下，節點 3 上的「mysqld」進程仍在運行並且可以連接，但是與data相關的任何語句都失敗並顯示錯誤。如下示例：
mysql> select * from test.sbtest1;ERROR 1047 (08S01): WSREP has not yet prepared node for application use在節點 3 判定它不能訪問節點 1 和節點 2 之前，可以進行讀取。禁止新的寫入。一旦其他節點可用，集群就會自動再次形成。如果節點 2 和節點 3 只是與節點 1 進行網絡隔離，但它們仍然可以相互訪問，則它們將繼續運行，因為它們仍然構成quorum。如果節點 1 和節點 2 崩潰，您需要手動啟用節點 3 上的primary組件，然後才能啟動節點 1 和節點 2。執行此操作的命令是：
mysql> SET GLOBAL wsrep_provider_options='pc.bootstrap=true';這種方法僅適用於其他節點在執行此操作之前已關閉的情況！否則，最終會得到兩個具有不同數據的集群。
3.4.6 所有節點在沒有正確關閉程序的情況下關閉這種情況可能發生在數據中心電源故障或遇到 MySQL 或 Galera 錯誤時。此外，這可能是由於數據一致性被破壞，集群檢測到每個節點具有不同的數據。該文件未更新且不包含有效序列號 (seqno)。grastate.dat可能看起來像這樣：
$ cat /var/lib/mysql/grastate.dat# GALERA saved stateversion: 2.1uuid: 220dcdcb-1629-11e4-add3-aec059ad3734seqno: -1safe_to_bootstrap: 0在這種情況下，您無法確定所有節點都彼此一致。我們不能使用safe_to_bootstrap變量來確定提交了最後一個事務的節點，因為它對於每個節點都設置為 0。除非使用mysqld --wsrep-recover，否則嘗試從此類節點引導將導致失敗。
恢復位置標記為最大數字的節點是最佳引導候選數據。在grastate.dat中，將safe_to_bootstrap變量設置為1，然後，從此節點引導啟動。
3.4.7 由於腦裂，集群失去了主要狀態假設我們有一個由偶數個節點組成的集群：例如，六個。其中三個在一個位置，而另外三個在另一個位置，並且它們失去了網絡連接。避免這種拓撲結構的最佳做法是：如果您不能擁有奇數個實際節點，則可以使用額外的仲裁節點或pc.weight為某些節點設置更高的值。但是當腦裂以任何方式發生時，沒有一個分離的組可以維持仲裁：所有節點必須停止服務請求，集群的兩個部分將不斷嘗試重新連接。
如果你想在網絡連結恢復之前恢復服務，可以使用「3.4.5 兩個節點從集群中消失」中所述的相同命令再次將其中一個組設為主組。
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';此後，你可以處理集群的手動恢復部分，而另一半部分應該能夠在網絡連結恢復後立即使用 IST 自動重新加入。
注意：如果在兩個分離的部分上都設置了 bootstrap 選項，您將最終得到兩個活動的集群實例，而數據可能會彼此分開。在這種情況下恢復網絡連結不會使它們重新加入，直到節點重新啟動並且配置文件中指定的成員再次連接。那麼，由於Galera複製模型真正關心的是數據的一致性：一旦檢測到不一致，節點因數據差異而無法執行行更改語句——將執行緊急關閉，並且是將節點帶回集群的唯一方法是通過完整的 SST。
3.5 集群訪問模式在實際應用中，Galera集群常與haproxy配合，haproxy作為單一入口，將SQL流量分配到後端Galera，注意此處是TCP級別的，而不是SQL語句級別。如果需要SQL語句級別的，可以參考看看MaxScale，相比haproxy方案，各有應用。
實際應用的結構，haproxy作為Galera Cluster的前端，2臺haproxy用keepalived避免單點故障。後端的Galera集群是3個節點，為了避免Galera寫入衝突，在haproxy配置中，實際上只允許一個節點接受寫入，另一個節點帶有backup參數，只有當前允許寫入的節點壞掉，才會自動寫入另一個節點。為了充分利用另一個節點，同時做讀寫分離，在haproxy上監聽兩個埠，例如：3307用於寫入，3308用於讀取。
參考資料Percona Clustercheck https://github.com/olafz/percona-clustercheck
MySQL的Galera Cluster配置說明 http://blog.sina.com.cn/s/blog_704836f40101lixp.html
galera集群啟動異常問題匯總 https://www.cnblogs.com/jinyuanliu/p/10929324.html
MySQL Galera Cluster grastate.dat文件詳解 https://blog.csdn.net/zhongbeida_xue/article/details/110000874