2026.05.22

Aurora MySQL 8.4 が GA。Aurora 利用者目線でリリースノートを読み解く

saratogax

記事内に商品プロモーションを含む場合があります

2026 年 5 月 21 日、AWS から Aurora MySQL 8.4 (バージョン 8.4.7) のリリースノートが公開されました。

MySQL 8.4 は LTS (長期サポート) 版であり、Aurora MySQL 側でも長らく v3 系 (MySQL 8.0 互換) が続いていたため、待望のメジャーバージョン更新となります。

本記事では、AWS 公式のリリースノートをAurora を業務で運用している立場から読み解き、移行検討の際に押さえておきたいポイントを整理します。

Aurora MySQL 8.4.7, May 21, 2026 (AWS 公式リリースノート)

Contents

リリース概要
- バージョン採番の刷新
注目ポイント①: 認証方式 (mysql_native_password の扱い)
- Aurora MySQL の現場で起きること
注目ポイント②: 自動メモリ管理
注目ポイント③: パスワード管理機能と validate_password
v3 から v8.4 へのアップグレード手段
v3 系最新 (3.12.0) からの主な改善点
- 可用性関連
- 一般改善
移行前に確認しておきたいことリスト
まとめ

リリース概要

まずはリリースノートに記載されている基本情報を整理します。

項目	内容
Aurora MySQL バージョン	8.4.7
互換 MySQL バージョン	MySQL 8.4.7
リリース日	2026 年 5 月 21 日
アップグレード元	サポート中の Aurora MySQL v3 クラスター
アップグレード手段	in-place / snapshot restore with upgrade / Blue/Green Deployments

※表は横スクロールできます

バージョン採番の刷新

これまでの Aurora MySQL は v1 (MySQL 5.6 互換) → v2 (5.7 互換) → v3 (8.0 互換) と独自のメジャーバージョンで採番されていました。

今回からは互換元の MySQL バージョンをそのままメジャー番号として使う形に変わり、Aurora MySQL 8.4.7 という採番になっています。

v3 系の最新バージョンは 3.12.0 で、リリースノートの Improvements セクションも「Aurora MySQL 3.12.0 と比べてどう変わったか」という形でまとめられています。

注目ポイント①: 認証方式 (mysql_native_password の扱い)

MySQL 8.4 で最も周知されている変更が、mysql_native_password プラグインがデフォルトで無効化された (disabled by default) ことです。

注意したいのは、デフォルト認証プラグインは MySQL 8.0 の時点で既に caching_sha2_password に切り替わっていたという点です。

つまり 8.4 で起きるのは「デフォルトの変更」ではなく、古いプラグインを使い続けるという選択肢がなくなる方向の変更です。

Aurora MySQL の現場で起きること

Aurora MySQL v3 (MySQL 8.0 互換) で運用しているクラスターをアップグレードする際、既存ユーザーが mysql_native_password で作成されたまま残っているケースが現場ではよくあります。

RDS for MySQL の公式ブログでは「8.0 から 8.4 にアップグレードした場合、既存ユーザー (マスターユーザー含む) は引き続き mysql_native_password を使い続ける」と説明されており、Aurora MySQL のアップグレードでも同様の挙動が想定されます。

「アップグレード直後は動いていたが、ユーザー追加や接続経路の見直しのタイミングで急に弾かれる」といった事故を避けるため、アップグレード前に既存ユーザーの認証プラグインを棚卸ししておくのがおすすめです。

確認は単純な SQL で行えます。

SELECT user, host, plugin FROM mysql.user;

アプリケーション側でも、ドライバ・コネクタが caching_sha2_password に対応しているか (たとえば古い MySQL Connector や、SSL なしでの接続に依存していないか) を合わせて確認しておきます。

注目ポイント②: 自動メモリ管理

個人的に Aurora MySQL 8.4 で一番大きな運用面の変化だと感じたのが、自動メモリ管理の導入です。

リリースノートには次のように記載されています。

新しいパラメータ aurora_enable_memory_management が追加された
デフォルトは ON
ON のとき、Aurora が OOM (out-of-memory) による再起動を回避するためのメモリ回収を自動で行う
ON のとき、従来の aurora_oom_response パラメータは無視される
手動で挙動を制御したい場合は aurora_enable_memory_management を OFF にする

これまで Aurora MySQL では、メモリ逼迫時の挙動を aurora_oom_response で細かく制御する運用が知られていました。

v8.4 では、既存のチューニングがそのままでは効かなくなる可能性があるため、移行時にはパラメータグループの差分レビューが必要です。

とくに「OOM 時に特定のセッションを優先して殺す」「再起動より接続切断を優先する」といったポリシーを aurora_oom_response でチューニングしていたチームは、aurora_enable_memory_management を OFF にして従来挙動を維持するのか、あるいは自動管理に任せるのかを明示的に意思決定しておくのがよさそうです。

注目ポイント③: パスワード管理機能と validate_password

MySQL 8.0 系で導入されていた以下の機能群が、Aurora MySQL 8.4 でも有効化できるようになりました。

パスワード管理機能 (有効期限、履歴、再利用制限など) をクラスターパラメータグループから設定可能に
validate_password コンポーネントによるパスワード強度ポリシーの強制 (aurora_enable_validate_password_component パラメータで有効化)

