Galera Cluster (Percona XtraDB Cluster) 對寫入熱點的處理方式

Percona 的「Optimizing Percona XtraDB Cluster for write hotspots」這篇說明了在 Galera Cluster 上發生多個 transaction 衝突時的處理方式。

不過解法是早就已經知道的方法,也就是把寫入都丟到同一台上處理:

So what are your options with PXC when the workload has write hotspots? The most obvious one is to write on a single node: then you will have the same locking model as with a standalone InnoDB server. Performance will not be as good as with a standalone server as you will have to pay for synchronous replication, but you will avoid the very expensive write conflicts.

講解的文章,對之後 troubleshooting 與 performance tuning 有幫助...

Percona XtraDB Cluster 5.6 與 GTIDs 的結合

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

Percona XtraDB Cluster 5.6 GA

放長假的時候總是可以感覺到世界上其他地方是沒放假的...

Percona 宣佈 Percona XtraDB Cluster 5.6 進入 GA (General Availability):「Percona XtraDB Cluster 5.6 GA release now available」。

Percona XtraDB Cluster 5.6 是基於 MySQL 5.6 以及 Galera Cluster 3 的版本。

其實最主要的效能改善是 Oracle 在 MySQL 5.6 上面下的功夫,比起 5.5 好不少。

Percona 官方有提到,現有的 PXC 5.5 可以在不停機的情況下升級到 5.6 (兩台輪流升級),這是件好事 (表示有問題回報時會被處理),但需要實際測試過才知道要怎麼做。所以就先在虛擬機裡面測試看看,沒問題就來規劃...

不過 PXC 上應該還是不能用 memcache interface 吧?之前有提到有問題,而且也沒看到有解決,所以應該還是不能用?

Percona XtraDB Cluster 5.6 的第一個 RC 版本...

Percona XtraDB Cluster 5.6 的第一個 RC 版本公告出來了:「Percona XtraDB Cluster 5.6.15-25.2 first Release Candidate is now available」。

其他的說明沒什麼,但意外看到這點:

Percona XtraDB Cluster now supports stream compression/decompression with new xtrabackup-sst compressor/decompressor options.

在「option compressor/decompressor」這邊可以看到這個設定,功能是在傳輸 SST 的過程壓縮。

看了範例設定,似乎也可以使用 gzip 以外的方式?bzip2 或是 xz 應該是可行的方案?

對跨機房之間的 full resync 應該是有幫助的... 像是 IPsec 的處理能力沒那麼高的時候 :p

Percona XtraDB Cluster (PXC) 開始測試 5.6 版了...

Percona 的 blog 上看到 Percona XtraDB Cluster 出 5.6 版 (測試版) 了:「Percona XtraDB Cluster 5.6.14-25.1 Beta is now available」。

也就是 Galera ClusterMySQL 5.6 上的版本...

在 5.6 上有的功能都會有,也就是說,InnoDB 的 memcache interface,以及 FULLTEXT 功能都可以用?

另外在 comment 也有討論到要如何從 PXC 5.5 升級到 5.6 (不產生 downtime),看起來也是噓要花時間 PoC 過後才能確認... 就算正式釋出,應該還是會觀望看看。

Percona XtraDB Cluster (PXC) 總算出 5.5.29 版本了...

剛剛看到 Percona XtraDB Cluster 5.5.29-23.7.1 的公告了:「Announcing Percona XtraDB Cluster 5.5.29-23.7.1」。

除了修正 bug 外,有很多是讓設定變得簡單的調整 (變得比較不容易中地雷,或是錯誤訊息比較清楚,而非靠 Google 找到答案),像是:

Variable wsrep_node_name was initialized before the glob_hostname, which lead to empty value for wsrep_node_name if it wasn’t set explicitly. Bug fixed #1081389 (Alex Yurchenko).

Percona XtraDB Cluster would crash when binlog_format was set to STATEMENT. This was fixed by introducing the warning message. Bug fixed #1088400 (Seppo Jaakola).

Percona XtraDB Cluster would crash if the node’s own address would be specified in the wsrep_cluster_address variable. Bug fixed #1099413 (Alexey Yurchenko).

該來安排測試了...

從 MySQL (單機) 轉到 Galera Cluster 的前置作業...

codership (Galera Cluster 背後的公司) 剛剛發了一篇文章,說明將 MySQL 轉換到 Galera Cluster 有哪些事情要先處理:「5 Tips for migrating your MySQL server to a Galera Cluster」。

純粹技術上的事情大致上是這樣:

  • 先轉到 InnoDB
  • 每個 Table 都加上 Primary Key。
  • 檢查 Event,確認在 Galera Cluster 裡面會怎麼跑,或是直接拆到 cron server 跑...

另外幾點不是技術上的問題,而是 policy 應該規劃的事情... 把事情列出來,多隻眼睛檢查後再一步一步照表操課。

PS:對於 Galera Cluster 不熟的人可以先去看官方網站以及 Percona 的說明,看不懂就不要用,這樣會比較安全...