MySQL Community Server 26.7 Early Access リリース

MySQL 26.7 は、MySQL 9.7 LTS リリース後の最初の MySQLイノベーション・リリースであり、四半期ごとのイノベーション・リリース公開に向けて新しい yy.mm CalVer バージョニングモデルを採用しています。この Early Access リリースでは、MySQL Community Server パッケージに予定されている一部機能のプレビューを提供し、一般提供前に今後の変更を評価する機会をユーザーに提供します。
ダウンロードはこちらから MySQL Early Access

この記事では、次の4点について取り上げます。

• MySQL 26.7 Early Access リリースに含まれる内容
• 主要機能の詳細
• テストとフィードバックへのご協力のお願い
• この Early Access リリースで対応した MySQL Community GitHub issues

提供範囲

MySQL 26.7 Early Access リリースには、以下の分野における更新が含まれています:

• InnoDB ストレージエンジンとリカバリ・インフラストラクチャ
• レプリケーションおよびグループレプリケーション
• サーバーのセキュリティ
• アップグレードおよび互換性チェック
• 実行時の接続処理

他の Early Access リリースと同様、このリリースは評価とフィードバックを目的としています。本番環境では使用しないでください。

より堅牢な UNDOログの切り詰め

MySQL 26.7 では、InnoDB の undoログ切り詰め処理の堅牢性が向上しました。

undoログ は、トランザクションのロールバックと一貫性のある読み取りに必要な情報を保存します。時間の経過とともに undo テーブルスペースは増大するため、領域を解放するために回収する必要があります。InnoDB undoトランザクションは以前からクラッシュセーフでしたが、MySQL 26.7 での変更は、切り詰め処理をより堅牢でredoログとの互換性を高めることです。

従来は、undo処理が進行中であることを示すために進行中であることを示すために、ローカルファイルの存在を前提とした設計になっていました。MySQL 26.7ではこの依存関係が解消され、代わりにundoヘッダー内のフラグを使用して進行状況を追跡するようになりました。

undoログ管理は、長時間実行されるトランザクションシステムの領域使用量、リカバリ動作、および運用予測可能性に影響を与えるため重要です。目的は、ユーザーから見えるMVCCの動作やトランザクションのセマンティクスを変更することではなく、リカバリシナリオ全体にわたって基盤となる切り捨て処理をより堅牢にすることです。

InnoDBのリカバリとメタデータインフラストラクチャ

MySQL 26.7 には、redoログインターフェース、テーブルスペースインターフェース、MVCC と ReadView インターフェース、スタンドアロン redoログ再生、永続テーブルメタデータの チェックポイントからの分離、undoリカバリ中のIXテーブルロックの高速復元など、InnoDBインフラストラクチャの改善がいくつか含まれています。

これらの変更は主に内部的なものです。InnoDBのコアとなるリカバリ、メタデータ、redoログ、テーブルスペース、トランザクション可視性に関するコードパスの構造と効率性を向上させます。目的は、ユーザーから見えるSQLのセマンティクスを変更することなく、これらの領域の保守、テスト、拡張を容易にすることです。

ユーザーの視点から見ると、MVCCは以前と同様に動作します。トランザクションの可視性、一貫性のある読み取り、並行処理の動作に変更はありません。また、これらのインフラストラクチャの変更によるパフォーマンスの低下もありません。

これは、リカバリ、メタデータの永続性、およびMVCCがInnoDBの確実性の基礎となるため重要です。新しい構文や設定として直接公開されない変更であっても、より明確で効率的な内部インターフェースはリスクを軽減し、将来の改善をサポートします。

レプリケーション用Change Stream Applier

Change Stream ApplierのLabsリリースに続き、MySQL 26.7 Early Accessでは、26.7サーバーリリースストリームの一部として、このレプリケーションアプライヤーを評価用に提供しています。Change Stream Applierは、並列適用動作を改善し、将来のレプリケーション作業のためのよりモジュール化された基盤を提供するように設計された、新しいレプリケーションアプライヤーの実装です。

