Tag: xtradb

Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇，裡面提到了 Percona 包的 Galera Cluster，叫 Percona XtraDB Cluster。

Percona 算是把 Galera Cluster 包的比較好的 distribution，是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本，叫做 MariaDB Galera Cluster。

這篇算是很早期使用 PXC 的人的一些感想：(大概是 2012 年導入，當年雲端也還沒流行，在地端上面自己建，對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的，加上一台沒有資料，這台沒資料的只負責投票組成 quorum，不需要到三台都是大機器，而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入，但實務上會建議都集中在一台寫，這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素，將兩台有資料的機器，一台做 writer，另外一台做 reader 算是常見的架構，然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構，或是後來政治改名為 source-replica 架構)，不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題，現在有 GUID 後會好一些)

除了 Galera Cluster 外，另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD：因為 DRBD 可以在兩台機器的 block 層做 mirror，所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純，維護成本也很低，但缺點就是 recovery 的時間會高一些：在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID)，而 Galera Cluster 因為等於是 hot-standby，蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上，Galera Cluster 也是因為 hot-standby 大勝：DRBD 這邊的情境等於是 cold start，資料庫內還有很多東西還沒進到 InnoDB buffer，對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西，但後面運作的機制複雜不少 (而且需要有人維護)，公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況，讀取速度與 random access 的效率都快很多，這使得 DRBD 切換的成本低很多了，很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定，如果這個時間是可以接受的，用 Galera Cluster 的優點可能就沒那麼高了...

在 Galera Cluster 上的 DDL 操作 (e.g. ALTER TABLE)

Percona 整理了一份關於 Galara Cluster 上 DDL 操作的一些技巧，這包括了 Percona XtraDB Cluster 與 MariaDB 的版本：「How to Perform Compatible Schema Changes in Percona XtraDB Cluster (Advanced Alternative)?」。

在不知道這些技巧前，一般都是拿 Percona Toolkit 裡的 pt-online-schema-change 來降低影響 (可以降的非常低)，所以這些技巧算是額外知識，另外在某些極端無法使用 pt-online-schema-change 的情境下也可以拿來用...

裡面的重點就是 wsrep_OSU_method 這個參數，預設的值 TOI 就是一般性的常識，所有的指令都會被傳到每一台資料庫上執行，而 RSU 則是會故意不讓 DDL 操作 (像是 ALTER TABLE) 被 replicate 到其他機器，需要由管理者自己到每台機器上執行。

利用這個設定，加上透過工具將流量導到不同後端的資料庫上，就有機會分批進行修改，而不需要透過 pt-online-schema-change 這種工具。

在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7

在 Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去，但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況，用的時候自己要注意。

另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來，但有 workaround 可以硬裝進去，要玩的人也可以參考一下 XD

這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04，做一些操作時才發現是 14.04...)

Percona 的人接受 AWS 的建議，重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...

去年年底的時候 Percona 的人在 AWS 上測試 Percona XtraDB Cluster 的效能，尤其是針對底層應該選擇哪種 EBS 的部分給了一些建議。可以參考先前寫的「Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)」這篇。

當時的建議是用 io1，雖然是比較貴，但對於效能比較好。

而後來 Percona 的人收到 AWS 工程師的建議，可以用另外一個方式，可以在 gp2 上拉出類似的效能，但成本會比 io1 低不少：「Percona XtraDB Cluster on Amazon GP2 Volumes」。

這個方式是利用 gp2 會依照空間大小，計算可用的 IOPS。在官方的文件裡是這樣描述 gp2 的效能 (IOPS)：

General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver the provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.

在這個前提下，需要 10000 IOPS 的效能會需要 3.3TB 以上的空間，所以 Percona 就被 AWS 的工程師建議直接拉高空間重新測試：

After publishing our material, Amazon engineers pointed that we should try GP2 volumes with the size allocated to provide 10000 IOPS. If we allocated volumes with size 3.3 TiB or more, we should achieve 10000 IOPS.

首先是測出來的效能，可以看到沒有太大差異：

接下來就比較儲存成本，大約是 io1 版本的一半價錢：

如上面文件中提到的，gp1 不完全保證效能，但統計出來經常能夠提供出 3 IOPS/GB 的效能。而 io1 則是保證效能，不太需要擔心效能不穩定的問題。就是這個差異，反應到成本上面就有蠻大的差距。善用這點設計系統，應該會對整體成本有蠻大的幫助... (但對 latency 就未必了，尤其是 P99 之類的數值)

