目录
本篇使用tpcc-mysql压测工具对实验环境的三节点Galera集群进行一系列性能测试。
一、测试目标
- 验证Galera的同步复制，检查是否存在复制延迟。
- 对比Galera与MySQL组复制的每秒事务数（TPS）。
- 验证多线程复制对Galera性能的影响。
- 验证流控对Galera性能的影响。
二、测试规划
这里采用与MySQL组复制性能测试相同的环境和方法，但组复制与Galera使用的MySQL版本不同。组复制测试用的是MySQL 8.0.16版本，而Galera测试用的是Galera Cluster for MySQL 5.7。之所以版本不同，是因为我在测试时使用的都是当时的最新版本。
节点1：172.16.1.125
节点2：172.16.1.126
节点3：172.16.1.127
具体思路与环境参见https://wxy0327.blog.csdn.net/article/details/97782304#2.%20%E6%B5%8B%E8%AF%95%E8%A7%84%E5%88%92。需要注意tpcc-mysql与Galera集群的兼容性，并不是所有版本的tpcc-mysql安装包都支持Galera。在我的环境中，最新的tpcc-mysql-master在Galera Cluster for MySQL 5.7上执行数据装载（tpcc_load）时就报错。
Galera是多主复制，集群中的多个节点对等。为了便于与MySQL组复制推荐的单主模式进行比较，我们只在Galera集群的节点1上执行压测。Galera使用自己定义的GTID，当前版本也没有提供类似master_pos_wait或wait_for_executed_gtid_set类似功能的函数，因此需要修改测试脚本获得压测在节点2和节点3上的执行时间。修改后的tpcc_test.sh文件内容如下：
[mysql@hdp1~/tpcc-mysql]$more tpcc_test.sh
# 初始化tpcc数据
mysql -uwxy -pP@sswo2d -h172.16.1.125 -Dtpcc_test < tpcc_test.sql
# 获取节点1的last_committed用于比较
read last_committed < <(mysql -uwxy -pP@sswo2d -h172.16.1.125 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{prin
t $2}' | sed "s/\\\n//g")
# 等待其它两个节点执行完初始化复制
read last_committed_1 < <(mysql -uwxy -pP@sswo2d -h172.16.1.126 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{pr
int $2}' | sed "s/\\\n//g")
read last_committed_2 < <(mysql -uwxy -pP@sswo2d -h172.16.1.127 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{pr
int $2}' | sed "s/\\\n//g")
while [ $last_committed_1 -lt $last_committed -o $last_committed_2 -lt $last_committed ]
do
read last_committed_1 < <(mysql -uwxy -pP@sswo2d -h172.16.1.126 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk
'{print $2}' | sed "s/\\\n//g")
read last_committed_2 < <(mysql -uwxy -pP@sswo2d -h172.16.1.127 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk
'{print $2}' | sed "s/\\\n//g")
done
# 开始时间
start_time=`date '+%s'`
# 开始事务序号
read start_last_committed < <(mysql -uwxy -pP@sswo2d -h172.16.1.125 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk
'{print $2}' | sed "s/\\\n//g")
# 节点1执行压测，10个仓库，32个并发线程，预热1分钟，压测5分钟
tpcc_start -h172.16.1.125 -d tpcc_test -u wxy -p "P@sswo2d" -w 10 -c 32 -r 60 -l 300 > tpcc_test.log 2>&1
# 获取节点1的last_committed用于比较
read last_committed < <(mysql -uwxy -pP@sswo2d -h172.16.1.125 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{prin
t $2}' | sed "s/\\\n//g")
# 等待其它两个节点执行完复制
read last_committed_1 < <(mysql -uwxy -pP@sswo2d -h172.16.1.126 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{pr
int $2}' | sed "s/\\\n//g")
read last_committed_2 < <(mysql -uwxy -pP@sswo2d -h172.16.1.127 -e "show status like 'wsrep_last_committed';" --skip-column-names | awk '{pr
int $2}' | sed "s/\\\n//g")
while [ $last_committed_1 -lt $last_committed -o $last_committed_2 -lt $last_committed ]
do
if [ $last_committed_1 -lt $last_committed ]
then
read last_committed_1 < <(mysql -uwxy -pP@sswo2d -h172.16.1.126 -e "show status like 'wsrep_last_committed';" --skip-column-names |
awk '{print $2}' | sed "s/\\\n//g")
else
end_time1=`date '+%s'`
fi
if [ $last_committed_2 -lt $last_committed ]
then
read last_committed_2 < <(mysql -uwxy -pP@sswo2d -h172.16.1.127 -e "show status like 'wsrep_last_committed';" --skip-column-names |
awk '{print $2}' | sed "s/\\\n//g")
else
end_time2=`date '+%s'`
fi
done
if [ ! $end_time1 ]; then
end_time1=`date '+%s'`
fi
if [ ! $end_time2 ]; then
end_time2=`date '+%s'`
fi
# 复制执行时长
elapsed1=$(($end_time1 - $start_time))
elapsed2=$(($end_time2 - $start_time))
# 执行的事务数
trx=$(($last_committed - $start_last_committed))
# 计算三个节点的TPS
Master_TPS=`expr $trx / 360`
Slave1_TPS=`expr $trx / $elapsed1`
Slave2_TPS=`expr $trx / $elapsed2`
# 打印输出
echo "TRX: $trx"
echo "Node1 TPS: $Master_TPS"
echo "Elapsed1: $elapsed1" "Node2 TPS: $Slave1_TPS"
echo "Elapsed2: $elapsed2" "Node3 TPS: $Slave2_TPS"
[mysql@hdp1~/tpcc-mysql]$当三个节点的last_committed相等时，它们执行了相同的事务数。如果存在复制延迟，节点2或节点3会比节点1后执行到last_committed点。
三、测试过程
每次测试只需要执行tpcc_test.sh即可。
1. 缺省配置
获得缺省配置的测试结果，作为后面不同配置的对比基准。测试结果如下：
TRX: 76472
Node1 TPS: 212
Elapsed1: 360 Node2 TPS: 212
Elapsed2: 360 Node3 TPS: 212可以看到，虽然Galera只是虚拟同步复制，每个节点上的事务验证是异步的，但实际测试中没有复制延迟，压测节点1与复制节点2、3的执行时间和TPS相同。这点与组复制大相径庭。单主模式的组复制中，相同压测主库比从库的TPS高一倍。另一方面，缺省配置组复制中主库的TPS比Galera高一倍，也就是说Galera的性能与单主模式组复制中的从库大致相当。因为两者MySQL版本不同，这里的测试结果只作参考。
2. 多线程
上篇文章提到wsrep_cert_deps_distance状态变量指示并行提交的事务序号之差，可用作wsrep_slave_threads的参考值。
mysql> show status like 'wsrep_cert_deps_distance';
+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| wsrep_cert_deps_distance | 56.673657 |
+--------------------------+-----------+
1 row in set (0.00 sec)wsrep_cert_deps_distance的值为56，因此在三个节点执行下面的SQL命令，指定复制线程数为60。
set global wsrep_slave_threads=60;再次执行测试，结果如下，TPS提高了40%：
TRX: 106848
Node1 TPS: 296
Elapsed1: 360 Node2 TPS: 296
Elapsed2: 360 Node3 TPS: 2963. 流控
查询流控相关的状态变量：
mysql> show status like 'wsrep_flow_control_%';
+------------------------------+--------------+
| Variable_name | Value |
+------------------------------+--------------+
| wsrep_flow_control_paused_ns | 947249076448 |
| wsrep_flow_control_paused | 0.037075 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 932 |
+------------------------------+--------------+
4 rows in set (0.00 sec)接收队列中的事务数超过gcs.fc_limit时触发流控，节点将暂停复制，gcs.fc_limitde的缺省值16显然太小。在三个节点执行下面的SQL命令，指定流控限制为1000。
set global wsrep_provider_options = 'gcs.fc_limit = 1000';再次执行测试，流控状态变量的值如下，确认没有触发流控。
mysql> show status like 'wsrep_flow_control_%';
+------------------------------+--------------+
| Variable_name | Value |
+------------------------------+--------------+
| wsrep_flow_control_paused_ns | 947249076448 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
+------------------------------+--------------+
4 rows in set (0.00 sec)测试结果如下：
TRX: 103760
Node1 TPS: 288
Elapsed1: 361 Node2 TPS: 287
Elapsed2: 361 Node3 TPS: 287可见，是否触发流控对于TPS并没有明显影响。
四、测试结论
- Galera是同步复制，节点间无延迟。
- Galera比单主模式组复制中的主库，TPS相差一半。
- wsrep_slave_threads参数对TPS影响较大。
- 是否触发流控对TPS没有明显影响。
参考：