アプライヤーは、ソースから受信した変更を処理し、レプリカに適用する役割を担います。その効率は、レプリケーションの遅延、バックログの回復、書き込みアクティビティの急増後やメンテナンス期間後のレプリカの回復速度に直接影響します。

Change Stream Applier は、並列レプリケーションに異なる実行モデルを導入します。適用処理とコミット処理を分離し、後の独立したトランザクションが続行できるようにし、前のトランザクションが依存関係を維持できるようにします。この設計では、APPLIER_VERSION、APPLIER_WORKER_COUNT、APPLIER_EVENT_MEMORY_LIMIT などの チャネルごとの制御機能も導入されています。

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

設定例:

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';

今回の Early Access リリースでは、行ベースのGTIDレプリケーションを対象としています。既存のすべてのレプリケーションモードを代替するものではありません。ユーザーは、行ベースのレプリケーションとGTIDのみのモードを既に使用している重要度の低いチャネルで、まず評価を行う必要があります。

このリリースでは、ステートメントまたは混合バイナリログ形式、ファイル名/オフセットのレプリケーションチャネル、遅延アプライヤーモード、 GTID_ONLY=0、REQUIRE_ROW_FORMAT=0、および replica_pending_jobs_size_max など、一部のレプリケーションモードと構成パターンは対応範囲外のままです 。Change Stream Applier では、replica_pending_jobs_size_max は channel ごとの APPLIER_EVENT_MEMORY_LIMIT に置き換えられます。

この機能は、読み取りスケーリング、高可用性、災害復旧、移行、変更データキャプチャなどにレプリケーションを利用するユーザーにとって重要です。書き込み負荷の高いワークロードでは、適用パフォーマンスがレプリカを最新の状態に保つための制約要因となることが多く、バックログの復旧速度が速ければ、負荷の急増や中断後の運用リスクを軽減できます。

実装の詳細については、WL#10500 “MTA: Optimized and generic change stream applier” を参照してください: https://dev.mysql.com/worklog/task/?id=10500

グループレプリケーションのデフォルト通信スタック

MySQL 26.7 では、Group Replication のデフォルト通信スタックが MYSQL に変更されます。

グループレプリケーションは、通信スタックを使用してグループメンバー間のメッセージを調整します。この MYSQL通信スタックは、グループレプリケーション独自のXCom接続セキュリティ実装ではなく、MySQL Serverの接続セキュリティを使用します。これにより、グループレプリケーションの設定がサーバーの他の設定とより密接に整合し、デフォルト構成のセキュリティが強化されます。また、MySQL通信スタックは認証にグループレプリケーションの分散リカバリユーザーを使用するため、そのユーザーに適切な権限が必要です。

この変更を含むバージョンを実行するサーバーでは、サーバー設定ファイル または コマンドライン で group_replication_communication_stack が明示的に設定されない限り、新しいデフォルトが自動的に適用されます。

これは、新しくグループレプリケーションを構築する際に重要です。なぜなら、デフォルトのパスの方がシンプルで、MySQLサーバーの認証および接続セキュリティとの整合性が高いからです。また、既存の運用においても通信スタックを変更すると、アップグレードや運用に影響が生じるため重要です。

重要なアップグレードに関する注意事項: グループレプリケーションの通信スタックを変更することは、実行中のグループに対してオンラインで変更するものではありません。通信スタックは、すべてのグループメンバー間で一貫している必要があります。既存のグループを XCOM から MYSQL に移行する管理者は、すべてのメンバでグループレプリケーションを停止し、必要な設定を更新した上で、 分散リカバリユーザーにGROUP_REPLICATION_STREAM と CONNECTION_ADMIN を付与してから、ドキュメントに記載されている手順に従ってグループを再起動またはブートストラップする必要があります。

手順と接続セキュリティ要件の詳細については、グループレプリケーションの接続セキュリティに関するドキュメントを参照してください: https://dev.mysql.com/doc/refman/en/group-replication-connection-security.html

