Galera Cluster for MySQL 詳解（四）——性能測試

  • 2019 年 11 月 3 日
  • 筆記

版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

本文鏈接：https://blog.csdn.net/wzy0623/article/details/102840342

本篇使用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://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即可。

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沒有明顯影響。

參考：

VirMach 便宜 VPS

QNews

QNews