はじめに

レプリケーションの性能は、ソースデータベースから転送、そしてレプリカでのコミットに至るまで、パイプラインのすべての処理に左右されます。特にレプリカ側では、変更内容をどれだけ効率よく読み取り、スケジューリングし、実際に適用できるかが、実運用下での性能を大きく左右します。これは、運用時のレイテンシ、バースト発生後のバックログ回復、メンテナンスやネットワーク障害後の追いつき時間に直接影響します。

本記事では、MySQL Labsリリースに含まれるレプリカログアプライヤの新しい機能である Change Stream Applier (CSA) を紹介します。Change Stream Applier は、並列レプリケーションのための異なる実行モデルを採用しており、バックログ回復の改善、検証シナリオでのスループット向上、そして今後のアプライヤー機能拡張に向けたよりモジュール化された基盤を重視しています。

書き込みの多い実行環境を運用している場合、アプライヤはレプリケーションが追従できるか、それとも遅れるかを決める中心的な部分です。実際には、性能だけでなく、障害や中断の後にどれだけ早くレプリカが回復できるか、あるいは リレーログ のバックログをどれだけ素早く処理できるかにも影響します。

Change Stream Applier は、以下を目的として設計されています：

  • 検証ワークロードにおけるスループット向上
  • バックログの処理速度を高め、検証シナリオでの追いつき時間を短縮
  • 将来機能のためのモジュール化された基盤の提供

背景

既存の マルチスレッドアプライヤ (MTA: multi-threaded applier) は、幅広いレプリケーションワークロードでMySQLを支えてきました。Change Stream Applier（CSA）はその基盤の上に構築されており、より高度な並列処理やバックログの高速処理が運用上大きな違いをもたらすワークロードを対象として、異なる実行モデルを模索しています。

実際の運用において、レプリカには定常状態のトラフィックに追従する以上の役割が求められます。バーストアクセスを吸収し、障害などの中断から復旧し、リレーログのバックログが溜まった際には効率的に追いつく必要があります。Change Stream Applierは、運用者が期待するレプリケーションの保証を維持しつつ、そうした状況における動作を改善するために開発されました。

Change Stream Applierは、モジュール性、バックログからの復旧、そしてチャネルレベルの制御に焦点を当てた、MySQLにおけるアプライヤ設計の新たな選択肢を提供します。MySQLコミュニティにとって、特に注目すべき点は次の2点です :

  • 行ベースのGTIDレプリケーションワークロードにおける、追従処理の向上
  • 時間をかけて拡張しやすくなった、モジュール化された適用エンジン

Change Stream ApplierのMySQL Labsリリースは、MySQL Labs からダウンロードしていただけます。

 

免責事項

免責事項： 本リリースは、コミュニティによるテスト、評価、およびフィードバックの収集を目的として提供される、MySQL Community Edition の Labs リリース（先行公開版）です。

オラクルは、本リリースを商用を目的とした製品、サービス、データベースで運用すること、またはその他の商用目的で使用することを推奨しません。

ビルドの性質： Labs リリースのビルドに対して実施されたテストは限られており、「現状のまま（AS IS）」で提供されます。バグ、セキュリティ上の脆弱性、または実験的な機能が含まれている可能性があり、エラーが存在しないことを保証するものではありません。本ビルドの使用は、すべてお客様ご自身の責任において行ってください。オラクルは Labs リリースに関するテクニカルサポートを提供せず、将来の Labs リリースや一般公開版（GA）リリースへの移行・アップグレードパスも保証されません。

将来機能に関する非コミットメント： 本 MySQL ビルドに含まれる機能および仕様は、予告なくいつでも変更される場合があります。購入判断において、これらの機能の存在を前提とすべきではありません。本ビルド内のいかなる記述も、将来のリリースでソフトウェア、コード、または機能を提供するコミットメント（約束）と解釈されるべきではなく、将来的に特定の機能が利用可能になることに依存しないでください。

ご評価中にバグや性能上の問題を見つけた場合は、コミュニティトラッカー bugs.mysql.com の 「MySQL Server: Replication」 カテゴリに報告してください。

 

仕組み

