何谓Galera Cluster?
就是集成了Galera插件的MySQL集群,是一种新型的,数据不共享的,高度冗余的高可用方案,目前Galera Cluster有两个版本,分别是Percona Xtradb Cluster及MariaDB Cluster,都是基于Galera的,所以这里都统称为Galera Cluster了。其中Percona 公司的最为成熟,简称“PXC”。
去哪和有缘婚恋网一直在基于PXC搞事情,从内参这本书中看出,去哪网极力推崇 PXC. 从小编的个人观点,如果是mysql的普通玩家,对PXC了解不深的时候,还是不要捉急直接上手搞它。
也需要调研一番。据小编所知:pxc是高可用,强一致性的数据库集群方案。就是一个事务在一个mysql集群中,要么全部执行成功,一个执行失败全部都要失败,从根本上解决了主从数据不一致的事务问题。金融级别不差钱的没有大型写事务,可以搞~。
风险点
如果发生了一个节点磁盘故障,整个集群就会被拖慢。对高并发大流量的写入表现的也比较挫。
秒杀业务,肯定是不适合这种架构的。节点越多性能越差。基于一种虚拟的全同步,一个事务在所有节点都得执行成功,这才会返回成功。节点越多,执行的效率就是倍增的。 官方说:超过100G的数据存储,也会发生安全隐患。
去哪网使用原因:据说是机票订单表,进行了分库,分表,拆分数量为100+。
要搞PXC架构,就得全面提升网络环境,硬件配置和系统环境的稳定性,毕竟强一致性。要求每个节点哥们都得高速稳定运转,不能拖后腿。
写入限制:单次事务写入不能超过131072行,size大小不能超过1个G.否则客户端会直接报错。
pxc、mgr相关对比
MGR简单介绍 :MySQL Group Replication(简称MGR)是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。
MySQL组复制提供了高可用、高扩展、高可靠的MySQL集群服务。
高一致性,基于原生复制及paxos协议的组复制技术,并以插件的方式提供,提供一致数据安全保证;
高容错性,只要不是大多数节点坏掉就可以继续工作,有自动检测机制,当不同节点产生资源争用冲突时,不会出现错误,按照先到者优先原则进行处理,并且内置了自动化脑裂防护机制;
高扩展性,节点的新增和移除都是自动的,新节点加入后,会自动从其他节点上同步状态,直到新节点和其他节点保持一致,如果某节点被移除了,其他节点自动更新组信息,自动维护新的组信息;
高灵活性,有单主模式和多主模式,单主模式下,会自动选主,所有更新操作都在主上进行;多主模式下,所有server都可以同时处理更新操作。
MGR是MySQL数据库未来发展的一个重要方向
很多关注数据库技术的IT人士可能记不住去年双十二都剁手买了什么东西,但是一定会有人对当时一篇“Galera将死——MySQL Group Replication正式发布”的文章还有印象。
长期以来MySQL官方都缺少原生的MySQL集群多活方案,所以也给第三方公司提供了发展的机会。Galera就是其中的一个典型,两种基于Galera的方案MariaDB Galera Cluster 和Percona XtraDB Cluster发展已有几年的历史,而且已经有不少业界使用经验,比如去哪儿网就使用了较多的Percona XtraDB Cluster(PXC)
2016年12月12日ORACLE发布了MySQL Group Replication的首个GA版本,并且提供了自家对比Galera的性能测试,当然是各方面秒杀Galera。
作为发展历史更悠久的Galera当然也不会坐以待毙,时隔四个月之后,2017年4月份Percona发布了Percona XtraDB Cluster 5.7.17-29.20版本,性能得到极大提高,并且Percona公司也发布了自家对比MGR的性能对比测试。
以上两家公司各自测试,都宣称自己的产品性能优于对方,那么作为客户应该相信哪一家呢?
我们使用同样的硬件环境,独立测试了两家产品。
测试方案 |
版本 |
测试环境 |
MySQL异步复制 |
5.7.19 |
二路X86服务器,256G内存,SSD硬盘,万兆网 |
MySQL半同步复制 |
5.7.19 |
|
MySQL Group Replication |
5.7.19 |
|
Percona XtraDB Cluster |
5.7.18-29.20 |
测试过程使用标准的sysbench 0.5版本的OLTP场景,数据库准备了100张400w的表,压测并发线程120,MySQL的公共参数基本参考Percona的测试(他们家公布了所有案例和参数文件,可供用户自行测试)压测命令参考如下
MySQL MGR |
percona PXC |
|
安装 |
插件式安装,比较简单 |
发布仅一年,无客户使用 |
成熟度 |
发布仅一年,无客户使用 |
发布五年多,经历MySQL5.5/5.6/5.7三个版本;有较多客户使用,如国内去哪儿网 |
性能 |
实际测试性能相差不大只有3%;大多数同步的方式,性能短板不明显 |
实际测试性能相差不大只有3%;由于数据在所有节点强同步所以性能由最差节点决定 |
功能性对比 |
安装简单,但是使用较难,配套工具不够成熟(如集群扩展多节点需要用户自行备份恢复数据库)对大事物支持欠缺(如单笔交易插入100万条记录),集群容错性不够好(复制冲突时集群会分裂) |
集群添加节点自动扩展,集成自家Xtrabackup工具,无需用户自行备份恢复数据,提供配套的监控工具,支持大事物(一次性插入1000万条记录),自身具备冲突检测解决方案 |
高可用特性 |
基于Paxos协议,数据在大多数节点同步;具备多主写入功能,但是不推荐使用 |
GaleraReplication是一种certiticationbased replication保证集群所有节点强同步;也具备多主写入功能,但是也需要注意减少冲突 |
(1) 相同测试环境下,MySQL Group Replication与Percona XtraDB Cluster性能基本差不多,相当于单机性能的60%。
方案 |
TPS |
平均响应时间 |
TPS同比单机 |
响应时间同比单机 |
MySQL单主库 |
10260 |
11.69 |
||
MySQL异步复制 |
10385 |
11.55 |
101.22% |
98.80% |
MySQL半同步复制 |
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)增加网络0.6ms的延迟对半同步复制影响较大(TPS下降约一半,平均交易响应时间翻倍),对MySQL Group Replication与PerconaXtraDB Cluster基本没有影响(TPS和平均交易响应时间均变化不大),意味着如果同城两个数据中心网络条件好,那么具备同城跨机房部署集群的条件。
(3)PXC的稳定性要好于MGR,TPS比较稳定,不像MGR毛刺比较严重:
(4)测试发现性能瓶颈点
对于PXC来说,测试发现wsrep_slave_threads对TPS影响较大(详见下表),官方也建议可以适当调大此参数,但是要注意对CPU使用率的影响。综合本场景最终选择设置为20进行压测。
压测机器 |
wsrep_slave_threads |
tps |
平均响应时间 |
机器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来说,发现flow_control对TPS影响较大。默认值25000测试TPS只有1125,调大十倍到250000后TPS能达到近6000。
首先我们把他们的缺点暴露出来(说明:MGC: MariaDB 10.2.1 Galera Cluster、MGR: MySQL group replication、PXC文章开头就介绍了,跳着看就不懂了吧~。)
增加节点对性能的影响:
影响PXC的特殊参数:测试过程中发现wsrep_slave_threads默认设置8严重限制TPS,所以调大到20。
影响MGR的参数:测试过程中发现默认flow_control设置25000太小,严重限制了TPS,所以调大到250000
MySQL MGR作为官方力推的明星产品,的确具备了与市场老牌产品如PXC竞争的资格,但是现在就谈Galera将死还言之过早,在功能完善性方面还比不上成熟的PXC。期待两家产品继续PK竞争,从而推出更加稳定、高效的集群解决方案。
小编个人总结,在未来还得是拥抱MySQL官方的MGR. .PXC毕竟是第三方厂家。虽然MGR暂时还未成熟,就看它的成长趋势,虽然PXC也不服输,但是从未来长远发展角度,我给MGR投了一票
因为篇幅原因就省略了pxc的具体细节,可以看下方博客链接。
https://blog.csdn.net/joy0921/article/details/80128328
http://galeracluster.com/downloads/
https://blog.csdn.net/chenhaifeng2016/article/details/77530569/