業務利用の Aurora ではアプリケーションユーザーのパスワードを IaC や Secrets Manager 経由で配布しているケースが多く、パスワード有効期限を強制すると運用が回らなくなることもあります。

使うかどうかはチームのセキュリティ要件次第ですが、「パラメータグループから設定できる」という事実だけは押さえておくと、監査・ガバナンス系の要件が降ってきたときの選択肢になります。

v3 から v8.4 へのアップグレード手段

リリースノートでは、サポート中の Aurora MySQL v3 クラスターから 8.4.7 へのアップグレード手段として、以下の 3 つが案内されています。

手段	特徴	向いているケース
in-place upgrade	既存クラスターを直接アップグレード	エンドポイントを変えずに切り替えたい / 検証環境
snapshot restore with upgrade	スナップショットからの復元時にバージョンを上げる	事前に新バージョンでの動作確認をしたい
Blue/Green Deployments	本番と同等の Green 環境を用意し、ステージング後に切替	本番のダウンタイムを最小化したい

※表は横スクロールできます

業務での Aurora 運用では、Blue/Green Deployments を使った段階移行が現実的な選択肢になることが多いはずです。

Green 側で v8.4.7 を立ててアプリケーションの結合確認まで実施した上でスイッチオーバーすれば、認証方式や自動メモリ管理の挙動変化を本番影響なく検証できます。

v3 系最新 (3.12.0) からの主な改善点

リリースノートの Improvements セクションは「Availability improvements」と「General improvements」の 2 つに分かれています。

業務利用で影響しそうなものを抜粋します。

可用性関連

仮想列に対するインデックスを持つテーブルの undo レコードをパージ中に writer が再起動を繰り返す問題を修正
新規クラスター作成が失敗し、削除・再作成を要するケースを修正
グローバルデータベースのスイッチオーバー時、一時テーブルのクリーンアップ中に writer が再起動して切替が長引く問題を修正
Aurora 物理レプリケーションが、reader 側でマルチスレッド適用になり性能改善
binlog 有効時に writer が大きなトランザクションを commit すると read replica が再起動する問題を修正
Aurora Serverless v2 のスケーリング中、InnoDB バッファプールのリサイズ遅延でインスタンスが応答しなくなり再起動する問題を修正
OOM 回避メカニズム内部での再起動を修正
writer の undo log 強制パージ中に reader を再起動すると、reader が再起動を繰り返す問題を修正
Parallel Query を使うサブクエリのクローズ漏れによる reader 再起動を修正

一般改善

Enhanced Binlog 有効時、replica_preserve_commit_order が正しく尊重されるよう commit 順序を修正 (非依存トランザクション間の順序のみで、データ整合性自体には影響なし)
ORDER BY DESC + 範囲比較 + LIMIT で結果が昇順で返る問題を修正
writer の INPLACE オンライン DDL 中、reader 側で「ERROR 1146 (table not found)」が出る問題を修正
aurora_in_memory_relaylog の固定キャッシュサイズ (128MB) を超える binlog イベント処理時のレプリケーションエラーを修正
Prepared Statement で IN + パラメータ値を使う場合に最適化プランが劣化する問題を修正
Parallel Query 有効時、hash join のメモリが上限を超えると結果が不正になる問題を修正
Zero-downtime patching / restart 時のインスタンス可用性遅延を修正
SRID 注釈付きカラムで Z-order spatial index を使った GIS クエリでのエンジン再起動を修正

とくに物理レプリケーションのマルチスレッド適用は、リードレプリカの遅延に悩まされてきた環境では効いてきそうな改善です。

また、Parallel Query + hash join での結果不正はデータの正しさに直結するバグなので、Parallel Query をプロダクションで使っているチームは要チェックです。

移行前に確認しておきたいことリスト

認証プラグインの棚卸し: SELECT user, host, plugin FROM mysql.user; で mysql_native_password を使うアカウントが残っていないか確認
アプリ側ドライバの対応状況: caching_sha2_password サポート / SSL 必須化の影響を確認
パラメータグループの差分: aurora_oom_response をチューニングしていないか、していた場合 aurora_enable_memory_management をどうするか決める
Parallel Query / Enhanced Binlog の利用状況: 修正された不具合が現環境で踏まれていないかも合わせて確認
アップグレード手段の選定: ダウンタイム要件と Green 環境のコスト感を踏まえて Blue/Green / in-place を選ぶ

まとめ

Aurora MySQL 8.4.7 のリリースで、ようやく Aurora 側でも MySQL 8.4 LTS が選べるようになりました。

注目したいポイントを 3 つに絞ると以下の通りです。

認証方式: デフォルトが変わったのではなく、mysql_native_password が既定で無効化された方向の変化。既存ユーザーの棚卸しが鍵
自動メモリ管理: aurora_enable_memory_management がデフォルト ON で、従来の aurora_oom_response は無視される
アップグレード経路: in-place / snapshot / Blue/Green の 3 通り。本番は Blue/Green が現実解

RDS for MySQL 8.0 のサポート終了 (2026 年 7 月 31 日) と合わせて、Aurora 側もこのタイミングで移行スケジュールを立て直しておくとよさそうです。

#Aurora #aws #MySQL #rds #データベース