看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇，裡面提到了 Percona 包的 Galera Cluster，叫 Percona XtraDB Cluster。
Percona 算是把 Galera Cluster 包的比較好的 distribution，是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本，叫做 MariaDB Galera Cluster。
這篇算是很早期使用 PXC 的人的一些感想：(大概是 2012 年導入，當年雲端也還沒流行，在地端上面自己建，對應的 MySQL 底層還是 5.5 的年代)
Percona XtraDB Cluster 建議至少三台
Galera Cluster 的三台可以是兩台有資料的，加上一台沒有資料，這台沒資料的只負責投票組成 quorum，不需要到三台都是大機器，而且這樣的配置也比較單純一點。
另外兩台雖然都可以當 writer 寫入，但實務上會建議都集中在一台寫，這樣可以大幅降低跨機器時產生的 lock contention。
基於上面這個因素，將兩台有資料的機器，一台做 writer，另外一台做 reader 算是常見的架構，然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構，或是後來政治改名為 source-replica 架構)，不要直接參與 Galera Cluster 協定。
(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題，現在有 GUID 後會好一些)
除了 Galera Cluster 外，另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD：因為 DRBD 可以在兩台機器的 block 層做 mirror，所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。
DRBD 的老方法架構很單純，維護成本也很低，但缺點就是 recovery 的時間會高一些：在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID)，而 Galera Cluster 因為等於是 hot-standby，蠻容易就可以做到小於 30 秒。
另外在切換後 warmup 的時間上，Galera Cluster 也是因為 hot-standby 大勝：DRBD 這邊的情境等於是 cold start，資料庫內還有很多東西還沒進到 InnoDB buffer，對應的 SQL query 還不會快。
相比起來 Galera Cluster 看起來是個好東西，但後面運作的機制複雜不少 (而且需要有人維護)，公司如果有專門的 DBOps 會比較好...
不過現在 SSD 變成主流的情況，讀取速度與 random access 的效率都快很多，這使得 DRBD 切換的成本低很多了，很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定，如果這個時間是可以接受的，用 Galera Cluster 的優點可能就沒那麼高了...