Tag: slave

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 跳機時的人力操作成本了...