MySQL InnoDB Cluster はすでに group_replication_communication_stack=MYSQL を使用しているため、このデフォルト変更による影響は受けません。

グループレプリケーションのXComスタックオプションの非推奨化

MySQL 26.7 では、グループレプリケーションのXCom関連オプションについては非推奨となりました。

MySQL 8.4 および 9.7 では、group_replication_communication_stack を XCOM に設定すると MYSQL を推奨する警告が出力されます。MySQL 26.7 では、group_replication_communication_stack または group_replication_ip_allowlist を設定すると、代替案なしの警告が出力されます。

非推奨とは、直ちに削除することを意味するものではありません。ユーザーが、今後廃止される予定の設定に依存しないように、構成、デプロイの自動化、および運用に関するドキュメントの更新を開始する必要があることを意味します。

現在グループレプリケーションを採用しているユーザーにとっては、明示的な警告により、非推奨の設定が互換性の問題になる前に可視化され、アップグレードに向けて余裕をもって準備するよう促します。

OpenSSL 3.5によるポスト量子暗号のサポート

MySQL Server 26.7 には、OpenSSL 3.5以降を使用して構築した場合、耐量子計算機暗号（Post-Quantum Cryptography）をサポートします。

耐量子計算機暗号は、将来的に実用化が見込まれる暗号解読能力を持つ量子コンピュータによる攻撃からデータを保護することを目的とした暗号技術です。MySQLサーバーでは、この技術により、利用しているOpenSSLのバージョンが対応している環境で、耐量子計算機向けの鍵交換アルゴリズムを評価・検証できるようになります。

MySQLサーバー は ハイブリッド方式と純粋な耐量子計算機方式の両方鍵交換アルゴリズムをサポートしていますが、互換性を考慮して古いクライアントとの相互運用性に優れたハイブリッド方式が優先的に使用されます。また、耐量子計算機暗号のみを厳密に使用する必要がない場合は、従来の鍵交換アルゴリズムへフォールバックすることも可能です。

サポートされる鍵交換グループは次のとおりです(優先順位順):

• X25519MLKEM768 — ハイブリッド方式（X25519 + ML-KEM-768）
• secp384r1MLKEM1024 — ハイブリッド方式（P-384 + ML-KEM-1024）
• secp256r1MLKEM768 — ハイブリッド方式（P-256 + ML-KEM-768）
• MLKEM512 — 純粋な耐量子計算機方式（ML-KEM-512）
• MLKEM768 — 純粋な耐量子計算機方式（ML-KEM-768）
• X25519 — 従来方式（ECDH）へのフォールバック
• secp384r1 — 従来方式（ECDHE）へのフォールバック
• secp256r1 — 従来方式（ECDHE）へのフォールバック
• secp521r1 — 従来方式（ECDHE）へのフォールバック

この機能は、長期間保管するデータを扱う組織や、厳格なセキュリティ規制への対応が求められる組織、あるいは将来を見据えた暗号ポリシーを採用している組織にとって特に重要です。標準として広く採用される前の段階から評価を始めることで、必要となるプラットフォーム要件や相互運用性、運用面への影響を事前に把握し、将来の移行に備えることができます。

互換性チェックおよびアップグレードチェックの進捗表示

MySQL 26.7では、互換性チェックおよびアップグレードチェックの進捗状況を表示する機能が追加されました。

大規模なスキーマや複雑な環境では、アップグレードチェックに時間がかかることがあります。進捗状況が表示されない場合、管理者は処理が正常に進行しているのか、現在どのフェーズを実行しているのか、あるいは処理が停止しているのかを判断できない場合があります。

進捗表示により、アップグレード準備の状況をより可視化できるようになりました。MySQLが現在どの項目を確認しているのかを把握できるほか、長時間実行されるチェックの進行状況を追跡し、アップグレード準備に関するワークフローのトラブルシューティングも可能になります。

