Percona XtraDB Cluster 测试

1         测试环境

HostName	OS	MySQL Version	IP:Port	CPU	MEM	bandwith
mysql-1	CentOS7.3	5.7.18-15-57 Percona XtraDB Cluster (GPL)	10.45.81.189:3306/4444/4567/4568	2	8G	10000Mb/s
mysql-2	CentOS7.3	5.7.18-15-57 Percona XtraDB Cluster (GPL)	10.45.81.190:3306/4444/4567/4568	2	8G	10000Mb/s
mysql3	CentOS7.3	5.7.18-15-57 Percona XtraDB Cluster (GPL)	10.45.81.191:3306/4444/4567/4568	2	8G	10000Mb/s

 

测试环境主机为虚拟机

2         安装部署

采用RPM包安装模式

配置my.cnf(PXC必要参数，省略了其他常用配置其他和MGR非插件参数配置一样)

symbolic-links=0 wsrep_provider=/usr/lib64/galera3/libgalera_smm.so   # Cluster connection URL contains IPs of nodes #If no IP is found, this implies that a new cluster needs to be created, #in order to do that you need to bootstrap this node wsrep_cluster_address=gcomm://10.45.81.189,10.45.81.190,10.45.81.191   # In order for Galera to work correctly binlog format should be ROW binlog_format=ROW   # MyISAM storage engine has only experimental support default_storage_engine=InnoDB   # Slave thread to use wsrep_slave_threads= 8   wsrep_log_conflicts   # This changes how InnoDB autoincrement locks are managed and is a requirement for Galera innodb_autoinc_lock_mode=2   # Node IP address wsrep_node_address=10.45.81.189 # Cluster name wsrep_cluster_name=pxc-cluster   #If wsrep_node_name is not specified,  then system hostname will be used wsrep_node_name=pxc-cluster-node-1   #pxc_strict_mode allowed values: DISABLED,PERMISSIVE,ENFORCING,MASTER pxc_strict_mode=ENFORCING   # SST method wsrep_sst_method=xtrabackup-v2   #Authentication for SST method wsrep_sst_auth="sstuser:sstuser"

初始化

#systemctl start [email protected]

--配置用户权限--

root@mysql-1[/root]# mysql -uroot -p mysql> alter user root@'localhost' identified by 'root'; Query OK, 0 rows affected (0.00 sec)   mysql> flush privileges; Query OK, 0 rows affected (0.01 sec) --验证状态 mysql> show status like 'wsrep%';   --创建sstuser mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'sstuser'; Query OK, 0 rows affected (0.00 sec)   mysql> GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'; Query OK, 0 rows affected, 1 warning (0.00 sec)   mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec)

---其他节点启动

#systemctl start mysql

--确认启动成功--

