很多關(guān)注數(shù)據(jù)庫技術(shù)的IT人士可能記不住去年雙十二都剁手買了什么東西，但是一定會有人對當時一篇“Galera將死——MySQL Group Replication正式發(fā)布”的文章還有印象。

長期以來MySQL官方都缺少原生的MySQL集群多活方案，所以也給第三方公司提供了發(fā)展的機會。Galera就是其中的一個典型，兩種基于Galera的方案MariaDB Galera Cluster 和Percona XtraDB Cluster發(fā)展已有幾年的歷史，而且已經(jīng)有不少業(yè)界使用經(jīng)驗，比如去哪兒網(wǎng)就使用了較多的Percona XtraDB Cluster（PXC）

2016年12月12日ORACLE發(fā)布了MySQL Group Replication的首個GA版本，并且提供了自家對比Galera的性能測試，當然是各方面秒殺Galera。

原文鏈接:?

http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/?spm=5176.100239.blogcont66550.17.T4N8cZ

簡單來說OLTP場景下，MGR大概性能是Galera的兩倍。也就是這篇激動人心的原生的、性能更先進的MySQL集群產(chǎn)品的發(fā)布才有了去年雙十二期間“Galera將死——MySQL Group Replication正式發(fā)布”的火爆。

作為發(fā)展歷史更悠久的Galera當然也不會坐以待斃，時隔四個月之后，2017年4月份Percona發(fā)布了Percona XtraDB Cluster 5.7.17-29.20版本，性能得到極大提高，并且Percona公司也發(fā)布了自家對比MGR的性能對比測試。

原文地址：

https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/

原文較長，簡單來說在提高wsrep_slave_threads并發(fā)復(fù)制線程數(shù)等綜合優(yōu)化之后，PXC的性能像開掛一般提升，Percona自己對比5.7.17和上一個版本5.7.16之間的性能，OLTP綜合場景下大概提升有3倍多，可見的確稱得上大殺器：

測試

Test

以上兩家公司各自測試，都宣稱自己的產(chǎn)品性能優(yōu)于對方，那么作為客戶應(yīng)該相信哪一家呢？

我們使用同樣的硬件環(huán)境，獨立測試了兩家產(chǎn)品。

測試方案	版本	測試環(huán)境
MySQL異步復(fù)制	5.7.19	二路X86服務(wù)器，256G內(nèi)存，SSD硬盤，萬兆網(wǎng)
MySQL半同步復(fù)制	5.7.19
MySQL Group Replication	5.7.19
Percona XtraDB Cluster	5.7.18-29.20

測試過程使用標準的sysbench 0.5版本的OLTP場景，數(shù)據(jù)庫準備了100張400w的表，壓測并發(fā)線程120，MySQL的公共參數(shù)基本參考Percona的測試（他們家公布了所有案例和參數(shù)文件，可供用戶自行測試）壓測命令參考如下：

經(jīng)過多輪30分鐘的長時間壓測，取sysbench自動統(tǒng)計的壓測結(jié)果

對比結(jié)果：

（1） 相同測試環(huán)境下，MySQL Group Replication與Percona XtraDB Cluster性能基本差不多，相當于單機性能的60%。

方案	TPS	平均響應(yīng)時間	TPS同比單機	響應(yīng)時間同比單機
MySQL單主庫	10260	11.69
MySQL異步復(fù)制	10385	11.55	101.22%	98.80%
MySQL半同步復(fù)制	8741	13.73	85.19%	117.45%
MySQL MGR	6066	19.78	59.12%	169.20%
percona PXC	5884	20.39	57.35%	174.42%

（2）增加網(wǎng)絡(luò)0.6ms的延遲對半同步復(fù)制影響較大（TPS下降約一半，平均交易響應(yīng)時間翻倍），對MySQL Group Replication與PerconaXtraDB Cluster基本沒有影響（TPS和平均交易響應(yīng)時間均變化不大），意味著如果同城兩個數(shù)據(jù)中心網(wǎng)絡(luò)條件好，那么具備同城跨機房部署集群的條件。