この機能は、MySQLのバージョンアップを計画しているDBAにとって特に有用です。アップグレード前の検証作業における不確実性を減らし、運用手順書（Runbook）へのアップグレードチェックの組み込みを容易にします。

MySQL Community ServerでThread Pool Pluginを利用可能に

MySQL 26.7 では、Thread Pool Plugin が 利用可能になりました。

Thread Pool Pluginは、従来の「接続ごとに1スレッドを割り当てる（one-thread-per-connection）」実行モデルに代わる仕組みです。大量の接続によってスレッドが過剰に作成されるのを防ぎ、多数のクライアント接続に対するSQL実行スレッドを効率的に管理します。

この機能は、多数の同時接続を扱うワークロードにおいて特に効果があります。Thread Poolによるスケジューリングによって、サーバーの並列実行数をホストが処理可能な範囲に保ち、高負荷時でも安定性を向上させるとともに、レスポンスタイムのばらつきを抑えることができます。

Community ServerでThread Pool Pluginが利用可能になったことで、商用版（Enterprise Edition）を利用しなくても、この動作を評価できるようになりました。Enterprise EditionのThread Poolを利用したことがあるユーザーであれば、設定方法やチューニング方法はほぼ同じです。26.7 Early Access での変更は、この plugin が MySQL Community Server で利用可能になることです。インストールやチューニング方法についての詳細は、26.7 Early Accessドキュメントおよび リリースノートで確認してください。

Early Accessリリースで確認していただきたいポイント

Early Accessリリースでは、実際の運用に近いワークロードや構成でこれらの新機能を検証していただくことが、最も有益なフィードバックにつながります。MySQL Early Access Releaseはこちらからダウンロードできます。

InnoDBのリカバリおよびUNDO関連では、代表的なトランザクションワークロードを用いて、Undoログの切り詰め（Undo Log Truncation）やリカバリ動作を検証してください。また、MVCCの動作、トランザクションの可視性、アプリケーションの挙動に変更がないことも確認してください。

レプリケーション環境では、行ベースのGTIDレプリケーションでChange Stream Applierをテストし、レプリカ遅延、バックログの解消時間、CPU使用率、メモリ使用量、APPLIER_WORKER_COUNTおよびAPPLIER_EVENT_MEMORY_LIMIT変更時の挙動などを評価していただければと思います。

グループレプリケーション関連では、新規構築だけでなくアップグレードの観点からも検証してください。特にgroup_replication_communication_stack=XCOMを明示的に設定した環境での挙動、分散リカバリユーザーの権限、非推奨設定に関する警告について重点的に確認してください。

耐量子計算機暗号（PQC）については、異なるOpenSSLバージョンでビルドされたクライアントとのTLS相互運用性を検証してください。また、ハイブリッドPQCグループと、PQCを必須としない場合のフォールバック動作も確認してください。

アップグレードに関しては、大規模スキーマに対して互換性チェックやアップグレードチェックを実行し、進捗表示が運用上十分に役立つ情報を提供しているか確認してください。

同時接続数が増大する環境においては、実際の接続数やレイテンシ要件、トランザクション構成を用いて、Thread Pool Pluginと従来の「接続ごとに1スレッド」方式の動作を比較してください。

Early Accessリリース へのフィードバックは、機能の品質向上やドキュメントの改善、正式リリース前の互換性・性能上の問題の発見に大きく役立ちます。

MySQL Community GitHub Issueとの対応

以下の表は、26.7 Early Access の内容と関連する MySQL Community GitHub issues の対応関係を示したものです。各 issue が完全に解決または クローズ されたことを示すものではありません。

これらのIssueの中には、広範な基盤開発に関するものもあれば、今回紹介した個別機能に直接対応するものもあります。Early Accessリリースへのフィードバックは、正式リリース前に動作の検証やドキュメントの改善、互換性や性能上の問題の洗い出しを行う上で重要な役割を果たします。

いつもMySQLをご利用いただき、ありがとうございます。

MySQL Early Accessのダウンロード