Change Stream Applier（CSA）は、レプリケーションチャネルごとに APPLIER_VERSION=2 を指定して選択します。既存のマルチスレッドアプライヤ（MTA）も、APPLIER_VERSION=1 として引き続き利用可能です。

大まかにいうと、Change Stream Applier は「プロバイダー」「依存関係の適応」「スケジューリング」「実行」「セッション管理」「リソースガバナンス」を、より明示的なコンポーネントとして整理しています。これにより、運用担当者が期待するレプリケーションの保証を維持しつつ、アプライヤ内での処理の流れを変更することが可能になります。実際の運用では、以下のような重要な動作の変更が可能になります：

  • 先行するトランザクションが依存関係の解消を待っている間でも、後続の独立したトランザクションは処理を進めることができます
  • アプライの進行とコミットの進行が分離されます
  • replica-preserve-commit-order が有効な場合でも、多くのケースで無駄なワーカーの待機（パーキング）を減らしつつ、コミット順序を保護します
  • リレーログのイベントは実行直前に読み込まれ、使用後に解放されます

ユーザーの視点から見ると、Change Stream Applierは依然としてアプリライヤにすぎませんが、バックログからの復旧、チャネルレベルのガバナンス、そして将来の拡張性に重点を置いた、並列レプリケーションのためのもう一つの実行モデルを実現します。

 

パフォーマンス

まず、既存のマルチスレッドアプライヤ（MTA）と Change Stream Applier（CSA）の比較してみましょう。

この Labs のベンチマークセットでは、結果として効果的であり、特に耐久性設定 (durability) を下げた軽量プロファイルにおいてバックログ処理で最も大きな改善が見られました。

このグラフでは、NOLOGS は compression OFF、binlog OFF、redo OFF、replica-preserve-commit-order OFF で実行した構成を指します。+REDO や +RPCO などのサフィックス (接尾辞) は、特定の実行においてどのオプションが有効化されていたかを示します。DEFAULT は検証で使用した全機能を有効にしたプロファイルを指し、compression OFF、binlog ON、redo ON、replica-preserve-commit-order ON です。

64ワーカーでのベンチマークでは、全体を通してChange Stream Applier はオンラインアプライ(適用)とキャッチアップ(追従)の両方のシナリオで MTA を上回るパフォーマンスを示しました。DEFAULT プロファイルでは、10件の更新を伴うワークロードにおいて、オンラインのスループットが約 45% 向上しました（7.22k TPSに対して10.5k TPS）。このベンチマーク集において最も顕著なバックログ向上が見られたのは、耐久性オーバーヘッドの少ない軽量設定であり、代表的な結果は以下の通りです :

  • NOLOGS（1件の更新）で 54.5k vs. 49.7k
  • NOLOGS+REDO（1 件の更新）で 43.8k vs. 36k
  • NOLOGS（10 件の更新）で 30.2k vs. 10.6k
  • NOLOGS+RPCO（10 件の更新）で 25.5k vs. 9.22k

これらの結果は、アクセスの急増（バースト）やメンテナンス期間の後に、バックログを減らしてキャッチアップ時間を短縮することを目的とする場合、特にロギングや耐久性のオーバーヘッドが少ない構成において、Change Stream Applier が非常に有用である可能性を示唆しています。

一方で、テストしたすべての構成において Change Stream Applier が一律に MTA を上回るわけではないことも結果は示しています。より耐久性を重視した構成や、圧縮処理の負荷が高い構成では、バックログの向上幅は小さくなり、一部の実行では依然として MTA に優位性がありました。リソースの動作もワークロードによって異なり、多くのバックログ実行において、Change Stream Applier は処理をより早く完了させたために CPU 使用率が高くなりました。

なお、このベンチマークセットはあくまでマイクロベンチマークであり、本番環境を完全に代表するものではありません。定常時のスループットやバックログ解消の挙動を比較するためには有用ですが、競合が多発するホットロー（特定の行へのアクセス集中）、複数チャネルの干渉、あるいは長期運用時における挙動（ロングテール）を完全に再現しているわけではありません。

 

ベンチマーク方法

