Percona 的 Fernando Laudares 在「How to setup a PXC cluster with GTIDs (and have async slaves replicating from it!)」這篇裡提到了 Percona XtraDB Cluster 5.6 與 GTIDs 的配合方式。
傳統的 replication 的 binlog 的表示方式是 filename + position,這個是大家已經很熟悉的方式。
digraph { M1 [label="Master 1"]; M2 [label="Master 2"]; S1 [label="Slave 1"]; S2 [label="Slave 2"]; S3 [label="Slave 3"]; S4 [label="Slave 4"]; { rank=same; M1; M2; }; { rank=same; S1; S2; S3; S4; }; S1 -> S2 -> S3-> S4 [style=invis]; M1 -> M2; M2 -> M1; M1 -> {S1, S2, S3, S4}; M2 -> {S1, S2, S3, S4} [color=gray]; }
優點是很簡單 (很好理解,也很容易設定管理),但缺點是 Slave 的 Master 跳動時 (從 Master 1 跳到 Master 2),Slave 可能會漏資料。
原因是出自於 MMM 之類的工具無法知道 Master 1 最後一筆寫入的資料對應到 Master 2 的哪個 binlog 位置。
在 MySQL 5.6 之後多了新的模式,叫做 GTIDs (Global Transaction IDs),把本來 binlog 的 filename + position 改良一下,變成 source_id + transaction_id 的形式。
source_id 是每台機器固定的值,目前是用 UUID 代表,而 transaction_id 則是遞增的流水號。所以也很好理解:「source_id 這台機器的第 n 個 transaction」。
這樣就可以多出很多偵測機制,降低問題發生的機率。
而 PXC 5.6 在這個領域則是因為已經有了自己的 cluster 機制,所以整個 cluster 會共用一組 UUID。這樣就可以避免混用機制而產生複雜的問題。
所以就變成三台 Master 互相切換 (通常 PXC 都是三台以上的奇數機器):
或是其中兩台互相切換 (第三台只跑 garbd 而沒有實際資料時):
我們家只剩下一組 cluster 是 PXC 5.5 (最大的一組),其他都是 PXC 5.6 了。應該要找人 deploy 這個機制降低 Master 跳機時的人力操作成本了...