Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 9.7 の次は 9.8 ではない
革新リリースは次の革新リリースが出た瞬間に終わる
MySQL 9.7 LTS — 2年ぶりの停泊地
9.7がコミュニティエディションへ引き渡したもの
カレンダーバージョニング — YY.M が教えてくれること
MariaDBは5週間後に同じことをした
分かれる点一つ目 — 支援期間8年対3年
分かれる点二つ目 — リリースノートが示さなかったデフォルト値の変更
では何をすべきか
おわりに
参考資料

はじめに — 9.7 の次は 9.8 ではない

2026年7月現在、MySQLの次の革新リリースのバージョン番号は26.7です。誤植ではありません。

Oracleは2026年6月16日、A More Predictable MySQL Release Modelの投稿で、MySQLのバージョン番号をカレンダーバージョニングに切り替えると発表しました。そしてMySQL 26.7.0 リリースノートの最初の項目がこれを裏付けています。

MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series. Version values use Year.Month.Patch (YY.M.P) format. MySQL 26.7.0 is the first such calendar-version release.

バージョン番号が9.7から26.7へ飛んだこと自体は、単なる表記の変更です。興味深いのは、この変化がこの2年間MySQLのリリースモデルが実際にどう回ってきたかの帰結だという点であり、さらに興味深いのはMariaDBが5週間の間隔を置いてほぼ同じことをしたという点です。本稿は、この2つの流れをリリースノートと支援ポリシーの原文まで確認して整理します。

本稿はリリースモデルと運用判断に焦点を当てます。MariaDBの内部構造(ストレージエンジン、Galera、パーティショニング)はMariaDB アーキテクチャ — ストレージエンジンから Galera までで別途扱いました。

革新リリースは次の革新リリースが出た瞬間に終わる

まず、2023年に導入されたInnovation/LTSモデルをおさらいします。MySQL 9.7 リファレンスマニュアル1.3節の一文が核心です。

Innovation releases are supported until the next Innovation release.

一文ですが、運用面ではかなり重い条件です。革新リリースを使っている間、あなたの支援期間は「次のリリースが出るまで」であり、その後も支援を受けたければアップグレードする以外の選択肢はありません。パッチリリースを待つという選択肢はないということです。

同じ文書はLTSをこう区別します。

These releases only contain necessary fixes to reduce the risks associated with changes in the database software's behavior. There are no removals within an LTS release.

逆に革新リリースについてはこう書いています。

Apart from new features in innovation releases, behavior changes are also expected as code is refactored, deprecated functionality is removed, and when MySQL is modified to behave more in line with SQL Standards.

「deprecated functionality is removed」が抽象的な警告ではないことを、9.0がそのまま示しました。MySQL 9.0.0 リリースノートには、mysql_native_password認証プラグインがサーバーから削除されたと記されています。8.0でdeprecatedだったものが次のメジャーで消えたわけで、古いクライアント・コネクタを抱えている組織はここで引っかかります。

では実際に、各革新リリースはどれだけ生きたのでしょうか。以下はOracleのリリースノートのタイトルに記載されたGA日付をそのまま転記したものです。支援終了日は上のルールに従い、単に次の行のGA日付です。

リリース	GA(リリースノート基準)	支援終了 = 次の革新リリースGA	実質寿命
9.0.0	2024-07-01	2024-10-15	約3.5か月
9.1.0	2024-10-15	2025-01-21	約3か月
9.2.0	2025-01-21	2025-04-15	約3か月
9.3.0	2025-04-15	2025-07-22	約3か月
9.4.0	2025-07-22	2025-10-21	3か月
9.5.0	2025-10-21	2026-01-20	3か月
9.6.0	2026-01-20	2026-04-21	3か月
9.7.0 (LTS)	2026-04-21	Premier 2031-04 / Extended 2034-04	8年

2年間で7回、四半期に1回のペースです。9.xラインを本番で運用していたなら、四半期ごとにメジャーアップグレードをしなければ支援対象を維持できなかったことになります。

