Group ReplicationのFlow controlを調整する

MySQL 8.0

はじめに

MySQLのGroup ReplicationにはFlow controlという機能があります。
Flow controlを制御するためのパラメータが複数ありますが、本記事では一部のパラメータがどのようにFlow controlに影響するかを確認してみました。

前提

今回は、MySQL8.0.35で検証を行います。Group Replicationは3台構成です。
また、今回の記事で確認する変数は全て、SETコマンドで変更すると即時反映されます。レプリケーションの停止などは不要となります。
なお、各検証で特に断りが無い場合は、パラメータはデフォルト値となっています。

目次

テストデータ準備

検証にはsysbenchを使用して更新処理を行います。
下記のコマンドで事前準備を行います。

続いて、下記のコマンドで事前にテーブルを作成します。

performance_schema.replication_group_member_statsについて

performance_schema.replication_group_member_statsで各メンバーの統計情報を確認できます。
本記事で関係するカラムを説明します。

  • COUNT_TRANSACTIONS_IN_QUEUE
    キュー内の保留中の競合検出チェックのトランザクション数。 トランザクションの競合がチェックされた後、チェックに合格すると、トランザクションも適用されるようにキューに入れられます。

  • COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE
    このメンバーがレプリケーショングループから受信し、適用を待機しているトランザクションの数。

  • COUNT_TRANSACTIONS_LOCAL_PROPOSED
    このメンバーで発生し、グループに送信されたトランザクションの数。

COUNT_TRANSACTIONS_IN_QUEUEがgroup_replication_flow_control_certifier_thresholdを超えるか、COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEがgroup_replication_flow_control_applier_thresholdを超えるとFlow controlが発生します。

今回はPercona Monitoring and Management(PMM)のMySQL Group Replication Summaryダッシュボードを使用して、COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEやCOUNT_TRANSACTIONS_LOCAL_PROPOSEDなどの値を確認していきます。

検証

group_replication_flow_control_applier_threshold

group_replication_flow_control_applier_thresholdはFlow controlをトリガーする閾値を決めます。
また、group_replication_flow_control_modeはFlow controlのモードを指定します。DISABLEDに設定するとFlow controlは無効になります。

Flow controlを無効にした場合とgroup_replication_flow_control_applier_thresholdが5000の場合の検証結果を比較します。

  • Flow control無効

  • group_replication_flow_control_applier_thresholdを5000に設定

下記のコマンドでsysbenchを実行します。

最初にFlow control無効にしたパターンを実行し、次にgroup_replication_flow_control_applier_thresholdを5000に設定したパターンを実行しています。

図の左下のReceived Transactions Queueはperformance_schema.replication_group_member_statsCOUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEカラムのグラフです。これは、現在適用を待機しているトランザクションの数を示しています。2回目の検証では、キューの数が設定した5000の閾値付近で横ばいになっていることがわかります。

また、右上にあるSent Transactionsはperformance_schema.replication_group_member_statsCOUNT_TRANSACTIONS_LOCAL_PROPOSEDカラムのグラフです。これは、グループに送信されたトランザクションの数を示しています。2回目の検証では、送信されたトランザクションが途中から増減を繰り返していて、Flow controlによる制御が行われていることがわかります。

Flow control発生中のgroup_replication_flow_control_modeの変更

Flow control発生中にgroup_replication_flow_control_modeを変更した際の動作を確認します。

まずは、group_replication_flow_control_modeをQUOTAとし、group_replication_flow_control_applier_thresholdを5000に設定します

下記のコマンドでsysbenchを実行します。

2分後にgroup_replication_flow_control_modeをDISABLEDに設定します
※このタイミングで目印として、グラフにはオレンジの縦線が挿入されています

さらにその2分後にgroup_replication_flow_control_modeをQUOTAに設定します
※同じくこのタイミングでもグラフにはオレンジの縦線を挿入しています

最初の2分間の間にSent Transactionsのグラフで値が上下していることから、Flow controlが発生していることがわかります。

そして、group_replication_flow_control_modeがDISABLEDに変更されるとすぐに、Sent Transactionsの値はほぼ一定になります。また、Received Transactions Queueの値が急増しています。このことからFlow controlが停止していることがわかります。

2分後に再度group_replication_flow_control_modeがQUOTAに変更されると、Received Transactions Queueの値がgroup_replication_flow_control_applier_thresholdで設定した5000に下がるまで、一時的にSent Transactionsの値が急減しています。

その後は最初の2分間と同じようにSent Transactionsの値は増減を繰り返します。

意図せずFlow controlが発生が発生した場合は、すぐにFlow controlを無効にできることがわかります。逆にシステム稼働中にFlow controlを有効にしたり、関連パラメータを変更すると急にFlow controlが発生し、処理が制限される可能性もあるので注意が必要です。

group_replication_flow_control_hold_percent

group_replication_flow_control_hold_percentはドキュメントで下記のように説明されています。

group_replication_flow_control_hold_percent では、フロー制御下のクラスタがバックログで捕捉できるように、未使用のままになるグループ割当ての割合を定義します。 値 0 は、作業バックログを捕捉するために割当て制限の一部が予約されていないことを意味します。