今回のベンチマークは、sysbench の oltp_write_only を使用し、非インデックス更新を対象として、オンライン処理とバックログ処理の双方のシナリオで、1件更新および10件更新のトランザクションプロファイルにフォーカスし、Change Stream Applier（CSA）とマルチスレッドアプライヤ（MTA）を比較した 64 ワーカーのベンチマーク結果を取得しました。

以下の 3 台のマシンをセットアップしました。

  • オンライン実行用ソースサーバー： 32 論理コア、256 GB RAM、SR-IOV ネットワーク、LVM RAID 0 構成の 4 x 1 TB (20 VPU) ブロックボリューム、CPU ブースト無効

  • オンライン実行およびバックログ実行用レプリカサーバー： 32 論理コア、256 GB RAM、SR-IOV ネットワーク、LVM RAID 0 構成の 4 x 1 TB (20 VPU) ブロックボリューム、CPU ブースト無効

  • クライアントマシン： 8 論理コア、256 GB RAM、SR-IOV ネットワーク、同等のストレージ構成

ワークロードは、それぞれ 8,000,000 行を持つ 8 つのテーブル、256 の sysbench スレッド、600 秒間、および 1,000,000 イベントを使用しました。書き込み負荷を最大化するため、インデックス更新および DELETE/INSERT 操作は無効化し、非インデックス更新のみを使用しました。

特に記載がない限り、アプライヤのワーカー数は 64 です。ベンチマークのマトリクスでは、トランザクションの圧縮、redo ログ記録、log-replica-updates、および replica-preserve-commit-order を変化させています。この結果は、mysql-9.7.0-labs-csa（早期リリース版）を使用して収集されたものです。

 

要件と制限事項

CSA は現在、行ベース（Row-based）の GTID レプリケーションに最適化されています。本 Labs リリースでは、既存のレプリケーション経路をすべて網羅しようとするのではなく、マルチスレッドアプライヤ（MTA）よりも絞り込んだ範囲に焦点を当てています。

要件

  • 行ベースレプリケーション（REQUIRE_ROW_FORMAT=1）
  • GTID 専用モード（GTID_ONLY=1）

制限事項

  • 非推奨のバイナリログフォーマット（STATEMENT または MIXED）の非対応
  • ファイル名/オフセットによるレプリケーションチャネルの非対応
  • 遅延アプライヤモード（SOURCE_DELAY > 0）の非対応
  • ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS の非対応
  • 拡張アプライヤ統計（extended applier statistics）の非対応
  • replica_pending_jobs_size_max の非対応（チャネルごとの APPLIER_EVENT_MEMORY_LIMIT に置き換え）

GTID 専用運用以外においても、以下の経路はスコープ外となります。

  • SQL_BEFORE_GTIDS および SQL_AFTER_GTIDS 以外の UNTIL 句の非対応
  • sql-replica-skip-counter の非対応
  • CHANGE REPLICATION SOURCE TO における IGNORE_SERVER_IDS の非対応

 

Change Stream Applierの設定と評価

Change Stream Applier（CSA）は CHANGE REPLICATION SOURCE TO を使ってチャネルごとに設定します。Labs リリースでは、行ベースレプリケーションおよび GTID 専用モードをすでに使用しているチャネルで評価するのが最も簡単です。

CSA では次の設定パラメータが導入されます：

  • APPLIER_VERSION（1 = MTA、2 = CSA）
  • APPLIER_WORKER_COUNT（CSA のみ、範囲は 1〜1024）
  • APPLIER_EVENT_MEMORY_LIMIT（CSA のみ、replica_max_allowed_packet 未満の値が指定された場合、警告とともにその最小値まで引き上げられます）

APPLIER_EVENT_MEMORY_LIMIT は、Change Stream Applier 内でキャッシュされたるバイナリログイベントのチャネルごとのメモリ上限を定義し、バックログの負荷下でも適用時のメモリ消費を一定範囲内に収めるのに役立ちます。これらのパラメータは永続化され、インスタンス再起動後も保持されます。

設定例:

STOP REPLICA FOR CHANNEL 'channel_1';
CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,
  APPLIER_WORKER_COUNT = 64,
  APPLIER_EVENT_MEMORY_LIMIT = 1073741824,
  REQUIRE_ROW_FORMAT = 1,
  GTID_ONLY = 1