余談ですが、9.0.0にはもう一つ注釈が付きます。リリースノートの冒頭にこうあります — "This release is no longer available for download. It was removed due to a critical issue that could stop the server from restarting following the creation of a very large number of tables (8001 or more)." テーブルを8001個以上作るとサーバーが再起動できなくなる可能性のある問題により、9.0.0は取り下げられ9.0.1に置き換えられました。革新リリースがどんなトラックかを示す事例です。

だからこそマニュアルが革新リリースを勧める相手も率直です — "developers and DBAs working in fast-paced development environments with high levels of automated tests and modern continuous integration techniques for faster upgrade cycles."。四半期ごとにメジャーアップグレードをテストして通せる組織のことです。大半の組織はこれに該当せず、該当しないと認めることが、このモデルを正しく使うための最初の一歩です。

MySQL 9.7 LTS — 2年ぶりの停泊地

MySQL 9.7.0 リリースノートのGA日付は2026-04-21です。直前のLTSである8.4.0のGAはリリースノート基準で2024-04-30なので、LTS間の間隔は2年に9日足りません。

支援期間はOracleのLifetime Support Policy文書(発効日: 2026年5月1日)に表として明記されています。月単位までしか書かれていませんが、これが一次情報源です。

リリース	GA	Premier終了	Extended終了	Sustaining
MySQL 8.0	Apr 2018	Apr 2025	Apr 2026	Indefinite
MySQL 8.4	Apr 2024	Apr 2029	Apr 2032	Indefinite
MySQL 9.7	Apr 2026	Apr 2031	Apr 2034	Indefinite

ここで目を引く行は8.0です。Premierが2025年4月に終わり、Extendedが2026年4月に終わりました。OracleのEOL通知ページはこれを"As of April 21, 2026, MySQL 8.0 is covered under Oracle Sustaining Support."と記しています — 9.7.0 LTSがGAになったまさにその日です。Sustaining SupportはOracleの用語で、期限は無期限ですが新規修正・セキュリティ通知・新規認証は伴わない段階です。つまり2018年からインターネットの相当部分を支えてきた8.0は、いまや実質的に停止状態にあります。

LTSが与えるものもマニュアルに明記されています。

Functionality remains the same and data format does not change in an LTS series, therefore in-place upgrades and downgrades are possible within the LTS series.

同じLTSラインの中ではダウングレードまで可能だということ、これが実務でLTSを選ぶ本当の理由です。ロールバック経路があるアップグレードとないアップグレードは別の作業です。

9.7がコミュニティエディションへ引き渡したもの

9.7 LTSで実際に注目すべき変化は、機能そのものよりもエディションの境界線が動いたことです。リリースノートが挙げる、これまでEnterprise専用だったがコミュニティへ降りてきたコンポーネントは以下の通りです。

Replication Applier Metrics Component
Group Replication Flow Control Statistics Component
Group Replication Resource Manager Component
Group Replication Primary Election Component
Telemetry Component

これに加えてリリースノートはさらに2点を記しています — "The Hypergraph Optimizer is now available in MySQL Community Edition"、そしてJSON Duality ViewへのDML(insert/update/delete)対応がコミュニティサーバーに入ったことです。

Telemetryがコミュニティに来たことは、運用チームにとってかなり大きな意味を持ちます。OpenTelemetry/OTLPでログ・メトリクス・トレースを送出できるということであり、これまでコミュニティエディションでMySQLを他のスタックと同じ観測パイプラインに載せるには、別途エクスポーターを付ける必要がありました。Hypergraphオプティマイザも複雑なジョイン計画の探索に使われるものなので、関心を持つ価値があります。

ただし方向は一方通行ではありません。同じリリースでDynamic Data MaskingはEnterprise側に新たに追加されました。Oracleの9.7発表記事はこれを"server-side protection of sensitive data without requiring application changes"と説明し、マスキングポリシーをベーステーブルのカラムに付与し、実行ユーザー・ロールに応じて元の値かマスキングされた値かを返す機能だと記しています。コミュニティに渡したものとEnterpriseに入れたものが、同じリリースの中に同居しているわけです。

