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

    这里采用与MySQL组复制性能测试相同的环境和方法，但组复制与Galera使用的MySQL版本不同。组复制测试用的是MySQL 8.0.16版本，而Galera测试用的是Galera Cluster for MySQL 5.7。之所以版本不同，是因为我在测试时使用的都是当时的最新版本。

    具体思路与环境参见[https://cloud.tencent.com/developer/article/1486498](https://cloud.tencent.com/developer/article/1486498)。需要注意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即可。

    获得缺省配置的测试结果，作为后面不同配置的对比基准。测试结果如下：

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版本不同，这里的测试结果只作参考。

    上篇文章提到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;

TRX: 106848 
Node1 TPS: 296
Elapsed1: 360 Node2 TPS: 296
Elapsed2: 360 Node3 TPS: 296

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

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