mysql> show status like 'wsrep%'; +----------------------------------+-------------------------------------------------------+ | Variable_name                    | Value                                                 | +----------------------------------+-------------------------------------------------------+ | wsrep_local_state_uuid           | 491256df-7666-11e7-b95d-eee2b5a469af                  | | wsrep_protocol_version           | 7                                                     | | wsrep_last_committed             | 12620603                                              | | wsrep_replicated                 | 1                                                     | | wsrep_replicated_bytes           | 291                                                   | | wsrep_repl_keys                  | 3                                                     | | wsrep_repl_keys_bytes            | 47                                                    | | wsrep_repl_data_bytes            | 180                                                   | | wsrep_repl_other_bytes           | 0                                                     | | wsrep_received                   | 6                                                     | | wsrep_received_bytes             | 623                                                   | | wsrep_local_commits              | 1                                                     | | wsrep_local_cert_failures        | 0                                                     | | wsrep_local_replays              | 0                                                     | | wsrep_local_send_queue           | 0                                                     | | wsrep_local_send_queue_max       | 1                                                     | | wsrep_local_send_queue_min       | 0                                                     | | wsrep_local_send_queue_avg       | 0.000000                                              | | wsrep_local_recv_queue           | 0                                                     | | wsrep_local_recv_queue_max       | 2                                                     | | wsrep_local_recv_queue_min       | 0                                                     | | wsrep_local_recv_queue_avg       | 0.166667                                              | | wsrep_local_cached_downto        | 12620603                                              | | wsrep_flow_control_paused_ns     | 0                                                     | | wsrep_flow_control_paused        | 0.000000                                              | | wsrep_flow_control_sent          | 0                                                     | | wsrep_flow_control_recv          | 0                                                     | | wsrep_flow_control_interval      | [ 253, 256 ]                                          | | wsrep_flow_control_interval_low  | 253                                                   | | wsrep_flow_control_interval_high | 256                                                   | | wsrep_flow_control_status        | OFF                                                   | | wsrep_cert_deps_distance         | 1.000000                                              | | wsrep_apply_oooe                 | 0.000000                                              | | wsrep_apply_oool                 | 0.000000                                              | | wsrep_apply_window               | 1.000000                                              | | wsrep_commit_oooe                | 0.000000                                              | | wsrep_commit_oool                | 0.000000                                              | | wsrep_commit_window              | 1.000000                                              | | wsrep_local_state                | 4                                                     | | wsrep_local_state_comment        | Synced                                                | | wsrep_cert_index_size            | 3                                                     | | wsrep_cert_bucket_count          | 22                                                    | | wsrep_gcache_pool_size           | 1861                                                  | | wsrep_causal_reads               | 0                                                     | | wsrep_cert_interval              | 0.000000                                              | | wsrep_ist_receive_status         |                                                       | | wsrep_ist_receive_seqno_start    | 0                                                     | | wsrep_ist_receive_seqno_current  | 0                                                     | | wsrep_ist_receive_seqno_end      | 0                                                     | | wsrep_incoming_addresses         | 10.45.81.189:3306,10.45.81.191:3306,10.45.81.190:3306 | | wsrep_desync_count               | 0                                                     | | wsrep_evs_delayed                |                                                       | | wsrep_evs_evict_list             |                                                       | | wsrep_evs_repl_latency           | 0/0/0/0/0                                             | | wsrep_evs_state                  | OPERATIONAL                                           | | wsrep_gcomm_uuid                 | 19026348-79a9-11e7-aa8b-57577397b275                  | | wsrep_cluster_conf_id            | 2                                                     | | wsrep_cluster_size               | 3                                                     | | wsrep_cluster_state_uuid         | 491256df-7666-11e7-b95d-eee2b5a469af                  | | wsrep_cluster_status             | Primary                                               | | wsrep_connected                  | ON                                                    | | wsrep_local_bf_aborts            | 0                                                     | | wsrep_local_index                | 1                                                     | | wsrep_provider_name              | Galera                                                | | wsrep_provider_vendor            | Codership Oy                      | | wsrep_provider_version           | 3.20(r7e383f7)                                        | | wsrep_ready                      | ON                                                    | +----------------------------------+-------------------------------------------------------+

按照上述步骤增加其他2个节点.

3         测试用例（结果）

Multi-Primary	1.one node crash (no binlog)	PASS
	2.two nodes crash single write client，nobinlog)	PASS
	3. two nodes crashed involuntarily	PASS
	4. one node recovery (data delay no binlog)	PASS
	5. two nodes crash(two write clients ,no binlog)	PASS
	6.recovery after all PXC nodes crash	PASS
	7.One Node Network timeout to the others	PASS
Multi-Primary (Arbitrator node mode)	1.one node crash (no binlog)	PASS
	2.two nodes(arbitrator+one node) crash single write client，nobinlog)	PASS
	3. two nodes(arbitrator+one node) crashed involuntarily	PASS
	4. one node recovery (data delay no binlog)	PASS
	6.recovery after all PXC nodes crash	PASS
	7.One Node Network timeout to the others	PASS

 

4         测试过程

4.1       Multi-Primary

4.1.1        one node crash(no binlog)

测试用例名称	1.任意一个节点crash
测试目的	确认其他2个节点读写不会受到影响
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master   测试过程： 在系统正常情况下无延迟情况下 reboot mysql-1节点
通过准则	其他节点不受影响,其他节点上的读写都正常运行
测试结果	通过
备注	在其中一个节点down的瞬间tps会受到些影响但是立马恢复正常

 

4.1.2        two nodes crash(single write client，nobinlog)

测试用例名称	2.任意2个节点 crash(没有延迟)
测试目的	确认2个主机crash场景下剩余一个节点状态是否正常
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master   测试过程： mysql-3尝试写入数据 reboot mysql-1,myqsl-2
通过准则	Mysql-3可以写入
测试结果	通过
备注

 

4.1.3        two nodes crash involuntarily

