Galera Cluster 不必要的 SST 行為的改善

Percona 的人解釋了 Galera Cluster 為什麼在某些情況下會需要 SST (整份重傳) 而不是 IST (傳最後造成差異的部分),以及開發商在 3.19 版對應的改進:「Galera Cache (gcache) is finally recoverable on restart」。

原因在於 IST 所需要的記錄會在重開機時消失,所以當其他節點加入時沒辦法給,只好給 SST:

The DONOR node caches missing write-sets in Galera cache, but on restart this cache is wiped clean and restarted fresh. So the DONOR node doesn’t have a Galera cache to donate missing write-sets.

gcache.recover 這個參數打開後就會啟用記錄,另外也可以挑著開就好:

The user can set this option for all nodes, or selective nodes, based on disk usage.

另外最重要的是,之後的版本才會有,所以得繼續等...:

And yes, Percona XtraDB Cluster inherits this feature in its upcoming release.

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。

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