（3）PXC的穩(wěn)定性要好于MGR，TPS比較穩(wěn)定，不像MGR毛刺比較嚴重：

（4）測試發(fā)現(xiàn)性能瓶頸點

對于PXC來說，測試發(fā)現(xiàn)wsrep_slave_threads對TPS影響較大（詳見下表），官方也建議可以適當調(diào)大此參數(shù)，但是要注意對CPU使用率的影響。綜合本場景最終選擇設(shè)置為20進行壓測。

壓測機器	wsrep_slave_threads	tps	平均響應(yīng)時間
機器1	48	5990	20
	32	6003	19.99
	16	4858	24.69
	8	2959	40
	1	616	194
機器2	48	5900	20
	20	5821	20
	16	5174	23

對于MGR來說，發(fā)現(xiàn)flow_control對TPS影響較大。默認值25000測試TPS只有1125，調(diào)大十倍到250000后TPS能達到近6000。

（4）功能性對比

本文主要目的是為了性能壓測，但是在壓測過程中也順便體驗了兩種產(chǎn)品的功能，受限于使用經(jīng)驗不夠豐富，簡單總結(jié)如下：

	MySQL MGR	percona PXC
安裝	插件式安裝，比較簡單	發(fā)布僅一年，無客戶使用
成熟度	發(fā)布僅一年，無客戶使用	發(fā)布五年多，經(jīng)歷MySQL5.5/5.6/5.7三個版本；有較多客戶使用，如國內(nèi)去哪兒網(wǎng)
性能	實際測試性能相差不大只有3%；大多數(shù)同步的方式，性能短板不明顯	實際測試性能相差不大只有3%；由于數(shù)據(jù)在所有節(jié)點強同步所以性能由最差節(jié)點決定
功能性對比	安裝簡單，但是使用較難，配套工具不夠成熟（如集群擴展多節(jié)點需要用戶自行備份恢復(fù)數(shù)據(jù)庫）對大事物支持欠缺（如單筆交易插入100萬條記錄），集群容錯性不夠好（復(fù)制沖突時集群會分裂）	集群添加節(jié)點自動擴展，集成自家Xtrabackup工具，無需用戶自行備份恢復(fù)數(shù)據(jù)，提供配套的監(jiān)控工具，支持大事物（一次性插入1000萬條記錄），自身具備沖突檢測解決方案
高可用特性	基于Paxos協(xié)議，數(shù)據(jù)在大多數(shù)節(jié)點同步；具備多主寫入功能，但是不推薦使用	GaleraReplication是一種certiticationbased replication保證集群所有節(jié)點強同步；也具備多主寫入功能，但是也需要注意減少沖突

結(jié)論

Conclusion

MySQL MGR作為官方力推的明星產(chǎn)品，的確具備了與市場老牌產(chǎn)品如PXC競爭的資格，但是現(xiàn)在就談Galera將死還言之過早，在功能完善性方面還比不上成熟的PXC。期待兩家產(chǎn)品繼續(xù)PK競爭，從而推出更加穩(wěn)定、高效的集群解決方案。

參考

Reference

公用的主要參數(shù)：

PXC的特殊參數(shù)：

測試過程中發(fā)現(xiàn)wsrep_slave_threads默認設(shè)置8嚴重限制TPS，所以調(diào)大到20

MGR的特殊參數(shù)：

測試過程中發(fā)現(xiàn)默認flow_control設(shè)置25000太小，嚴重限制了TPS，所以調(diào)大到250000

SET GLOBALgroup_replication_flow_control_certifier_threshold=250000;

SET GLOBALgroup_replication_flow_control_applier_threshold=250000;

總結(jié)

以上是生活随笔為你收集整理的MySQL MGR与Galera性能测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。