Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb
HTML Download (TGZ) - 10.0Mb
HTML Download (Zip) - 10.1Mb


このページは機械翻訳したものです。

18.6.3 メッセージ圧縮

オンライングループメンバー間で送信されるメッセージの場合、グループレプリケーションはデフォルトでメッセージ圧縮を有効にします。 特定のメッセージが圧縮されるかどうかは、group_replication_compression_threshold システム変数を使用して構成するしきい値によって決まります。 ペイロードが指定されたバイト数より大きいメッセージは圧縮されます。

デフォルトの圧縮しきい値は 1000000 バイトです。 たとえば、次のステートメントを使用して、圧縮しきい値を 2MB に増やすことができます:

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold = 2097152;
START GROUP_REPLICATION;

group_replication_compression_threshold をゼロに設定すると、メッセージ圧縮は無効になります。

グループレプリケーションでは、LZ4 圧縮アルゴリズムを使用して、グループで送信されるメッセージを圧縮します。 LZ4 圧縮アルゴリズムでサポートされる最大入力サイズは 2113929216 バイトです。 この制限は、XCom で受け入れられる最大メッセージサイズと一致する、group_replication_compression_threshold システム変数の最大可能値を下回っています。 したがって、LZ4 の最大入力サイズはメッセージ圧縮の実用的な制限であり、メッセージ圧縮が有効な場合、このサイズを超えるトランザクションはコミットできません。 LZ4 圧縮アルゴリズムでは、group_replication_compression_threshold に 2113929216 バイトを超える値を設定しないでください。

グループレプリケーションでは、group_replication_compression_threshold の値はすべてのグループメンバーで同じである必要はありません。 ただし、トランザクションの不要なロールバック、メッセージ配信の失敗またはメッセージリカバリの失敗を回避するために、すべてのグループメンバーに同じ値を設定することをお薦めします。

MySQL 8.0.18 から、ドナーバイナリログからの状態転送によって分散リカバリ用に送信されるメッセージの圧縮を構成することもできます。 グループ内にすでに存在するドナーから参加メンバーに送信されるこれらのメッセージの圧縮は、group_replication_recovery_compression_algorithm および group_replication_recovery_zstd_compression_level システム変数を使用して個別に制御されます。 詳細は、セクション4.2.8「接続圧縮制御」を参照してください。

binlog_transaction_compression システム変数によってアクティブ化されるバイナリログトランザクション圧縮 (MySQL 8.0.20 で使用可能) を使用して帯域幅を節約することもできます。 トランザクションペイロードは、グループメンバー間で転送されても圧縮されたままです。 バイナリログトランザクションの圧縮を Group Replication メッセージの圧縮と組み合わせて使用する場合、メッセージの圧縮ではデータを処理する機会は少なくなりますが、ヘッダーと、圧縮されていないイベントおよびトランザクションペイロードは圧縮できます。 バイナリログのトランザクション圧縮の詳細は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。

グループ内で送信されるメッセージの圧縮は、データがグループ通信スレッドに渡される前に、グループ通信エンジンレベルで行われるため、mysql ユーザーセッションスレッドのコンテキスト内で行われます。 メッセージペイロードサイズが group_replication_compression_threshold で設定されたしきい値を超えると、トランザクションペイロードはグループに送信される前に圧縮され、受信時に解凍されます。 メッセージを受信すると、メンバーはメッセージエンベロープをチェックして、圧縮されているかどうかを確認します。 必要に応じて、メンバーは上位レイヤーに配信する前にトランザクションを解凍します。 このプロセスを次の図に示します。

図 18.15 圧縮のサポート

MySQL Group Replication プラグインアーキテクチャーは、前のトピックで説明したように、プラグインの 5 つのレイヤーが MySQL サーバーとレプリケーショングループの間に配置されています。 圧縮と解凍は、Group Replication プラグインの第 4 層である Group Communication System API によって処理されます。 グループ通信エンジン (プラグインの第 5 層) とグループメンバーは、より小さいデータサイズの圧縮トランザクションを使用します。 MySQL Server コアおよび Group Replication プラグインの上位 3 つのレイヤー (API、キャプチャ、適用機能およびリカバリコンポーネント、およびレプリケーションプロトコルモジュール) では、より大きいデータサイズの元のトランザクションが使用されます。

ネットワーク帯域幅がボトルネックの場合、メッセージ圧縮により、グループ通信レベルでスループットが最大 30 から 40% 向上します。 これは、負荷の高い大規模なサーバーグループのコンテキスト内で特に重要です。 グループ内の N 参加者間の相互接続の TCP ピアツーピアの性質により、送信者は同じ量のデータを N 回送信します。 さらに、バイナリログは高い圧縮率を示している可能性があります。 これにより、圧縮は、大規模なトランザクションを含むグループレプリケーションワークロードにとって魅力的な機能になります。