Oracle は、現在の四半期ごとの Critical Patch Update（CPU）スケジュールを補完する形で、MySQL のセキュリティ・アップデートを月次サイクルへ移行することを計画しています。
月次の Critical Security Patch Update（CSPU）は、重大なセキュリティまたは安定性の問題に対処するため、必要な場合にのみ提供されます。毎月必ずリリースされるわけではありません。
CSPU は、新機能ではなく、重大なセキュリティおよび安定性の修正に重点を置きます。最新のセキュリティベースラインを維持できるよう、MySQLのパッチ適用、テスト、リリース、デプロイの各プロセスを評価し、迅速化するための準備を進める必要があります。
前回の記事では、カレンダーバージョン、LTSリリース、イノベーションリリース、そして定期的なCPUおよびCSPUのリリース間隔を採用した、より予測しやすいMySQLリリースモデルへの移行について紹介しました。
残されていたのは、通常の四半期CPUリリースと、四半期リリースの間に提供されるCSPUリリースをバージョン番号でどのように区別するかという点でした。この形式が今回正式に決定しました。
バージョン形式
新しいカレンダーバージョン方式のMySQLリリースでは、CPUは3つの要素を使用し、CSPUでは4つ目の要素が追加されます。
| リリース種別 | バージョン形式 |
|---|---|
| LTS CPU / 四半期ごとのメンテナンス | YY.M.P |
| LTS CSPU / 月次セキュリティ脆弱性対応パッケージ（提供される場合） | YY.M.P.C |
| イノベーション CPU / 四半期ごとのイノベーションリリース | YY.M.0 |
| イノベーション CSPU / 月次セキュリティ脆弱性対応パッケージ（提供される場合） | YY.M.0.C |
| 位置 | 意味 |
|---|---|
YY | リリースラインが開始された年 |
M | リリースラインが開始された月（先頭に0は付けない） |
P | LTSリリースラインの四半期ごとのメンテナンス・パッケージ番号 イノベーションリリースラインでは、この値は常に0 |
C | 各リリースラインのセキュリティ脆弱性対応パッケージ番号 提供される場合にのみ使用 |
月には先頭の0を付けません。7月は7、10月は10、1月は1となります。
ルールはシンプルです。CPUは3つの要素を使用し、CSPUでは.1から始まる4つ目の要素を追加します。イノベーションリリースでは、3つ目の値は常に0のままです。
LTS リリースの番号付け
LTSリリースでは、最初の2つの要素がリリースラインを識別します。3つ目の要素は、四半期メンテナンス・パッケージごとに増加します。次の四半期リリースまでにCSPUが必要になった場合は4つ目の要素を使用し、次の四半期パッケージでは3つ目の要素を増やして、再び3要素の形式に戻ります。
| LTS ライン | CPU | 1 回目の CSPU（必要な場合） | 2 回目の CSPU（必要な場合） | 次の CPU |
|---|---|---|---|---|
| 8.4 LTS | 8.4.11 | 8.4.11.1 | 8.4.11.2 | 8.4.12 |
| 9.7 LTS | 9.7.2 | 9.7.2.1 | 9.7.2.2 | 9.7.3 |
将来のカレンダーバージョン方式のLTSラインにも同じ構造が適用されます。たとえば、2028年4月に予定されているLTSラインは28.4.0から始まります。CSPUが必要になった場合は28.4.0.1、28.4.0.2となり、次のCPUは28.4.1となります。
イノベーションリリースの番号付け
四半期ごとに提供される各イノベーションリリースは、それぞれ新しいカレンダーバージョン方式のリリースラインとして開始されます。3つ目の要素は常に0で、次のイノベーションリリースでは、この3つ目の要素を増やすのではなく、カレンダー部分が変更されます。
| イノベーションリリース | CPU |
|---|---|
| 2026 年 7 月 | 26.7.0 |
| 2026 年 10 月 | 26.10.0 |
| 2027 年 1 月 | 27.1.0 |
26.7 ラインで CSPU が必要になった場合は、 26.7.0.1、26.7.0.2 のようになります。次のイノベーション CPU は 26.10.0 であり、26.7.1 ではありません。
CSPU 番号は、該当するリリースラインに対して順番に割り当てられます。ある製品が CSPU バージョンを使用した場合、同じリリースラインの別の製品に対する次のCSPUでは、次に利用可能なCの値が使用されます。たとえば、MySQL Shell が 27.1.0.1 としてリリースされた場合、その後に同じラインで MySQL Server の CSPU が提供された場合 は 27.1.0.2 となります。
Microsoft MSI パッケージバージョン
ここまで説明してきたものは、MySQL製品のバージョンです。Microsoft MSIパッケージでは3つの数値要素を使用するため、MySQLのPとCの値をMSIの3つ目の要素にまとめます。
MSI の 3 つ目の位置 = 100 × P + C
CPU では、この計算では C を 0 として扱います。イノベーションリリースでは、P は常に 0 です。
| リリースタイプ | MySQL 製品バージョン | MSI パッケージバージョン |
|---|---|---|
| CPU | 8.4.11 | 8.4.1100 |
| CSPU（必要な場合） | 8.4.11.1 | 8.4.1101 |
| CPU | 9.7.2 | 9.7.200 |
| CSPU（必要な場合） | 9.7.2.1 | 9.7.201 |
| CPU | 28.4.0 | 28.4.0 |
| CSPU（必要な場合） | 28.4.0.1 | 28.4.1 |
この MSI 固有の表記によってMySQL 製品のバージョンが変わるわけではありません。Microsoft MSI パッケージメタデータ上で、そのバージョンをどのように表現するかを示しているだけです。
まとめ
| リリース ファミリー | CPU の動作 | CSPU の動作 |
|---|---|---|
| LTS | 四半期のパッケージごとに P が増加 | 必要に応じてCが追加され、その四半期サイクルで増加 |
| イノベーション | 四半期ごとに カレンダーの年/月が変わり、Pは常に0 | 必要に応じてCが追加され、そのカレンダー・リリースラインで増加 |
セキュリティ脆弱性対応パッケージが自動的に提供されるわけではありません。必要になった場合に、1から始まる4つ目の要素が追加されます。次のLTS CPUではPが増加し、次のイノベーションCPUでは新しいカレンダー・リリースラインが開始され、P = 0 のままとなります。
今後に向けて
より頻繁にセキュリティ・アップデートを提供することで、MySQLユーザーは最新のセキュリティ・ベースラインを維持しやすくなります。CPUおよびCSPUのバージョニングモデルにより、四半期メンテナンスのレベルと、その間に提供されたセキュリティ・アップデートを簡単に識別できます。
必要なアップデートを迅速に評価して適用できるよう、パッチ適用、テスト、リリース、デプロイの各プロセスを見直すことをお勧めします。
いつも MySQL をご利用いただき、ありがとうございます。