測試 MariaDB 上 Galera Cluster 的 Isolation

雖然人還在大阪員旅,不過看到這篇很精彩的測試還是先寫下來:「Call me Maybe: MariaDB Galera Cluster」,作者在 Stripe 花了很多時間在測試各種資料庫的資料正確性。

由於 PerconaPercona XtraDB Cluster (PXC) 是基於 Galera Cluster 改出來的,再加上敝公司裡面大量使用 PXC,決定還是趕緊花時間看完整篇文章確認到底講了什麼。

先講目前看到的結論:

  • 作者認為 Galera Cluster 官方宣稱的 SNAPSHOT-ISOLATION (SI) > REPEATABLE-READ (RR) 是有問題的講法,在學理上 SI 與 RR 都低於 SERIALIZABLE (1SR),也都高於 READ-COMMITTED (RC),但兩者之前沒有直接包含。
  • Galera Cluster 的測試結果看起來沒有做到 SI 的要求,不過測試中看起來有達到 READ-UNCOMMITTED (RU),在 RC 的測試中也沒找到問題,不過作者還是懷疑系統有達到 RC 的要求。

另外從其他討論串看起來,當所有人寫入都到同一台就沒有這些狀況,可以達到 1SR 的要求,這也是目前還蠻常見的系統設計,所以這次的問題看起來沒有這麼大。

後面也提到裝 MySQL Cluster 裝了好幾個禮拜還是裝不起來的事情:

Galera is easy to install–I spent weeks trying to set up MySQL Cluster to no avail, and got Galera Cluster running in a matter of hours.

有種,不是很意外的感覺...

Anyway,原文下面的 comment 可以看到 Baron Schwartz 也跑出來討論,另外在 GitHub 上有開始有討論了:「Snapshot Isolation may not be as isolated as one would like」,看起來直接戳破 Galera Cluster 支援 SI 的宣傳詞了,接下來拉板凳繼續看戲吧... XD

Galera Cluster (Percona XtraDB Cluster) 同步速度的改善

Percona 的「State Snapshot Transfer (SST) at a glance」這篇給了 Galera Cluster (也就是 Percona XtraDB Cluster) 在同步速度的改善方案,整篇文章一步一步改善,從 51 分鐘降到 18 分鐘。

劃幾個重點。

首先是同步時的設定可以放到系統 my.cnf[sst] 內,像是這樣:

[sst]
inno-apply-opts="--use-memory=20G"

其中改善最大的也就是 --use-memory,依照作者測試的數據,光這步就從 51 分鐘降到 30 分鐘。不過這邊要小心本來就有跑的 mysqld,如果 OOM 就慘了...

再來講的是 wsrep_slave_threads,不同於上面的 sst only 設定,這是在一般性的 tuning (平常在跑的參數,放在 [mysqld] 內),改完後速度 30 分鐘再提升到 25:32。

然後是壓縮的方式改用支援多 CPU 的 pigz

[sst]
inno-apply-opts="--use-memory=20G"
compressor="pigz"
decompressor="pigz -d"

很明顯是個 shell command 類的設定,所以如果真的想要測的話,可以再從 -1 測到 -9,作者在這邊沒測,不過效果也很明顯了,從 25:32 降到 21 分鐘。

最後一個大的改變是建議有專門同步的節點 (Donor node),這個節點上不會有 SQL query 來影響效能,這樣可以讓 pigz 的效率更高:

Since node2 is not getting application traffic, moving into the Donor state and doing an expensive SST with pigz compression should be relatively safe for the rest of the cluster (in this case, node1).

時間最後降到 18:33。

FreeBSD snapshot 版本復出...

很久前 FreeBSD 有提供 weekly build (還是 daily build?) 讓人安裝,以前還蠻喜歡抓這個版本下來裝,因為解開 ports 的東西不會太舊。現在網路夠快,用 Portsnap 拉一下就抓完了...

不過對於希望能用 -STABLE 的人絕對是一個相當棒的服務 (通常發生在 -STABLE 從 -CURRENT 合併新功能進來時... 這時可以直接裝一台機器測試,而不用先裝 -RELEASE 再 re-compile kernel & world 升級):「FreeBSD Development Snapshot Availability」。

目前針對 10-CURRENT 放出 amd64、i386、powerpc、powerpc64 四個平台,9-STABLE 則是 amd64 與 i386,所以總共是六個支線,檔案在官方的 FTP 站上可以取得:「ftp.freebsd.org/pub/FreeBSD/snapshots/」。

MySQL 5.6 可以唯讀狀態掛起 InnoDB 資料了...

在「InnoDB now works with read-only media」這邊看到 MySQL 從 5.6.7 開始,可以在唯讀狀態掛起 InnoDB 資料:「14.2.6.1. Support for Read-Only Media」。

這對 recovery 相當方便,尤其是人為失誤 (人為下錯指令 TRUNCATE 或是 DROP TABLE) 時可以馬上從 read-only snapshot 掛一份起來複製資料。