この流れには背景があります。Perconaは2026年2月17日、An Open Letter to OracleでMySQLのガバナンスについて議論しようと公に提案しました。この投稿はOracleが2025年秋にMySQLをOCIへ移し人員を削減したと主張し、その規模を"roughly 50%"と書いていますが、これはPerconaの主張であってOracleが確認した数字ではないため、そのまま事実として受け取る根拠はありません。ただし、同じ投稿が9.7に期待すると書いていた項目 — コミュニティエディションのベクトル関数、デフォルトで有効なHypergraphオプティマイザ、完全なDMLを備えたJSON Duality、PGOビルド — は実際に9.7リリースノートで確認できます。そして同じ投稿がなお欲しいと書いている項目に"vector indexes"が残っている点も公平に見る必要があります。Perconaの表現通り「verification through action, not words」が判断基準になるのでしょうが、エディションの境界線が実際に動いたことは、少なくとも言葉だけではなかった根拠にはなります。

カレンダーバージョニング — YY.M が教えてくれること

ここで26.7に戻ります。Oracleの6月16日の発表記事は、この形式をこう定義しています。

YY — 年の下2桁
M — リリース月、先頭ゼロなし(1月は1、4月は4、7月は7、10月は10)

投稿が示す今後のケイデンス例はこうです。

26.7   – July 2026 Innovation release
26.10  – October 2026 Innovation release
27.1   – January 2027 Innovation release
27.4   – April 2027 Innovation release
27.7   – July 2027 Innovation release
27.10  – October 2027 Innovation release
28.1   – January 2028 Innovation release
28.4   – April 2028 LTS release
28.7   – July 2028 Innovation release

LTSの扱い方がこの設計の核心です。LTSに指定されたラインは、寿命の間ずっとそのYY.M接頭辞を維持します — 28.4.0 → 28.4.X → 28.4.Y → 28.4.Zという具合で、2030年に28.4.10を見たとしても、番号だけで「2028年4月に始まったLTSライン」だと分かります。Oracleの表現では"This ensures an LTS line retains the identity of exactly when it started."。

ここで実務者が読み取るべき本当の情報は、表記法そのものではなく例のリストそのものです。次のLTSとして書かれているのは28.4、つまり2028年4月です。9.7 LTSが2026年4月なので、LTSの間隔がまた2年であるというシグナルです。ただし、そのリストのタイトルは"Upcoming Cadence Examples"であってロードマップの確約ではないので、2028年4月を契約のように受け取らないでください。それでも計画の観点で読み取れるメッセージははっきりしています — 今9.7 LTSに停泊すれば、次の停泊地まではおよそ2年かかります。

発表記事は保守用語も新しく一つ持ち出します。CPU(Critical Patch Update)はOracleの四半期ごとの定期セキュリティパッチサイクルであり、CSPU(Critical Security Patch Update)は四半期の合間に必要に応じて出る対象を絞ったセキュリティ更新です。投稿はCSPUを"strictly as-needed"と明記し、毎月の義務が生じるわけではないと明言しています。そして四半期パッケージがセキュリティ修正だけを含むわけではない点も指摘しています — LTSではセキュリティ修正とバグ修正を、革新リリースではそれに新機能まで含みます。

既存のラインはどうなるか。発表記事と表によれば、8.4と9.7 LTSは影響を受けず既存の番号体系をそのまま維持します。カレンダーバージョニングは9.7以降のリリースから適用されます。

そして26.7.0自体について、一つ正確にしておくべきことがあります。リリースノートのタイトルは"Changes in MySQL 26.7.0 (Early Access Release)"です。GAではなくEarly Accessです。新しいバージョン番号が付いた最初の成果物が本番リリースではないということなので、26.7という数字を見たからといってアップグレード計画を立てないでください。