算是另外一種搞法讓大家可以考慮...

Percona XtraDB Cluster 裡各種與 LOCK 相關的指令會產生的效果

在「FLUSH and LOCK Handling in Percona XtraDB Cluster」這邊看到在 Percona XtraDB Cluster 內各種不同形式的 LOCK 指令會有不同的效果。有些跟一開始用的印象已經不太一樣了...

FLUSH TABLE WITH READ LOCK 與 FLUSH TABLE <tablename> (WITH READ LOCK|FOR EXPORT) 都會直接讓整個 node 卡住，但 LOCK TABLE <tablename> READ/WRITE 就只會卡對應的表格，另外 GET_LOCK 本來應該是完全不支援，現在似乎變成 experimental 的功能了 (參考「PXC Strict Mode」這邊)，這樣一來 MogileFS 的資料庫部分就可以在上面跑了嗎？(當初就是因為這個問題而另外弄一組 DRBD + Heartbeat 的 MySQL 起來跑 XD)

之後看一下什麼時候加進去的...

Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)

Percona 的人分析了在 Amazon EC2 上跑 Percona XtraDB Cluster (PXC) 效能 (I/O bound)：「Best Practices for Percona XtraDB Cluster on AWS」。

先看他們做出來的圖：

直接跳到結論的地方。如果資料可以掉，用 i3 本地 storage 的效能是最好的，如果要資料不能掉，用 EBS 的 Provisioned IOPS SSD (io1) 的效能會比 General Purpose (gp2) 好很多。

另外 instance type 的選擇上，避免用 {i3,r4}.large，因為測試出來發現 {i3,r4}.xlarge 的效能好不只一倍。

不過 Aurora 的 Multi-master 已經在 Preview 了啊，如果 Percona 的人拿到帳號的話，應該會有單位成本的效能比較可以看...

Percona XtraDB Cluster 解釋最近的版本為什麼可以再度提昇效能

Percona XtraDB Cluster 最近的一個版本宣稱效能大幅提昇，這篇試著解釋原因：「How We Made Percona XtraDB Cluster Scale」。

裡面提了三個情境，解釋了這些效能問題以及解法，進而帶出這次的效能提昇：

With these three main optimizations, and some small tweaks, we have tuned Percona XtraDB Cluster to scale better and made it fast enough for the growing demands of your applications. All of this is available with the recently released Percona XtraDB Cluster 5.7.17-29.20. Give it a try and watch your application scale in a multi-master environment, making Percona XtraDB Cluster the best fit for your HA workloads.

查看 Percona XtraDB Cluster 在 IST 時的進度

Percona 的「Tracking IST Progress in Percona XtraDB Cluster」這篇介紹了 PXC 在 IST 時的進度。

是個新功能，很簡單的可以看到目前進度，也可以拿來當作 health check 的一部分，避免開機剛起來時開始提供服務：

mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+--------------------------------------------------------+
| Variable_name | Value |
+--------------------------+--------------------------------------------------------+
| wsrep_ist_receive_status | 3% complete, received seqno 1421771 of 1415410-1589676 |
+--------------------------+--------------------------------------------------------+
1 row in set (0.00 sec)
....
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+---------------------------------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------------------------------+
| wsrep_ist_receive_status | 52% complete, received seqno 1506799 of 1415410-1589676 |
+--------------------------+---------------------------------------------------------+
1 row in set (0.00 sec)
....
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+---------------------------------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------------------------------+
| wsrep_ist_receive_status | 97% complete, received seqno 1585923 of 1415410-1589676 |
+--------------------------+---------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show status like 'wsrep_ist_receive_status';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| wsrep_ist_receive_status | |
+--------------------------+-------+
1 row in set (0.00 sec)

Percona XtraDB Cluster 5.7 的效能改善

在「Percona XtraDB Cluster 5.7.17-29.20 is now available」這邊提到了：

This release is focused on performance and scalability with increasing workload threads. Tests show up to 10 times increase in performance.

不過這邊沒提到是 MySQL 本身還是 Galera Cluster 實做的修正，或是 PXC 本身特有的 bug 被修正... (通常都是有 bug 造成效能很慢，然後修正後拉上來)

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.