测试用例名称	3.任意2个节点 crash 异常断电
测试目的	确认2个主机crash场景下剩余一个节点状态是否正常
测试方法	mysql-1 Master mysql-2 Master mysql-3 Master 测试过程： sysbench-3 压mysql-3 db=test3 table=sbtest 存在延迟后 依次重启mysql-1,mysql-2电源2个节点 确认剩余节点是否可写 确认恢复后从新加入PXC
通过准则	剩余一个节点不可写，节点恢复后可恢复一致性
测试结果	通过
备注

 

4.1.4        one node recovery (data delayno binlog)  

测试用例名称	4. 一个节点crash后，集群任在运行存在data delay情况下节点从下加入节点情况
测试目的	确认data delay节点从新加入集群对集群产生的影响
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master 测试过程： sysbench 压mysql-3 db=test3 table=sbtest reboot mysql-1主机 等待mysql-1从新启动好启动mysql字段加入集群 观察新加入节点是否正常 观察集群是否收到影响
通过准则	从新加入节点后，数据一致性不受影响。剩余主机读写不受影响主机性能
测试结果	通过
备注	PXC通过2种方式来追数据一种是SST另一种是IST通常要避免SST，IST通过gcache去追取增量落后数据或，在尝试加入group当与group同步之后，才会对外打开connection也就是说在追数据过程中恢复节点是不可访问的。 Beginning of list of non-natively partitioned tables 2017-08-05T03:40:41.383024Z 1 [Note] WSREP: Receiving IST: 221759 writesets, seqnos 10448928-10670687 2017-08-05T03:40:41.686234Z 0 [Note] End of list of non-natively partitioned tables 2017-08-05T03:40:43.523138Z 0 [Note] InnoDB: Buffer pool(s) load completed at 170805 11:40:43 2017-08-05T03:41:27.148273Z 1 [Note] WSREP: IST received: 491256df-7666-11e7-b95d-eee2b5a469af:10670687 2017-08-05T03:41:27.149749Z 0 [Note] WSREP: 1.0 (pxc-cluster-node-1): State transfer from 2.0 (pxc-cluster-node-1) complete. 2017-08-05T03:41:27.149780Z 0 [Note] WSREP: Shifting JOINER -> JOINED (TO: 10795462) 2017-08-05T03:42:19.132287Z 0 [Note] WSREP: Member 1.0 (pxc-cluster-node-1) synced with group. 2017-08-05T03:42:19.132327Z 0 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 10933902) 2017-08-05T03:42:19.156684Z 5 [Note] WSREP: Synchronized with group, ready for connections 2017-08-05T03:42:19.156716Z 5 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.

 

4.1.5        two nodes crash(two writeclients ,no binlog)

测试用例名称	4．复制延迟情况下2个节点crash
测试目的	确认复制延迟时候2节点crash，复制组状态
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master   默认值 测试过程： sysbench-1 压mysql-1 db=test1 table=sbtest sysbench-2 压mysql-2 db=test2 table=sbtest sysbench-3 压mysql-3 db=test3 table=sbtest 上面三个同时进行压力测试 登录各个库比较插入表和复制表是否存在延迟 存在延迟后reboot其中任意2个主机 恢复后从新加入Cluster
通过准则	2个节点reboot后，剩下节点任然可写；2个节点从新启动后任然可以加入到原集群状态中数据恢复一致性
测试结果	通过
备注	3master和单master性能在此种情况下是一致的。当由于异常断电involuntarily导致的2节点crash，数据一致性会得到保证，如果是人为reboot，则数据一致性会可能受的破坏。

 

4.1.6        recovery after all PXC nodescrash(no binlog)

测试用例名称	5. 存在延迟的情况下3个节点都crash
测试目的	确认事务一致性是否可以正常恢复
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master   测试过程： sysbench-1 压mysql-1 db=test1 table=sbtest sysbench-2 压mysql-2 db=test2 table=sbtest sysbench-3 压mysql-3 db=test3 table=sbtest 上面三个同时进行压力测试 登录各个库比较插入表和复制表是否存在延迟 存在延迟后段时间依次reboot 其中3个主机/直接同时重启三个机器 恢复后从新启动PXC
通过准则	数据一致，可以正常启动
测试结果	通过，能正常启动各个节点查表三个数据库的表数据一致。
备注	测试过程中三个的bootstrap都是0，通常如果存在先后顺序应该会有存在1的 通过启动加如参数--wsrep-recover在启动日志里面找出WSREP: Recovered position: 491256df-7666-11e7-b95d-eee2b5a469af:12396151 找出最大一个序号(实际最后的序号和grastate.dat中的uuid:seqno相等)作为bootstrap，修改grastate.dat中safe_to_bootstrap：1 systemctl start [email protected]启动（后修改my.cnf address 内容）

 

 

