love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

MySQL高可用方案之–PXC vs MGR

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: MySQL高可用方案之–PXC vs MGR

首先我们来安装部署好MGR,如下是MGR的简单配置步骤:

1. 初始化node1
2. 修改密码并创建复制用户
3. 其他节点分别执行:
4. 每个节点的参数配置如下:

这里需要注意的是每个节点的my.cnf配置文件修改server_id,local_address需要修改。

5. 创建测试数据验证MGR配置是否ok

可见整个MySQL Group Replication配置是完整ok的。

MySQL PXC集群的配置更为简单,这里不再贴出来了,有兴趣的可以自行测试一下,其中/etc/my.cnf在进行修改时保证每个节点的

server_id 、wsrep_node_address、wsrep_node_name 不同即可。
下面我们来看一下sysbench的对测试结果究竟如何:
a) MGR
b) PXC

 

我们不难看出当threads=50时,mgr依然可以维持在5300的QPS,而pxc基本上平均降到3500左右。
同时测试了threads=20的情况,pxc的性能稍微有所提升,大概在4000左右。但是仍然不敌MGR,因为MGR QPS 超过5000.  由于我这里是虚拟机,本地盘使用的是三星SSD,因此所测QPS相对还算理想。实际上测试20并发的时候,cpu 基本上已经耗尽了,因为我每个虚拟机只分配了一颗cpu。
如下是pxc sysbench threads=20的测试:
总的来说,MGR的性能完胜PXC!未来MGR是大势所趋!
备注:
1、我这里pxc和mgr均为5.7最新版本。
2、后续又分别调整了部分参数进行优化,分析性能均有一定上升,如下是参数:

PXC:

wsrep_slave_threads=16

MGR:

slave_parallel_type =LOGICAL_CLOCK
slave_parallel_workers =16
group_replication_compression_threshold =3000000
group_replication_flow_control_certifier_threshold=250000
group_replication_flow_control_applier_threshold=250000

Leave a Reply

You must be logged in to post a comment.