https://dev.mysql.com/doc/refman/8.0/ja/group-replication-options.html#sysvar_group_replication_flow_control_hold_percent

具体的にどのように動作するのか、group_replication_flow_control_hold_percentの値を順番に10(デフォルト),70,100としてsysbenchを実行した場合を比較してみます。
なお、group_replication_flow_control_applier_thresholdは5000に設定しています。

group_replication_flow_control_hold_percent=100とした3回目の検証を見ると、Received Transactions Queueのグラフで、キューが0になるのを待っていることがはっきりとわかります。

group_replication_flow_control_max_quota

group_replication_flow_control_max_quotaはドキュメントで下記のように説明されています。

group_replication_flow_control_max_commit_quota では、フロー制御が有効になっている間、グループの最大フロー制御割当て制限または任意の期間の最大使用可能割当て制限が定義されます。 値 0 は、最大割当て制限が設定されていないことを意味します。

https://dev.mysql.com/doc/refman/8.0/ja/group-replication-options.html#sysvar_group_replication_flow_control_max_commit_quota

※日本語版ドキュメントではgroup_replication_flow_control_max_commit_quotaと記載されていますが、英語版及び実際のパラメータはgroup_replication_flow_control_max_quotaとなっていました。

group_replication_flow_control_max_quotaを0(デフォルト),500としてsysbenchを実行した場合を比較します。
なお、今回はCOUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUEが閾値を超えたことによるFlow controlの発生を回避するため、group_replication_flow_control_applier_threshold50000に設定しています。

Sent Transactionsのグラフから、送信したトランザクションの数が設定した制限(group_replication_flow_control_max_quota=500)と一致していることがわかります。group_replication_flow_control_applier_thresholdの閾値に達していない場合もトランザクションが制限されることがわかります。

なお、group_replication_flow_control_modeDISABLEDに設定した場合は、group_replication_flow_control_max_quotaによる制限も行われません。

group_replication_flow_control_min_quota

group_replication_flow_control_min_quotaはドキュメントで下記のように説明されています。

group_replication_flow_control_min_quota は、最後の期間に実行された計算済の最小目標とは関係なく、メンバーに割り当てることができる最小フロー制御目標を制御します。 値 0 は、最小割当て制限がないことを意味します。

https://dev.mysql.com/doc/refman/8.0/ja/group-replication-options.html#sysvar_group_replication_flow_control_min_quota

group_replication_flow_control_applier_thresholdを5000に設定し、
group_replication_flow_control_min_quotaを0(デフォルト),900でそれぞれsysbenchを実行した場合を比較します。

Sent TransactionsとReceived Transactions Queueのグラフから、1回目の検証では、キューの数がgroup_replication_flow_control_applier_thresholdを超えたため、Flow controlがトリガーされていることがわかります。

一方で、2回目の検証では、キューの数がgroup_replication_flow_control_applier_thresholdを超えたものの、group_replication_flow_control_min_quotaで設定した900の辺りまではトランザクションの送信ができていることがわかります。

group_replication_flow_control_release_percent

group_replication_flow_control_release_percentはドキュメントで下記のように説明されています。

 group_replication_flow_control_release_percent では、フロー制御でライターメンバーを制限する必要がなくなった場合に、グループ割当て制限を解放する方法を定義します。

https://dev.mysql.com/doc/refman/8.0/ja/group-replication-options.html#sysvar_group_replication_flow_control_release_percent

まずは、group_replication_flow_control_applier_thresholdを5000に設定し、
group_replication_flow_control_release_percentを5,50(デフォルト)でそれぞれsysbenchを実行した場合を比較します。

group_replication_flow_control_release_percentを5とした場合、制限が解除された後、Sent Transactionsの値の上昇は緩やかであることがわかります。

次にgroup_replication_flow_control_applier_thresholdを100に設定し、
group_replication_flow_control_release_percentを50(デフォルト)と1000でそれぞれsysbenchを実行した場合を比較します。

group_replication_flow_control_release_percentを1000に設定すると、現在のクォータの最大10 倍(1000%)でクォータを解放できます。ドキュメントでは下記のように説明されています。

The range allows the quota to be released at up to 10 times current quota, as that allows a greater degree of adaptation, mainly when the flow control period is large and the quotas are very small.

https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_flow_control_release_percent

グラフを見ると、制限解除後のSent Transactionsの値の値が急上昇していることがわかります。

まとめ

Flow controlを制御しているパラメータの一部について、どのように動作するのかを検証してみました。ドキュメントだけでは読み取りにくかったものも、整理できたのではないかと思います。
Flow control関連のチューニングを考えている場合は、本記事も参考にしてみてください。
また、今回の検証で使用したPMMのグラフは全てデフォルトで使用できるものです。Group Replicationを監視するための追加設定などは不要で簡単にGroup Replicationのステータスの確認ができました。
下記のブログ記事では、PMMのMySQL Group Replication Summaryダッシュボードで監視できる情報について詳しく説明がされているので、本記事と合わせてご参考いただければと思います。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次