Galera Cluster for MySQL 详解（四）——性能测试

目录

一、测试目标

二、测试规划

三、测试过程

1. 缺省配置

2. 多线程

3. 流控

四、测试结论

参考：

---

        本篇使用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: 296

3. 流控

        查询流控相关的状态变量：

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没有明显影响。

参考：

• https://blog.csdn.net/chenhaifeng2016/article/details/77530569
• https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/
• http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/?spm=5176.100239.blogcont66550.17.T4N8cZ