Home » Posts tagged "xtradb"

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

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.

Percona XtraDB Cluster 5.7 (Galera Cluster)

Percona 放出 PXC 5.7 了:「Percona XtraDB Cluster 5.7.14-26.17 GA is now available」。

主要的效能提昇還是基於 MySQL 5.7 上面,不過要注意的是有些預設值有改變 (尤其是 5.6 -> 5.7 最有名的 sync_binlog 設定),如果當初沒有特別指定的話,效能會掉不少,這點 Percona 整理了不少資料出來,可以翻一下 Percona 網站得到結果。

不過整體上改善了不少,在 5.6 需要一些手動設定的值以確保在 heavy loading 時不會拖垮系統效能 (也就是常說的「卡 query」),在 5.7 變得自動化了。像是 innodb_thread_concurrency 之前的建議都是設在 CPU logical threads 數量以確保當 threads 數量破千時還是有慢慢消化的能力 (讓 DBA 可以不用介入),在 5.7 不需要設定就跑得不錯了。

MySQL 5.7 中 InnoDB 的 innodb_page_size 在 SSD 硬碟上對效能的巨大影響

Percona 的「Small innodb_page_size as a performance boost for SSD」這篇文章裡提到了 MySQL 5.7 的 innodb_page_size 在 SSD 上對效能的差異,主要是這張圖的解釋:

先講一下標示的部份,有三個產品線 (都是 Samsung 的 SSD),中間的 sam850 是消費級的 SSD 硬碟 (所以不是本次重點),而 sam863 是企業級 SATA SSD,pm1725 則是企業級 PCI-e SSD。下方的 BP 指的是 Buffer Pool 大小,單位是 GB。左邊是速度,數字愈大愈好。

InnoDB 預設 16KB 的 page size,配合 SSD 大多都是 4KB 的 block size 後,效能的提昇非常巨大 (70% 的提昇),雖然既有的 InnoDB 要換過去會花不少功夫,但作者還是很建議評估:

I think a 70% performance gain is too significant to ignore, even if manipulating innodb_page_size requires extra work. I think it is worthwhile to evaluate if using different innodb_page_size settings help a fast SSD under your workload.

不過 comment 有不少額外重要的資訊。

有提到 Galera Cluster 目前有 bug,無法使用 4KB page size,可以在「Restarting a cluster with innodb_page_size=4096 segfaults」這邊看到 bug report。

另外有提到,使用 InnoDB Compression 的前提下,4KB 也許不是個好主意,用 8KB 也許是個方向:

You’re right – if you’re using Innodb Compression 4K base page is unlikely to be the good choice. Though we do not see Innodb compression (any of them) being used too frequently.

If using compression 8K base page size with 4K compressed page size might be good idea if 2x compression is routinely reached

不過我覺得應該還是有幫助才對 (可能提昇不高,但想了一下應該不會有負面的影響),之後有機會再測試看看吧 :o

Archives