1、 案例一：三個節點，關閉一個
由于維護和配置變更等工作需要，正常關閉節點A，其它節點會收到”good by”資訊，cluster size大小會減少，一些屬性如仲裁計算和自動增長都會自動改變。一旦我們再次啟動節點A，它将會基于my.cnf檔案中的wsrep_cluster_address設定加入叢集.這個過程是很不同于正常複制---加入者節點不會提供任何請求，直到再次與叢集完全同步，是以正連接配接到叢集中提供同等作用的節點是不足的，首次ST必需成功。如果在節點A關閉期間，節點B或節點C的寫資料集gcache中仍然存在他們所有執行過的事務，加入叢集可能通過增量同步(IST，快和輕量)，否則，需要進行全量同步，實際上就是全量二進制資料複制。是以，決定一個最佳貢獻者是重要的，如果因貢獻者gcache丢失了事務，增量同步是不可能發生，則回退決定由貢獻者和全量同步自動代替。
圖示如下：
2、 案例二：三個節點，關閉兩個
節點A和節點B正常關閉。通過熟悉前面的案例，cluster size減少到1。是以，即使是單個節點C，組成一個主要元件，提供用戶端請求。獲得這些節點要傳回到叢集中的需求時，你僅需要啟動他們，可是，當它必需提供ST給首個加入的節點時，節點C切換到“Donor/Desynced”狀态。在那個過程期間，它仍然是可以讀寫的，但是它可能非常慢，取決于它發送的st有多大。是以，一些負載均衡器可能認為貢獻者節點是不可操作的或是從池中移除了。是以，最好避免當隻有一個節點線上時的場景。
需要注意的是，如果你按順序重新開機節點A和節點B，當節點A的gcache可能不含有所有需要的寫資料集時，你可以想要節點B確定不使用節點A作為ST貢獻者。是以指定節點C作為貢獻者的方法(你指定一個帶有wsrep_node_name變量的節點名為node C):
service mysql start --wsrep_sst_donor=nodeC
圖示如下：
3、案例三:三個節點，全部關閉
所有三個節點都正常關閉。叢集已廢，在這個案例中，這問題是如何再次初始化，這裡有一點很重要的要知道，在節點幹淨關閉期間，PXC節點會将最後一個執行位置寫進grastate.dat檔案中，通過比較檔案裡面的seqno号，你會看到最先進位置的節點(最可能是最後關閉的節點)，叢集必需使用這個節點自舉啟動，否則，先進位置的節點必需與後進位置節點執行全量同步初始化加入叢集(和一些事務将會丢失)，
給出一些自舉啟動第一個節點的腳本：
/etc/init.d/mysql bootstrap-pxc或 service mysql bootstrap-pxc或service mysql start --wsrep_new_cluster或service mysql start --wsrep-cluster-address="gcomm://"
或在centos 7中使用系統服務包：systemctl start [email protected]，在老的pxc版本中，自舉啟動叢集，需要在my.cnf檔案中将wsrep_cluster_address變量的内容替換為空：wsrep_cluster_address=gcomm:// 。
圖示如下：
4、案例四：一個節點從叢集中消失
節點A從叢集中消失。消失的意思是指斷電、硬體損壞、核心錯誤，mysql崩潰、kill -9 mysqld程序等，兩個剩餘的節點注意到連接配接A節點已關閉，并嘗試重新連接配接到它。一些逾時後，兩個節點都同意節點A确實關閉和從叢集中正式移除它。仲裁保留（三個中的兩個正常線上），是以，沒有中斷服務發生。重新開機後，節點A按場景一的相同的方法自動加入叢集。
圖示如下：
5、案例五：兩個節點從叢集中消失
節點A和節點B消失，節點C不能組成單獨仲裁，是以叢集切換進入非主模式，mysql拒絕提供任何SQL查詢，在這個狀态中，節點C的mysql程序仍然運作，你能連接配接到它，但任何語句相關的資料失敗都帶有：
mysql> select * from test.t1;
ERROR 1047 (08S01): Unknown command
實際上節點C在一瞬間讀是可能的，直到它決定不能到達節點A和節點B，但沒有立即新寫入的被允許,由于galera的基于複制的認證。
我們将看到剩餘節點的日志是什麼：
140814 0:42:13 [Note] WSREP: commit failed for reason: 3
140814 0:42:13 [Note] WSREP: conflict state: 0
140814 0:42:13 [Note] WSREP: cluster conflict due to certification failure for threads:
140814 0:42:13 [Note] WSREP: Victim thread:
THD: 7, mode: local, state: executing, conflict: cert failure, seqno: -1
SQL: insert into t values (1)
單個節點C正等待它的同等作用的夥伴們再次線上，在一些案例中，當網絡中斷和在所有時間那些節點up時，叢集會再自動組成。如果節點B和節點C與第一節點的網絡斷了，但它們之間仍互相到達，當他們組成仲裁時，他們能保持自己的功能，如果節點A和B崩潰(資料不一緻、bug等)或者由于斷電下線，你需要人工在節點C上啟用主元件，你能将節點A和B帶回叢集中，這個方法，我們可以告訴節點C,你可以單獨組成一個叢集，可以忘記節點A和節點B，這個指令是：
SET GLOBAL wsrep_provider_options='pc.bootstrap=true';
可是，你在做這個操作前，需要多檢查确認其它節點是否真正down了，最有可能最終會有兩個不同的資料叢集。
圖示如下：
6、案例6：所有節點不正确地關閉
這個場景可以發生在資料中心電源失敗，命中mysql或galera bug以緻于所有節點崩潰的案例中，但資料一緻性結果要作出讓步—--叢集檢測到每個節點的資料不同，在那些案例的每一個裡，grastate.dat 檔案不能被更新和不能包含有效的seqno号，它可能看起來像這個：
cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid: 220dcdcb-1629-11e4-add3-aec059ad3734
seqno: -1
cert_index:
在這個案例中，我們不能确信所有節點之間是否一緻的，是以關鍵是要找到最前進節點，用它來自舉啟動叢集，在任何節點上啟動mysql daemon前，你必須通過檢查它的事務狀态來提取最後的序列号，你能按下面方法來做：
[[email protected] ~]# mysqld_safe --wsrep-recover
140821 15:57:15 mysqld_safe Logging to '/var/lib/mysql/percona3_error.log'.
140821 15:57:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140821 15:57:15 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.6bUIqM' --pid-file='/var/lib/mysql/percona3-recover.pid'
140821 15:57:17 mysqld_safe WSREP: Recovered position 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:2
140821 15:57:19 mysqld_safe mysqld from pid file /var/lib/mysql/percona3.pid ended
是以在這個節點上的最後送出的事務序列号是2，現在你需要先從最後節點上自舉啟動，然後再啟動其它節點。 然而，以上方法在新的galera版本3.6及以上是不需要的，自pxc 5.6.19是可用的。
有一個新的選項--- pc.recovery(預設是啟用)，它用于保留叢集狀态到每個節點上的gvwstate.dat檔案裡，當作變量名說明(pc – primary component)，它隻保留一個主要狀态的叢集。
那個檔案的内容看起來像如下：
cat /var/lib/mysql/gvwstate.dat
my_uuid: 76de8ad9-2aac-11e4-8089-d27fd06893b9
#vwbeg
view_id: 3 6c821ecc-2aac-11e4-85a5-56fe513c651f 3
bootstrap: 0
member: 6c821ecc-2aac-11e4-85a5-56fe513c651f 0
member: 6d80ec1b-2aac-11e4-8d1e-b2b2f6caf018 0
member: 76de8ad9-2aac-11e4-8089-d27fd06893b9 0
#vwend
我們能看到以上三個節點叢集是啟動的，多虧了這項新功能，在我們的資料中心停電的情況下，上電後回來，節點将讀取啟動最後的狀态，将嘗試恢複主元件一旦所有成員再次開始看到對方。這使得PXC叢集自動被關閉而無需任何人工幹預恢複。在log中，我們可以看到：
140823 15:28:55 [Note] WSREP: restore pc from disk successfully
(...)
140823 15:29:59 [Note] WSREP: declaring 6c821ecc at tcp://192.168.90.3:4567 stable
140823 15:29:59 [Note] WSREP: declaring 6d80ec1b at tcp://192.168.90.4:4567 stable
140823 15:29:59 [Warning] WSREP: no nodes coming from prim view, prim not possible
140823 15:29:59 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 2, memb_num = 3
140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28]
140823 15:29:59 [Note] WSREP: Received NON-PRIMARY.
140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# -1: non-Primary, number of nodes: 3, my index: 2, protocol version -1
140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
140823 15:29:59 [Note] WSREP: promote to primary component
140823 15:29:59 [Note] WSREP: save pc into disk
140823 15:29:59 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = yes, my_idx = 2, memb_num = 3
140823 15:29:59 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
140823 15:29:59 [Note] WSREP: clear restored view
(...)
140823 15:29:59 [Note] WSREP: Bootstrapped primary 00000000-0000-0000-0000-000000000000 found: 3.
140823 15:29:59 [Note] WSREP: Quorum results:
version = 3,
component = PRIMARY,
conf_id = -1,
members = 3/3 (joined/total),
act_id = 11,
last_appl. = -1,
protocols = 0/6/2 (gcs/repl/appl),
group UUID = 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a
140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28]
140823 15:29:59 [Note] WSREP: Restored state OPEN -> JOINED (11)
140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# 0: Primary, number of nodes: 3, my index: 2, protocol version 2
140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
140823 15:29:59 [Note] WSREP: REPL Protocols: 6 (3, 2)
140823 15:29:59 [Note] WSREP: Service thread queue flushed.
140823 15:29:59 [Note] WSREP: Assign initial position for certification: 11, protocol version: 3
140823 15:29:59 [Note] WSREP: Service thread queue flushed.
140823 15:29:59 [Note] WSREP: Member 1.0 (percona3) synced with group.
140823 15:29:59 [Note] WSREP: Member 2.0 (percona1) synced with group.
140823 15:29:59 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 11)
140823 15:29:59 [Note] WSREP: Synchronized with group, ready for connections
圖示如下：