Galera Cluster for MySQL Comments (four) - Performance Testing

table of Contents

First, the test target

Second, the test plan

Third, the testing process

1. default configuration

2. Multithreading

3. Flow Control

Fourth, the test results

reference:

---

        Benpian using tpcc-mysql pressure measurement tool Galera three-node cluster environment experimental series of performance tests.

First, the test target

• Verify synchronous replication Galera, checking whether there is replication latency.
• Comparing the number of transactions per second Galera group with MySQL replication (TPS).
• Verify multi-threaded replication Galera impact on performance.
• Effects on flow control to verify Galera performance.

Second, the test plan

        Here the same performance testing environment and methodology replication and MySQL group, but with different sets of copy Galera using MySQL version. Copy the test group is MySQL 8.0.16 version, which is used for testing Galera Galera Cluster for MySQL 5.7. The reason why different versions, because I used in the test is the latest version at the time.

Node 1: 172.16.1.125
Node 2: 172.16.1.126
Node 3: 172.16.1.127

        Specific ideas and Environment See https://wxy0327.blog.csdn.net/article/details/97782304#2.%20%E6%B5%8B%E8%AF%95%E8%A7%84%E5%88% 92 . Note Compatibility tpcc-mysql cluster with Galera, not all versions of tpcc-mysql installation package supports Galera. In my environment, the latest tpcc-mysql-master perform on the error when loading data (tpcc_load) on Galera Cluster for MySQL 5.7.

        Galera is a multi-master replication, the plurality of peer nodes in the cluster. To facilitate replication and a single set of recommendations MySQL master mode by comparing pressure measurements performed only on the nodes that we Galera 1 cluster. GTID Galera using their own definition, the current version does not provide a function similar master_pos_wait wait_for_executed_gtid_set or similar functions, and therefore need to modify the test script execution time measured pressure obtained in the nodes 2 and 3. Tpcc_test.sh modified file contents as follows:

[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]$

        When three nodes are equal last_committed, they perform the same number of transactions. If there is a delay replication, node 2 or node 3 performs the last_committed point after node 1 ratio.

Third, the testing process

        Each test can only perform tpcc_test.sh.

1. default configuration

        Obtaining the default configuration of the test results, as behind the different configurations of the comparison reference. Test results are as follows:

TRX: 76472 
Node1 TPS: 212
Elapsed1: 360 Node2 TPS: 212
Elapsed2: 360 Node3 TPS: 212

        It can be seen that, although only the virtual synchronization Galera replication, transaction verification on each node is asynchronous, there is no actual copying test delay, the execution time of pressure sensing node 1 and nodes 2, 3 and replicate the same TPS. This is very different with the replication group. Replicon single master mode, TPS library from the same high pressure measured twice than the primary database. On the other hand, TPS replication default configuration set twice as high as the main library Galera, that is to say the performance of the single master copy mode set in Galera roughly from the library. Because the two different versions of MySQL, where the test results for reference only.

2. Multithreading

        Article mentioned wsrep_cert_deps_distance the state variable indicates a difference of the number of parallel transactions submitted wsrep_slave_threads used as reference value.

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 value of 56, so the implementation of the following SQL commands three nodes, specify copy number of threads 60.

set global wsrep_slave_threads=60;

Perform the test again with the following results, TPS increase by 40%:

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

3. Flow Control

        Queries related flow control state variables:

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)

        Flow control trigger when the number of transactions in the receive queue exceeds gcs.fc_limit, the node will suspend replication, gcs.fc_limitde default value of 16 is obviously too small. Execute the following SQL commands three nodes, the flow control is limited to 1000 specified.

set global wsrep_provider_options = 'gcs.fc_limit = 1000';

A test is performed again, the value of the state variable flow control as shown below, does not trigger flow control.

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)

Test results are as follows:

TRX: 103760 
Node1 TPS: 288
Elapsed1: 361 Node2 TPS: 287
Elapsed2: 361 Node3 TPS: 287

        Visible, whether to trigger flow control for TPS and no significant effect.

Fourth, the test results

• Galera is synchronous replication between nodes without delay.
• Galera pattern group than the single master copy of the master library, TPS difference half.
• wsrep_slave_threads parameter greater impact on TPS.
• Whether to trigger traffic control had no significant effect on TPS.

reference:

• 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