FOR CHANNEL 'channel_1';
START REPLICA FOR CHANNEL 'channel_1';

評価にあたっては、すでに行ベースレプリケーションと GTID 専用モードを使用している非本番（クリティカルでない）チャネルから導入を開始するのが実践的です。まずは MTA で使用していたのと同じワーカー数から始め、代表的なスパイク時のバックログ解消時間と遅延の動作を測定してください。そこから、必要に応じてチャネルごとにワーカー数とイベントメモリ上限を調整していきます。

他の CHANGE REPLICATION SOURCE TO パラメータと同様に、CSA の設定はパフォーマンススキーマから確認できます： 

SELECT *
  FROM performance_schema.replication_applier_configuration;

実行時の統計情報については、MTA で一般的に使用されているのと同じ パフォーマンススキーマビューを使用して、Change Stream Applier の状態を観察できます。

 

実装の詳細

 

Change Stream Applier（CSA）は、単なるチューニング作業ではなく、新しいアーキテクチャによるアプローチです。

主な設計上の変更点は以下の通りです：

  • コンポーネントの明示的な分離： プロバイダー、レプリケーションストレージ（リレーログへのアクセスなど）、依存関係の適合、スケジューラー、スレッドプール、セッションサービス、統計モニター、およびリソースモニターを明示的に分離
  • 再利用可能な並行性・スケジューリングライブラリ： libs/mysql/concurrency および libs/mysql/scheduler を追加
  • イベントのライフサイクル変更： 実行直前に読み込み、使用後に解放
  • サブスクライバー主導のリレーログパージ： より早い段階での安全なファイル解放を実現

  • 明示的な停止オーケストレーション： より応答性の高いシャットダウン動作を実現

 

これは、今回の最初の Labs リリースにとどまらない重要な意味を持ちます。アプライヤを停止させずにワーカー数を変更する将来のサポート、代替のリレーログストレージバックエンド、長大なトランザクションのより早期のスケジューリングタイミングなど、今後の機能追加に向けた、よりクリーンな基盤を MySQL に提供します。

実装の詳細についてさらに知りたい方は、対応する Worklog の設計ドキュメントをご参照ください。

 

フィードバックの提供方法

 

皆様からのフィードバックを心よりお待ちしております。フィードバックをいただく際は、正確なビルド情報と再現可能なシナリオを添付していただけると助かります。

特に優先度が高いフィードバック領域は以下の通りです：

 

  • 過去のバージョンに対するリグレッション
  • アップグレードおよびダウングレードの挙動
  • パフォーマンスの差分（プラス・マイナス問わず）
  • Group Replication や InnoDB Cluster を含む、レプリケーションおよび高可用性（HA）のエッジケース
  • 新機能に対するフィードバック

開発チームへは、通常のコミュニティチャネルを通じて連絡できます：

バグ報告の際は、以下の情報を含めてください：

  • 正確な Early Release のビルド識別子とプラットフォーム（例: mysql-9.7.0-labs-csa）、カテゴリは MySQL Server: Replication

  • 最小限の再現手順

  • 期待される挙動と実際の挙動

  • 設定と関連するログやエラー

まとめ

Change Stream Applier（CSA）は、並列適用スループットの向上 と バックログ回復の高速化 という2つを目指してMySQL に導入された新しいレプリケーションアプライヤです。今回の 64 ワーカーによるベンチマークでは、Change Stream Applier は通常のオンラインアプライ性能を向上させ、耐久性設定を下げた構成で最も大きなキャッチアップ性能の向上が見られました。一方で、より耐久性を高めた構成や圧縮負荷の高いケースでは、向上幅が小さくなるか、あるいは混在した結果となりました。

すでに行ベースの GTID レプリケーション運用を行っている環境では、Change Stream Applier は検証そ行う価値が十分あります。今回のテスト結果がより幅広いワークロードでも再現されれば、CSA は日常のレプリケーション動作を改善すると同時に、将来のアプライヤ開発に向けたより強固なアーキテクチャ基盤になるでしょう。

 

ぜひこの機能プレビューをお試しいただき、ご意見・ご感想をお寄せください。