7.4. データベースレプリケーションのパフォーマンスのテスト
クラスターおよび個々のノードがすべて健全で安定している場合、特定のデータベース変数のクエリーを行い、レプリケーションのスループットについてパフォーマンスのベンチマークテストを行うことができます。
これらの変数の 1 つのクエリーを行うたびに、FLUSH STATUS
コマンドは変数の値をリセットします。ベンチマークテストを行うには、複数のクエリーを実行し、差異を分析する必要があります。この差異は、Flow Control がクラスターのパフォーマンスにどの程度影響を及ぼしているかを判断するのに役立ちます。
Flow Control は、クラスターがレプリケーションを制御するのに使用するメカニズムです。ローカルの 受信キュー が一定のしきい値を超えると、キューのサイズが減少するまで、Flow Control はレプリケーションを一時停止します。Flow Control の詳細は、Galera Cluster の Web サイトで「Flow Control」を参照してください。
手順
次のコマンドを実行し、VARIABLE
を確認する wsrep
データベース変数に置き換えます。
$ sudo podman exec galera-bundle-podman-0 sudo mysql -B --password="[MYSQL-HIERA-PASSWORD]" -e "SHOW STATUS LIKE 'VARIABLE';"
以下の表には、データベースレプリケーションのパフォーマンスをテストするのに使用できるさまざまな wsrep
データベース変数をまとめています。
変数 | 概要 | 用途 |
---|---|---|
| 最後のクエリー後のローカル受信 Write Set キューの平均サイズ |
値が 0.0 を超えていれば、ノードが受信速度に対応して Write Set を適用できないことが分かります。この場合、レプリケーションのスロットリングがトリガーされます。このベンチマークの詳しい情報は、 |
| 最後のクエリー後の送信キューの平均長さ | 値が 0.0 を超えていれば、レプリケーションのスロットルおよびネットワークスループットの問題の可能性が高いことが分かります。 |
| 最後のクエリー後のローカル受信キューの最小/最大サイズ |
|
| 最後のクエリー以降、Flow Control がノードを一時停止した時間の割合 |
値が 0.0 を超えていれば、Flow Control がノードを一時停止したことが分かります。一時停止の時間を把握するには、 以下に例を示します。
|
|
並行して適用することのできるシーケンス番号 ( |
スロットリングおよび一時停止の場合、この変数は並行して適用することのできる Write Set 数の平均を示します。この値を |
| 同時に適用することのできるスレッドの数 |
この変数の値を増やして、より多くのスレッドを同時に適用することができます。これにより、
たとえば、
問題のあるノードの |