4.1.7        One Node Network timeout to theothers(no binlog)

测试用例名称	6.任意一个节点到其他2个节点网络超时
测试目的	确认网络超时（分区）场景下
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master 确认状态每个节点查看show status like 'wsrep%'; wsrep_local_state_comment        | Synced wsrep_evs_delayed                |              wsrep_cluster_status             | Primary 测试过程： 使用sysbench压测mysql-3 在mysql-1和mysql-2上执行iptables -I INPUT -s 10.45.81.191 -j DROP 确认sysbench是否能继续读写 确认状态是否发生改变 去除网络分区 确认数据是否一致
通过准则	当发生网络分区情况，集群不会对外提供写操作 ，数据强一致性得到保证。
测试结果	通过
备注	发生网络分区时客户端直接报了错 FATAL: mysql_drv_query() returned error 1047 (WSREP has not yet prepared node for application use) for query 'INSERT INTO sbtest1 (id, k, c, pad) VALUES (0, 49107, '13343192824-40279963429-89601133041-56483876037-24781339587-65925069081-65410763167-70567913300-97314673243-00789516572', '17413050671-41534367057-47812413603-25105653355-36436905174')' FATAL: `thread_run' function failed: ../share/sysbench/oltp_insert.lua:47: SQL error, errno = 1047, state = '08S01': WSREP has not yet prepared node for application use

 

4.2       Arbitrator

4.2.1        one node crash(no binlog)

测试用例名称	1.任意一个节点crash
测试目的	确认其他2个节点读写不会受到影响
测试方法	预置条件： mysql-1 Arbitrator mysql-2 Master mysql-3 Master   测试过程： 在系统正常情况下无延迟情况下 Write mysql-3 Reboot mysql-1或者mysql-2
通过准则	Write mysql-3不受影响
测试结果	通过
备注

 

4.2.2        two nodes(arbitrator+one node)crash single write client，nobinlog)

测试用例名称	2.任意2个节点 crash(没有延迟)
测试目的	确认2个主机crash场景下剩余一个节点状态是否正常
测试方法	预置条件： mysql-1 Arbiter mysql-2 Master mysql-3 Master   测试过程： mysql-3尝试写入数据 2． reboot mysql-1,myqsl-2
通过准则	Mysql-3可以写入
测试结果	通过
备注

 

4.2.3        two nodes(arbitrator+one node)crashed involuntarily

测试用例名称	3.任意2个节点 crash 异常断电
测试目的	确认2个主机crash场景下剩余一个节点状态是否正常
测试方法	mysql-1 Arbitrator mysql-2 Master mysql-3 Master 测试过程： sysbench-3 压mysql-3 db=test3 table=sbtest 存在延迟后 依次重启mysql-1,mysql-2电源2个节点 确认剩余节点是否可写 确认恢复后从新加入PXC
通过准则	剩余一个节点不可写，节点恢复后可恢复一致性
测试结果	通过
备注

 

4.2.4        one node recovery (data delayno binlog)  

测试用例名称	4. 一个节点crash后，集群任在运行存在data delay情况下节点从下加入节点情况
测试目的	确认data delay节点从新加入集群对集群产生的影响
测试方法	预置条件： mysql-1 Arbitrator mysql-2 Master mysql-3 Master 测试过程： sysbench 压mysql-3 db=test3 table=sbtest reboot mysql-2主机 等待mysql-2从新启动好启动mysql字段加入集群 观察新加入节点是否正常 观察集群是否收到影响
通过准则	从新加入节点后，数据一致性不受影响。剩余主机读写不受影响主机性能
测试结果	通过
备注	.

 

4.2.5        two nodes crash(two writeclients ,no binlog)

测试用例名称	5．复制延迟情况下2个节点crash
测试目的	确认复制延迟时候2节点crash，复制组状态
测试方法	预置条件： mysql-1 Master mysql-2 Master mysql-3 Master   默认值 测试过程： sysbench-1 压mysql-1 db=test1 table=sbtest sysbench-2 压mysql-2 db=test2 table=sbtest sysbench-3 压mysql-3 db=test3 table=sbtest 上面三个同时进行压力测试 登录各个库比较插入表和复制表是否存在延迟 存在延迟后reboot其中任意2个主机 恢复后从新加入Cluster
通过准则	2个节点reboot后，剩下节点任然可写；2个节点从新启动后任然可以加入到原PXC中恢复数据一致性
测试结果	通过
备注	3master和单master性能在此种情况下是一致的。当由于异常断电involuntarily导致的2节点crash，数据一致性会得到保证，如果是人为reboot，则数据一致性会可能受的破坏。

 

4.2.6        recovery after all PXC nodescrash(no binlog)

测试用例名称	6. 存在延迟的情况下3个节点都crash
测试目的	确认事务一致性是否可以正常恢复
测试方法	预置条件： mysql-1 Arbiter mysql-2 Master mysql-3 Master   测试过程： sysbench-2 压mysql-2 db=test2 table=sbtest sysbench-3 压mysql-3 db=test3 table=sbtest 上面2个同时进行压力测试 登录各个库比较插入表和复制表是否存在延迟 存在延迟后段时间依次reboot 其中3个主机/直接同时重启三个机器 恢复后从新启动PXC
通过准则	数据一致，可以正常启动
测试结果	通过，能正常启动各个节点查表2个数据库的表数据一致。
备注

 

 

4.2.7        One Node Network timeout to theothers(no binlog)

测试用例名称	7.任意一个节点到其他2个节点网络超时
测试目的	确认网络超时（分区）场景下
测试方法	预置条件： mysql-1 Arbiter mysql-2 Master mysql-3 Master 确认非arbiter状态每个节点查看show status like 'wsrep%'; wsrep_local_state_comment        | Synced wsrep_evs_delayed                |              wsrep_cluster_status             | Primary 测试过程： 使用sysbench压测mysql-3 在mysql-1和mysql-2上执行iptables -I INPUT -s 10.45.81.191 -j DROP 确认sysbench是否能继续读写 确认状态是否发生改变 去除网络分区 确认数据是否一致
通过准则	当发生网络分区情况，集群不会对外提供写操作 ，数据强一致性得到保证。
测试结果	通过
备注

 

 

5         测试总结

测试过程中发现节点间数据延迟几乎没有，等同于同步复制，相比MGR来说，MGR默认配置下延迟还是比较大

PXC不依赖于binlog，这点改善很大，在使用binlog时性能相当于MGR默认配置时的70%（主要是cert队列和apply队列25000），但是对比两边未发现明显延迟（和MGR相同测试环境）。不使用binlog，一个节点写能达到MGR的2倍性能（100% insert）

3节点写（不同DB）能增加吞吐量到MGR的3倍（MGR当时1200tps，且磁盘IOwait20%）

且io wait<3%(不依赖于binlog是因为PXC 的gcache和IST机制)。使用binlog适用于需要PIT闪回或者异地容灾这种场景

3.      虽然是基于多主的方式，但是为了数据一致性还是建议使用单节点写入（物理是否开启binlog），避免复杂问题，当然如果完全利用PXC多主特性，还是建议四垂直分库做好一个节点只访问一个库减少conflicts

         4.      支持了网络分区的场景处理

5.  人为预计的reboot等操作和MGR表现一样并不会剩余节点readonly，意外断电网络分区会触发剩余节点readonly保证数据一致性

         6.      相对于MGR,MHA等，当属强一致性。

         7.  PXC最少可以使用2个数据节点加仲裁节点，功能上暂未发现明显区别

         8．相对目前的MGR来说，PXC的优势还是很明显的

9.  Percona 也是卖服务的https://www.percona.com/store/mysql-standard-support

参考网站: http://galeracluster.com

         https://www.percona.com/doc/percona-xtradb-cluster/5.7/index.html

 

6         PXC官方限制说明:

1．只支持innodb

2．多主情况下不支持lock table,unlock table,锁函数get_lock(),release_lock()

3．查询日志general_log,general_log_file只能指向文件格式不能指定表中

4．事务大小阀值由参数控制，文件导入数据库load会按照这个值进行切分成多个事务

5．集群级别的并发控制会导致在commit在多个节点时可能会被abort掉(同时更新同一row)，PXC会返回个Error1213

6．不支持XA事务

7．集群性能由最差的节点控制，保证集群间硬件一致性

8．推荐最小三个节点，但是第三个节点可以是arbitrator

9．InnoDB fake changes feature不支持

10．           enforce_storage_engine=InnoDB is not compatible with wsrep_replicate_myisam=OFF (default)

11．           binlog_rows_query_log_events不支持

12．           PXC模式下避免使用 ALTER TABLE ... IMPORT/EXPORT workloads可能会导致数据不一致