互換性の面で一つ配慮はあります。26.7.0はmysql_version.hにMYSQL_PREVIOUS_LTS_VERSION("9.7.0")とMYSQL_PREVIOUS_LTS_VERSION_ID(90700)を追加しました(WL #17310)。バージョン番号が9から26へ飛ぶと、単純に数値を比較していたビルドスクリプトやコネクタが壊れる可能性がありますが、直前のLTSバージョンをヘッダーに明示することで系譜をたどれるようにしたわけです。逆に言えば、バージョン文字列をパースするコードを持っているなら、今それを一度確認する理由ができたということです。

MariaDBは5週間後に同じことをした

ここで面白いのは、MariaDBが事実上同じ構造を独立に運用しているという点です。

MariaDB Foundationの12.3 LTS発表は2026年5月29日付です。MySQL 9.7 LTSから5週間後です。発表文は"The first GA of the 12.3 series is 12.3.2"と記しています — MariaDBでは.2が最初のGAです(.0がpreview、.1がRC)。

その前の12.0、12.1、12.2はローリングリリースでした。MariaDBリリースモデル文書の一文は、Oracleのルールとほぼ瓜二つです。

There are no patch version releases of an innovation release after GA (except for emergency releases), instead users are supposed to upgrade to the next minor innovation release. In other words, innovation releases are rolling releases, one upgrades 11.3.2→11.4.2→11.5.2→11.6.2→11.7.2

同じ文書は"Approximately every fourth innovation release is a long-term support (LTS) release"と記し、MariaDB Foundationの保守ポリシーは"A new long-term release (LTS) of MariaDB Server is announced yearly"と記しています。四半期ごとにローリング、年1回LTSです。

整理すると、両陣営の構造はこう重なります。

MySQL    : 四半期ごとにInnovation  -> 約2年ごとにLTS   (次のInnovationが出ると支援終了)
MariaDB  : 四半期ごとにRolling     -> 毎年LTS         (次のRollingが出ると支援終了)

競合する2つの実装が同じ結論にたどり着いたということは、これがマーケティングではなく「メジャーなDBをオープンソースで保守するにはこの方法しかない」という工学的な収束に近いことを意味します。高速トラックと低速トラックを分離し、高速トラックには長期支援を約束しない、ということです。

分かれる点一つ目 — 支援期間8年対3年

構造が同じだからこそ、本当の違いが見えてきます。LTSを選んだとき何年もつかが、まったく違います。

MySQLマニュアルはこう記しています。

An LTS series follows the Oracle Lifetime Support Policy, which includes 5 years of premier support and 3 years of extended support.

5 + 3 = 8年です。先ほどのLifetime Support表の9.7の行(Premier Apr 2031、Extended Apr 2034)は、まさにこの計算通りです。

MariaDB Foundationの保守ポリシーは異なります。

MariaDB Community LTS binaries are released for 3 years after the GA date on mariadb.org/download

脚注まで読んで初めて全体像が完成します。脚注2は"For releases up to MariaDB 11.4, the binaries are released for 5 years after the GA date"と記しています。つまりコミュニティLTSバイナリの支援は11.4までは5年だったのが、それ以降3年に縮んだということです。脚注1はもう一つ緩衝材を付けます — "Critical and security fixes will be provided in source code releases for 2 additional years beyond Community LTS binary release period."。バイナリは3年ですが、致命的・セキュリティ修正はソースリリースとしてさらに2年出るという意味です。自分でビルドできるなら実質5年、配布パッケージに依存するなら3年です。この区別は実務上大きいです。

お金を払えば変わります。同じポリシー文書はEnterpriseバイナリについて"an extended release option maintained and supported for 5 and 8 years, respectively, after the GA date"と記しています。

	MySQL 9.7 LTS	MariaDB 12.3 LTS
無料で受けられる支援	Premier 5年 + Extended 3年 = 8年	コミュニティバイナリ3年(+ ソース限定の致命的・セキュリティ修正2年)
有料拡張	Sustaining(無期限、新規修正なし)	Enterprise 5年 / Extended 8年

一言でまとめると、コミュニティエディションだけを使う組織にとって、MySQL LTSは8年、MariaDB LTSは3年を与えます。「どちらもオープンソースのMySQL互換DB」という言葉が覆い隠す、最も実務的な違いがここにあります。

公平を期して付け加えると、MariaDBのLTSは毎年出るので停泊地そのものが頻繁に訪れます。8年に一度大きく越えるか、3年ごとに小さく越えるかの違いに近いです。どちらが安いかは組織のアップグレード筋力次第です。

一つ注意点。MariaDB Foundationの保守ポリシー表では、12.3のGA日付とEOLはこの記事を書いている時点でまだTBCのまま空欄です。そのため12.3の正確なEOL日付はここには書いていません。3年というのはポリシー文の話であり、日付が確定すればその表が一次情報源になります。

分かれる点二つ目 — リリースノートが示さなかったデフォルト値の変更

12.3 LTS発表文には"Important"と表示された項目がちょうど一つあります。

In MariaDB 12.3, innodb_snapshot_isolation defaults to ON

そしてこう付け加えています — "There probably is no better moment than when we release a new LTS."

まずこれが何の機能かから。MariaDB InnoDBシステム変数文書によれば、innodb_snapshot_isolationはInnoDB内でwrite/write競合を検出するスイッチです。オンになっていると、現在のread viewに存在しないレコードにロックをかけようとしたときER_CHECKREAD(エラー1020)が発生し、このエラーはデッドロックと同じ扱いでトランザクションがロールバックされます。デフォルトの分離レベルであるREPEATABLE READに影響します。文書の表現では、lost updateのような異常を防ぐため、スナップショット以降に並行トランザクションが変更した行へのUPDATE/DELETEを拒否する設計です。

正確性という点では正しい方向です。問題は、アプリケーション側がこれを知らないことです。昨日まで静かに成功していたUPDATEが、今はエラー1020でロールバックされ、リトライロジックがなければそのまま失敗として表面化します。LTSアップグレードで出会いたくない類の変化です。

ところがここで、文書と発表文が食い違います。同じシステム変数文書はデフォルト値をこう記しています。

Default Value: ON (>= MariaDB 11.6.2), OFF (<= MariaDB 11.6.1)

12.3ではなく11.6.2からONだというわけです。どちらが正しいかはソースを見れば決着がつきます。storage/innobase/handler/ha_innodb.ccでこの変数のデフォルト値引数をブランチごとに確認すると、こうなります。

MariaDB/server ブランチ別 innodb_snapshot_isolation デフォルト値
  11.4  -> FALSE
  11.5  -> FALSE
  11.6  -> TRUE
  11.7  -> TRUE
  11.8  -> TRUE
  12.2  -> TRUE
  12.3  -> TRUE
  main  -> TRUE

文書側が正しいです。デフォルト値は11.6で反転しており、12.3で変わったわけではありません。

そのため、LTSだけを追っている人からすると、実際の絵はこうなります。

11.4 LTS (OFF)  ->  11.8 LTS (ON)  ->  12.3 LTS (ON)
                     ^^^ ここですでに変わっていた

つまりこの変更は11.8 LTSの時点ですでに適用済みの状態で出荷されていました。そして11.8 LTS発表文ではsnapshot isolationは一度も言及されていません。整理するとこうなります。

11.4 → 11.8へ上げた組織はこの挙動変更に直面したのに、発表文では案内されませんでした。
11.4 → 12.3へ飛ぶ組織は、いまになって案内を受けます。ただし「12.3で変わる」という説明は正確ではありません。
11.8 → 12.3へ上げる組織にとって、この項目は実は変更点ではありません。すでにONだったからです。

発表文を責めたいわけではありません。むしろ遅くとも大きく表示したのは正しい判断で、11.4 LTSから移行する人にはまさに必要な警告です。要点は別のところにあります — リリースノートの「今回変わります」は、あなたのアップグレード経路ではなく作成者が想定した経路を基準に書かれています。LTSからLTSへ2段飛ばしすると、その間のローリングリリースで静かに反転していたデフォルト値が一度に到着します。ローリングリリースを飛ばすこと自体は合理的な運用判断ですが、飛ばした区間の変更ログまで飛ばしていいという意味ではありません。

実務的には、LTSアップグレードの前にSHOW GLOBAL VARIABLESを両方のバージョンで取ってdiffするほうが、発表文を読むより確実です。参考までに、この機能はまだ調整途中でもあります。MariaDBのJiraには、innodb_snapshot_isolationがオンの状態でのロック待ち・デッドロック関連のissue(MDEV-40182、MDEV-40092など)が、2026年になっても10.11 / 11.4 / 11.8 / 12.3をfix versionに付けて上がってきています。

では何をすべきか

整理すると、判断はシンプルです。

MySQL 8.0を使っているなら — 今がその時です。 Extended Supportは2026年4月に終わり、いまはSustaining Support、つまり新しいセキュリティ修正が出ない状態です。行き先は8.4 LTS(Extendedは2032年4月まで)か9.7 LTS(2034年4月まで)です。9.0でmysql_native_passwordが削除されたため、8.0 → 9.7のジャンプはクライアント・コネクタの認証方式の点検が先行する必要があります。その作業を今すぐ負担できないなら、8.4 LTSが正直な中間の寄港地です。

9.xの革新リリースを使っているなら — 9.7に上げて止まってください。 9.0から9.6まではすべて支援が終了しています。9.7は同じ系譜のLTSであり、LTSライン内ではin-placeアップグレードとダウングレードの両方が可能です。

26.7を本番に載せないでください。 Early Accessです。そしてカレンダーバージョニングの発表が示唆する次のLTSは2028年4月(28.4)です。今は9.7に停泊するのが正しい選択です。

革新トラックにあえて乗る必要はあるか? 大半の場合はありません。四半期ごとにメジャーアップグレードをテストして通せるCIと人員があり、特定の新機能が事業上どうしても必要なときにだけ価値があります。そうでなければLTSにとどまるのが、このモデルが意図する正常な経路です。Oracleのマニュアルもそう記しています。

MariaDBを使っているなら — 12.3 LTSが現在の停泊地です。 ただし支援期間を勘違いしないでください。コミュニティバイナリは3年で(11.4までの5年から縮んでいます)、その後2年は致命的・セキュリティ修正のみソースリリースで来ます。配布パッケージに依存しているなら、実質3年で計画するのが安全です。そして11.4以下から上がるなら、innodb_snapshot_isolationがONになることをステージングで必ず確認してください — エラー1020のリトライ経路がないアプリケーションなら、ここで壊れます。

MySQLとMariaDBのどちらにするか悩んでいるなら — 本稿はその答えを出しません。 ただし支援期間(コミュニティ8年対3年)とアップグレード頻度(2年対1年)は機能比較表にはあまり出てこないのに運用コストにはそのまま反映される項目なので、ベンチマークより先に計算しておく価値があります。

おわりに

バージョン番号が9.7から26.7へ飛んだのは表記法の変更ですが、その背景にある物語は表記法の話ではありません。

2024年から2026年にかけて、MySQLは四半期ごとに革新リリースを出し、各リリースは次が出た瞬間に支援が終わりました。その2年間の積み重ねが2026年4月21日に9.7 LTSとしてまとまり、同じ月に8.0がSustaining Supportへ格下げされ一つの時代が閉じました。MariaDBは5週間後、12.3 LTSでまったく同じ動きをしました。競合する2つの実装が同じリリース構造にたどり着いたのは偶然ではなく収束です。

そしてその下では、本当の違いは依然として分かれたままです。コミュニティエディション基準の支援8年対3年、エディションの境界線をコミュニティ側へ動かすOracleと、コミュニティバイナリの支援を5年から3年に縮めたMariaDB、そしてLTS間を飛び越えるときに静かに到着するデフォルト値の変更たち。

カレンダーバージョニングは「このリリースがいつ始まったか」を番号だけで教えてくれます。有用な改善です。しかし番号が教えてくれないこと — その間に何が削除され、どのデフォルト値が反転したか — は依然としてリリースノートを、時にはソースを開かないと分かりません。本稿でinnodb_snapshot_isolation一つを確認するのに、ブランチを7つ見なければならなかったように。