まず、テスト対象

レプリケーションの遅延があるかどうかをチェックし、同期レプリケーションガレラを確認してください。
MySQLのレプリケーション（TPS）を有する第二ガレラグループあたりのトランザクション数を比較します。
パフォーマンス上のマルチスレッド複製ガレラへの影響を確認してください。
ガレラの性能を検証するために、フロー制御の影響。

第二に、テスト計画

ここでは、環境と方法論の複製およびMySQLのグループをテストしますが、MySQLのバージョンを使用してコピーガレラの異なるセットと同じ性能。テストグループは、MySQL 5.7のためガレラガレラクラスタをテストするために使用されているMySQLの8.0.16バージョンですコピーします。私はテストで使用されるので、異なるバージョンは、時点での最新バージョンである理由。

ノード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のクラスタ、TPCC-mysqlのインストールパッケージのないすべてのバージョンはガレラをサポートしています。私の環境では、最新TPCC-mysqlのマスターは、エラー時に実行するときのMySQL 5.7用ガレラクラスタ上のデータをロードする（tpcc_load）。

ガレラは、マルチマスターレプリケーション、クラスタ内のピア・ノードの複数です。我々ガレラ1つのクラスタこと圧力測定値を比較することによって、複製および推奨MySQLのマスタモードの単一のセットを容易にするためのノードでのみ実行。独自の定義を使用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]$

3つのノードがlast_committed等しい場合、それらはトランザクションの同じ番号を行います。ノード1の比率後の遅延レプリケーション、ノード2またはノード3行うlast_committed点がある場合。

第三に、テストプロセス

各テストはtpcc_test.shのみを行うことができます。

1.デフォルトの設定

比較基準の異なる構成の背後にあるように、テスト結果のデフォルト設定を取得します。次のようにテスト結果は以下のとおりです。

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

仮想同期ガレラ複製は、各ノード上のトランザクションの確認が非同期であるが、そこには実際の複写テスト遅延、圧力感知ノード1とノード2、3の実行時間がなく、同一のTPSを複製することが分かります。これは、レプリケーショングループと非常に異なっています。シングルマスタモードレプリコン、プライマリ・データベースよりも2回測定同じ高圧からライブラリTPS。二回おおよそライブラリからガレラの単一のマスターコピーモードセットのパフォーマンスを言うことですメイン図書館ガレラ、など高い一方、TPSの複製のデフォルト設定セット。試験は、参考結果のMySQL、2つの異なるバージョンのため。

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)

56のwsrep_cert_deps_distance値、次のSQLの実装は、3つのノードを指示するように、スレッド60のコピー数を指定します。

set global wsrep_slave_threads=60;

次の結果、40％TPSの増加と再度テストを実行します。

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を超える受信したときに、ノードは、レプリケーションを中断しますが、16のgcs.fc_limitdeデフォルト値は明らかに小さすぎます。次のSQLコマンドに3つのノードを実行し、フロー制御が指定された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のための制御と有意な影響するかどうか。

第四に、テスト結果

ガレラは、遅滞なく、ノード間の同期複製です。
マスターライブラリーの単一のマスターコピーよりガレラパターン群は、差の半分をTPS。
TPSに大きな影響パラメータwsrep_slave_threads。
トリガートラフィック制御するかどうかをTPSに有意な影響を及ぼしませんでした。

参考：

wzy0623 ブログの専門家

公開された370元の記事・ウォンの賞賛599 ・ビュー218万+

彼のメッセージボードの懸念

MySQLのコメント（4）のためガレラクラスタ - 性能試験