MySQL 8.0.20 から、MySQL サーバーインスタンスでバイナリログトランザクション圧縮を有効にできます。 バイナリログのトランザクション圧縮が有効になっている場合、トランザクションペイロードは zstd アルゴリズムを使用して圧縮され、単一のイベント (Transaction_payload_event) としてサーバーのバイナリログファイルに書き込まれます。 圧縮トランザクションペイロードは、レプリケーションストリームでレプリカ、他のグループレプリケーショングループメンバー、または mysqlbinlog などのクライアントに送信されている間、圧縮状態のままです。 これらは受信側スレッドによって解凍されず、圧縮された状態のままリレーログに書き込まれます。 したがって、バイナリログトランザクション圧縮では、トランザクションの作成者と受信者 (およびそのバックアップ) の両方に記憶領域が節約され、トランザクションがサーバーインスタンス間で送信されるときにネットワーク帯域幅が節約されます。
圧縮されたトランザクションペイロードは、それに含まれる個々のイベントを検査する必要がある場合に解凍されます。 たとえば、受信者に含まれるイベントを適用するために、Transaction_payload_event はアプライヤスレッドによって解凍されます。 解凍は、リカバリ中、mysqlbinlog によるトランザクションのリプレイ時、および SHOW BINLOG EVENTS ステートメントと SHOW RELAYLOG EVENTS ステートメントによっても実行されます。
binlog_transaction_compression システム変数 (デフォルトは OFF) を使用して、MySQL サーバーインスタンスでバイナリログトランザクション圧縮を有効にできます。 binlog_transaction_compression_level_zstd システム変数を使用して、圧縮に使用される zstd アルゴリズムのレベルを設定することもできます。 この値は、圧縮作業を 1 (最小作業量) から 22 (最大作業量) の範囲で決定します。 圧縮レベルが高くなるにつれて、圧縮率が高くなり、トランザクションペイロードに必要なストレージ領域およびネットワーク帯域幅が削減されます。 ただし、データ圧縮に必要な労力も増加し、元のサーバーでは時間と CPU およびメモリーリソースがかかります。 圧縮作業の増加には、圧縮率の増加と線形関係はありません。
次のタイプのイベントはバイナリログトランザクション圧縮から除外されるため、常に非圧縮でバイナリログに書き込まれます:
トランザクションの GTID に関連するイベント (匿名 GTID イベントを含む)。
変更イベントやハートビートイベントの表示など、その他のタイプの制御イベント。
インシデントイベントおよびそれを含むトランザクション全体。
非トランザクションイベントおよびそれらを含むトランザクション全体。 非トランザクションストレージエンジンとトランザクションストレージエンジンが混在するトランザクションでは、ペイロードは圧縮されません。
ステートメントベースのバイナリロギングを使用してログに記録されるイベント。 バイナリログトランザクションの圧縮は、行ベースのバイナリロギング形式にのみ適用されます。
バイナリログの暗号化は、圧縮されたトランザクションを含むバイナリログファイルで使用できます。
ペイロードが圧縮されたトランザクションは、他のトランザクションと同様にロールバックでき、通常のフィルタリングオプションを使用してレプリカでフィルタ処理で除外することもできます。 バイナリログトランザクション圧縮は XA トランザクションに適用できます。
バイナリログのトランザクション圧縮が有効になっている場合、サーバーの max_allowed_packet および slave_max_allowed_packet の制限は引き続き適用され、Transaction_payload_event の圧縮サイズにイベントヘッダーに使用されるバイト数を加えて測定されます。 圧縮トランザクションペイロードは、バイナリログトランザクション圧縮が使用されていない場合と同様に、個々のパケットで送信されるトランザクションの各イベントではなく、単一のパケットとして送信されることに注意してください。
マルチスレッドワーカーの場合、各トランザクション (GTID イベントおよび Transaction_payload_event を含む) はワーカースレッドに割り当てられます。 ワーカースレッドはトランザクションペイロードを解凍し、個別のイベントを 1 つずつ適用します。 Transaction_payload_event 内でイベントの適用中にエラーが検出された場合、完全なトランザクションは失敗したとして座標系にレポートされます。 slave_parallel_type が DATABASE に設定されている場合、トランザクションがスケジュールされる前に、トランザクションの影響を受けるすべてのデータベースがマップされます。 バイナリログトランザクション圧縮を DATABASE ポリシーとともに使用すると、イベントごとにマップおよびスケジュールされる圧縮されていないトランザクションと比較して並列度を減らすことができます。
準同期レプリケーション (セクション17.4.10「準同期レプリケーション」 を参照) の場合、レプリカは完全な Transaction_payload_event を受信したときにトランザクションを確認します。
バイナリログチェックサムが有効になっている場合 (デフォルト)、レプリケーションソースサーバーは、圧縮されたトランザクションペイロード内の個々のイベントのチェックサムを書き込みません。 代わりに、完全な Transaction_payload_event に対してチェックサムが書き込まれ、GTID に関連するイベントなど、圧縮されなかったすべてのイベントに対して個別のチェックサムが書き込まれます。
SHOW BINLOG EVENTS および SHOW RELAYLOG EVENTS ステートメントの場合、Transaction_payload_event は最初に単一のユニットとして印刷され、次に開梱され、その内部の各イベントが印刷されます。
UNTIL 句、MASTER_POS_WAIT() および sql_slave_skip_counter を使用した START REPLICA | SLAVE など、イベントの終了位置を参照する操作の場合、圧縮トランザクションペイロード (Transaction_payload_event) の終了位置を指定する必要があります。 sql_slave_skip_counter を使用してイベントをスキップする場合、圧縮されたトランザクションペイロードは単一のカウンタ値としてカウントされるため、その内部のすべてのイベントは単位としてスキップされます。
バイナリログトランザクション圧縮をサポートする MySQL Server リリースでは、圧縮されたトランザクションペイロードと圧縮されていないトランザクションペイロードの混在を処理できます。
バイナリログトランザクション圧縮に関連するシステム変数は、すべてのグループレプリケーショングループメンバーで同じように設定する必要はなく、レプリケーショントポロジのソースからレプリカにレプリケートされません。 バイナリログトランザクション圧縮がバイナリログを持つ各 MySQL Server インスタンスに適しているかどうかを判断できます。
トランザクション圧縮がサーバーで有効になっている場合、圧縮はそのサーバーで発生した将来のトランザクションには適用されませんが、圧縮されたトランザクションペイロードは引き続き処理および表示できます。
binlog_transaction_compressionのセッション値を設定して個々のセッションにトランザクション圧縮が指定されている場合、バイナリログには圧縮されたトランザクションペイロードと圧縮されていないトランザクションペイロードを混在させることができます。
レプリケーショントポロジ内のソースとそのレプリカの両方でバイナリログトランザクション圧縮が有効になっている場合、レプリカは圧縮トランザクションペイロードを受信し、それらをリレーログに圧縮して書き込みます。 トランザクションペイロードを解凍してトランザクションを適用し、バイナリログへの書込みのために適用した後で再度圧縮します。 ダウンストリームレプリカは、圧縮されたトランザクションペイロードを受信します。
レプリケーショントポロジのソースでバイナリログトランザクション圧縮が有効になっていてもレプリカで有効になっていない場合、レプリカは圧縮されたトランザクションペイロードを受信し、それをリレーログに書き込みます。 トランザクションペイロードを解凍してトランザクションを適用し、圧縮解除したペイロードがある場合は独自のバイナリログに書き込みます。 ダウンストリームレプリカは、圧縮されていないトランザクションペイロードを受信します。
レプリケーショントポロジのソースでバイナリログトランザクション圧縮が有効になっていないが、そのレプリカでバイナリログがある場合、トランザクションペイロードは適用後に圧縮され、圧縮されたトランザクションペイロードがバイナリログに書き込まれます。 ダウンストリームレプリカは、圧縮されたトランザクションペイロードを受信します。
MySQL サーバーインスタンスにバイナリログがない場合、MySQL 8.0.20 からのリリースであれば、binlog_transaction_compression の値に関係なく、圧縮されたトランザクションペイロードを受信、処理および表示できます。 このようなサーバーインスタンスによって受信された圧縮トランザクションペイロードは、圧縮状態でリレーログに書き込まれるため、レプリケーショントポロジ内の他のサーバーによって実行された圧縮から間接的に利点があります。
MySQL 8.0.20 より前のリリースのレプリカは、バイナリログトランザクション圧縮が有効になっているソースからレプリケートできません。 MySQL 8.0.20 以上のレプリカは、バイナリログのトランザクション圧縮をサポートしていない以前のリリースのソースからレプリケートでき、独自のバイナリログに書き込むときに、そのソースから受信したトランザクションに対して独自の圧縮を実行できます。
「パフォーマンススキーマ」テーブル binary_log_transaction_compression_stats を使用して、バイナリログトランザクション圧縮の影響を監視できます。 統計には、監視対象期間のデータ圧縮率が含まれ、サーバー上の最後のトランザクションに対する圧縮の影響を表示することもできます。 統計をリセットするには、テーブルを切り捨てます。 バイナリログおよびリレーログの統計は分割されるため、各ログタイプの圧縮の影響を確認できます。 これらの統計を生成するには、MySQL サーバーインスタンスにバイナリログが必要です。
「パフォーマンススキーマ」テーブル events_stages_current は、トランザクションがトランザクションペイロードの解凍または圧縮のステージにあるかどうかを示し、このステージの進行状況を表示します。 圧縮は、トランザクションがコミットされる直前に、バイナリログトランザクション圧縮 (インシデントイベントなど) からトランザクションを除外するイベントがファイナライズされた取得キャッシュにない場合に、トランザクションを処理するワーカースレッドによって実行されます。 解凍が必要な場合は、ペイロードから一度に 1 つのイベントに対して実行されます。
--verbose オプションを指定した mysqlbinlog には、圧縮されたトランザクションペイロードの圧縮サイズと圧縮されていないサイズ、および使用された圧縮アルゴリズムを示すコメントが含まれます。
CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) の SOURCE_COMPRESSION_ALGORITHMS | MASTER_COMPRESSION_ALGORITHMS および SOURCE_ZSTD_COMPRESSION_LEVEL | MASTER_ZSTD_COMPRESSION_LEVEL オプション、または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前)、または非推奨の slave_compressed_protocol システム変数を使用して、レプリケーション接続のプロトコルレベルで接続圧縮を有効にできます。 接続圧縮も有効になっているシステムでバイナリログのトランザクション圧縮を有効にすると、圧縮されたトランザクションペイロードをさらに圧縮する機会がほとんどない可能性があるため、接続圧縮の影響が軽減されます。 ただし、接続圧縮は、圧縮されていないイベントおよびメッセージヘッダーで引き続き動作できます。 ネットワーク帯域幅だけでなく記憶領域も節約する必要がある場合は、バイナリログトランザクション圧縮を接続圧縮と組み合せて有効にできます。 レプリケーション接続の接続圧縮の詳細は、セクション4.2.8「接続圧縮制御」 を参照してください。
グループレプリケーションの場合、圧縮は group_replication_compression_threshold システム変数で設定されたしきい値を超えるメッセージに対してデフォルトで有効になっています。 group_replication_recovery_compression_algorithm および group_replication_recovery_zstd_compression_level システム変数を使用して、ドナーのバイナリログからの状態転送によって分散回復のために送信されるメッセージの圧縮を構成することもできます。 バイナリログトランザクション圧縮が構成されているシステムでバイナリログトランザクション圧縮を有効にしても、グループレプリケーションメッセージ圧縮は圧縮されていないイベントおよびメッセージヘッダーでは引き続き動作できますが、その影響は軽減されます。 グループレプリケーションのメッセージ圧縮の詳細は、セクション18.6.3「メッセージ圧縮」 を参照してください。