Aurora MySQL 8.4とは？8.4.8の新機能とversion 3からのアップグレード手順・非互換の確認方法

Aurora MySQL 8.4は、MySQL 8.4 LTSと互換のAurora MySQLの新しいメジャーバージョンです。最初のマイナー版8.4.7が2026年5月21日に、続く8.4.8が2026年9月3日に一般提供されました。version 3（MySQL 8.0互換）からはインプレースで上げられますが、旧レプリケーション構文や削除されたパラメータを使っていると、アップグレード後にSQLや接続が止まります。この記事では、AWSの公式ドキュメントとリリースノートで版とサポート期限を確かめ、MySQL 8.4.8を手元で起動して止まるSQLを実測しました。そのうえで、アップグレード方式の選び方と事前チェックの読み方を説明します。

まとめ：Aurora MySQL 8.4へ上げる前に決めること

• 現行の最新は8.4.8（2026年9月3日・標準サポートは2028年3月31日まで）。8.4系全体の標準サポートは2032年4月までです。
• version 3は2028年4月30日で標準サポートが終わり、翌5月1日からRDS延長サポートの課金が始まります。3.04 LTSは2026年10月31日、3.11は2026年11月13日に先に切れます。
• 止まるのは主に4種類：SHOW SLAVE STATUS などの旧レプリケーション構文、expire_logs_days などの削除パラメータ、非一意キーを参照する外部キーの新規作成、新しい予約語（MANUAL・QUALIFY など）を引用符なしで使った識別子です。
• Aurora 8.4ではコミュニティ版と違い mysql_native_password が有効のままなので、既存ユーザーはアップグレード後も接続できます。一方で require_secure_transport が既定でONになり、TLSを使わない接続は拒否されます。
• 方式は、停止を許容できるならインプレース、切替を1分程度に収めたいならBlue/Greenデプロイです。どちらの前にも、クローンで事前チェックを通しておきます。

Aurora MySQL 8.4の版番号とサポート期限

8.4.mysql_aurora.8.4.8 という表記と版の確かめ方

version 3までは 8.0.mysql_aurora.3.10.1 のように、MySQLの版とAuroraの版が別々の番号でした。8.4からは番号が単純になり、エンジンバージョンは 8.4.mysql_aurora.8.4.8、Auroraの版は 8.4.8 と、MySQL互換の版とそのままそろいます。8.4は「メジャー.マイナー」の2段で、利用者から見えるパッチ番号はありません。

-- 接続中のクラスターの版を確かめる（8.4系なら 8.4.8 のように返る）
SELECT aurora_version(), @@aurora_version, VERSION();

Auroraの版の全体像や、version 3の番号の読み方はAurora MySQLの版の確認とMySQL 8.0との差分をまとめた実装ガイドで扱っています。

version 3と8.4の標準サポート終了日

AWSのAurora MySQLのリリースカレンダー（2026年10月9日時点）から、移行計画に関わる版だけを抜き出しました。期限は更新されることがあるので、計画を確定する前にこのページで再確認してください。

メジャー単位では、version 3が2028年4月30日に標準サポートを終え、2028年5月1日からRDS延長サポートの課金が始まります（延長サポートの終了は2029年7月31日）。8.4系はコミュニティのMySQL 8.4と同じ2032年4月までです。3.08と3.09はすでに2026年8月31日で標準サポートが終わっています。延長サポートの単価はRDSの料金を東京リージョンの実額で計算した記事にまとめています。

8.4.7と8.4.8で追加された機能

AWSは「8.4は最新のversion 3と同じAurora機能を持つ」と説明しており、例外として挙げているのはFast insertが8.4で使えないことだけです。ただし、ゼロETL統合の対応表（2026年10月9日時点）にAurora MySQLの対応元として載っているのはversion 3だけなので、利用中なら上げる前に確認が要ります。8.4で増えた機能は、リリースノートに次のとおり載っています。

運用で効くのは aurora_transaction_timeout です。放置されたトランザクションがInnoDBのパージを止めて性能が落ちる事故を、秒数の上限で防ぎます。既定値は0（無効）で、クラスター・インスタンス・セッションの単位で設定でき、読み取り専用を含むInnoDBトランザクションが対象です。上限を超えると実行中のクエリは中断されてロールバックされ、アイドル中の場合は接続が切られます。大きな更新ほどロールバックに時間がかかるため、値は通常のバッチの所要時間より十分長く取ります。遅延レプリケーションは、誤った DROP TABLE や DELETE がレプリカへ届く前に気づく時間を作る機能です。耐量子鍵交換（X25519MLKEM768・SecP256r1MLKEM768）は、対応クライアントなら設定なしで使われ、SHOW STATUS LIKE 'Aurora_ssl_named_group'; で交渉結果を確かめられます。

MySQL 8.0から8.4で止まるSQLと設定（MySQL 8.4.8で実測）

AuroraのDBはここでは起動していないため、Aurora 8.4.8と同じ版のMySQL Community Server 8.4.8を手元で起動し、version 3（MySQL 8.0互換）で通っていた書き方を流しました。ここで扱う構文と変数は、AWSが「8.4で削除された」と明記しているものです。

旧レプリケーション構文と置き換え先

SHOW SLAVE STATUS と SHOW MASTER STATUS は、どちらも ERROR 1064 (42000) の構文エラーになりました。version 3で通っていた書き方がそのまま失敗するので、監視スクリプトや運用手順書に残っていると、アップグレード直後に気づくことになります。

左列の9文はすべて8.4.8で ERROR 1064 になり、右列の文はすべて実行できました。ただしAuroraで外部のMySQLからbinlogレプリケーションを組む場合、AWSの手順は CHANGE REPLICATION SOURCE TO を直接打つのではなく、mysql.rds_set_external_source などのストアドプロシージャを使います。この表は、自前の監視スクリプトや手順書に残った構文を直すためのものです。

ステータス変数も変わります。Com_show_slave_status は8.4.8では存在せず、Com_show_replica_status だけが返りました。CloudWatchのカスタムメトリクスや監視エージェントがこの名前を読んでいると、エラーにならずに値が取れなくなるだけなので、構文エラーより気づきにくい点に注意してください。AWSもアップグレード後の作業として、この種の変数を使うアラームと自動化の更新を挙げています。

削除されたパラメータ

SELECT @@expire_logs_days; と SELECT @@default_authentication_plugin; は、どちらも ERROR 1193 (HY000) Unknown system variable でした。カスタムパラメータグループにこれらの値を入れている場合は、そのまま8.4へ持ち込めません。8.4用のパラメータグループ（既定は default.aurora-mysql8.4）を新しく作り、置き換え先の値を入れてからアップグレードで指定します。

CloudFormationやTerraformのテンプレートでパラメータグループを管理している場合は、削除済みパラメータの参照を外すまでデプロイが通りません。AWSのアップグレード後の作業一覧にも、テンプレートの更新が含まれています。

スキーマとアプリのSQLで止まる4つの書き方

スキーマとアプリのSQLで止まる箇所を、実測結果ごとに並べます。

-- 新しいセッションで実行（restrict_fk_on_non_standard_key は既定のON）
CREATE DATABASE t84;
USE t84;
CREATE TABLE p (id INT PRIMARY KEY, code INT, KEY(code));
CREATE TABLE c (id INT PRIMARY KEY, code INT, FOREIGN KEY (code) REFERENCES p(code));
-- ERROR 6125 (HY000): Failed to add the foreign key constraint.
--   Missing unique key for constraint 'c_ibfk_1' in the referenced table 'p'

CREATE TABLE f (id FLOAT AUTO_INCREMENT PRIMARY KEY);
-- ERROR 1063 (42000): Incorrect column specifier for column 'id'

LOCK TABLES p LOW_PRIORITY WRITE;
-- ERROR 1064 (42000): ... near 'LOW_PRIORITY WRITE'

CREATE TABLE kw (manual INT);
-- ERROR 1064 (42000): ... near 'manual INT)'
CREATE TABLE kw3 (`manual` INT, `qualify` INT);
-- Query OK（バッククォートで囲めば通る）

外部キーは、親テーブルの一意でないキーを参照する新規作成だけが既定で拒否されます。既存の外部キーはそのまま動きます。restrict_fk_on_non_standard_key をOFFにすると作成できますが、8.4.8では「将来のリリースで削除する」という警告（Warning 6124）が出ました。OFFは移行期間の逃げ道と考え、親側に一意キーを足して直すほうを選んでください。

予約語は、8.4で増えた MANUAL と QUALIFY を列名にすると構文エラーになりました。AWSは、アップグレード前にスキーマとオブジェクト定義の中で新しい予約語が引用符なしで使われていないかを確かめるよう求めています。

Aurora MySQL 8.4とコミュニティ版MySQL 8.4の違い

「MySQL 8.4の変更点」を解説する記事の多くはコミュニティ版を前提にしています。Aurora 8.4では既定値がいくつか異なり、そのまま当てはめると判断を誤ります。

mysql_native_password ユーザーの扱いとマスターユーザーの切り替え

コミュニティ版8.4.8で IDENTIFIED WITH mysql_native_password のユーザーを作ると、ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded で失敗しました。Aurora 8.4ではこのプラグインが有効のまま固定されており、version 3から上げた既存ユーザーは接続を続けられます。authentication_policy に指定できるのは *:caching_sha2_password（既定）と *:mysql_native_password の2値だけです。

ただしAWSはこのプラグインを非推奨としており、移行を勧めています。注意したいのはマスターユーザーです。8.4ではコンソール・CLIからのパスワードリセットや、Secrets Managerのローテーションのたびに、その時点の authentication_policy のプラグインへ切り替わります。古いドライバが caching_sha2_password に対応していないと、ローテーションをきっかけにマスターユーザーだけ接続できなくなります。

-- 移行対象のユーザーを洗い出す
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

-- 1ユーザーずつ caching_sha2_password へ移す
ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY '新しいパスワード';

require_secure_transport の既定ONとアプリ側のTLS設定

Aurora 8.4の既定パラメータグループでは require_secure_transport がONで、TLSを使わない接続は拒否されます。version 3で既定のパラメータグループを使っていたクラスターをインプレースで上げると、アップグレード後は自動的に default.aurora-mysql8.4 で起動します。そのため、アプリ側がTLSを有効にしていなかった場合、アップグレードを境に接続が失敗します。

対処は、アプリのDB接続設定でTLSを有効にし、RDSのCA証明書バンドルを指定することです。すぐに直せない場合は、カスタムパラメータグループで一時的にOFFにします。あわせて、TLS 1.2未満と弱い暗号スイートも使えなくなるため、古いクライアントライブラリはこの段階で更新しておきます。RDS Proxy経由の構成では、Proxyの監視ユーザー rdsproxyadmin が8.4.7以降は保護ユーザーになり、変更や削除ができなくなります。version 3で同じ名前のユーザーを自分で作っていた場合は、上げる前に名前を変えておいてください（RDS Proxyの仕組みと導入手順）。

version 3から8.4へのアップグレード手順

インプレース・スナップショット復元・Blue/Greenの選び方

8.4へは、サポート中のversion 3ならどの版からでも上げられます。version 2からの直接アップグレードはできないため、いったんversion 3を経由します。方式は3つです。

インプレースでは、Auroraがアップグレードの最初にクラスターの手動スナップショットを作ります。手動スナップショットの上限に達していても作られ、削除するまで残ります。Aurora以外（RDS for MySQLやオンプレのMySQL）からbinlogレプリケーションを受けているクラスターはインプレースで上げられないため、スナップショット復元を使います。グローバルデータベースは、modify-global-cluster でプライマリとセカンダリを同時に上げます。

Blue/Greenの切替タイムアウトは既定300秒で、30〜3,600秒の範囲で変えられます。Blue/Green全般の制約に加えて、Aurora MySQL固有の制約が4つあります。ソースのクラスターに tmp という名前のデータベースを置けないこと（置いてもグリーン側へコピーされないので、事前に名前を変えるか削除する）、外部のbinlogレプリカになっているクラスターは使えないこと、Backtrackを有効にしたクラスターでもグリーン側はBacktrackなしで作られること、AWS JDBC Driver for MySQLに対応していないことです。インプレースの場合も、アップグレード前の時点へはBacktrackで戻れません。

クローンでの事前チェックのリハーサル

Auroraはアップグレードの開始時に事前チェックを自動で実行し、エラーが1件でもあればアップグレードを取り消して、内容を upgrade-prechecks.log に残します。本番でいきなり取り消されないよう、先にクローンでリハーサルします。クローンを作ったらすぐにアップグレードを始めてください。クローンを放置すると裏でクリーンアップ処理が進み、本番を上げるときの再現になりません。

警告はアップグレードを止めませんが、外部キーの警告を放置すると、8.4へ上げた後に同じ形の外部キーを新しく作れなくなります。旧レプリケーション構文と予約語はアプリ側のSQLの問題で、事前チェックでは見つかりません。先に挙げた実測の構文を、リポジトリと運用スクリプトで検索しておきます。

AWS CLIでのアップグレード

公式の手順では、modify-db-cluster に版と --allow-major-version-upgrade を指定します。カスタムパラメータグループを使っている場合は、8.4用に作ったグループ名をクラスター用とインスタンス用それぞれで渡します。

aws rds modify-db-cluster \
  --db-cluster-identifier my-cluster \
  --engine-version 8.4.mysql_aurora.8.4.8 \
  --allow-major-version-upgrade \
  --db-cluster-parameter-group-name my-aurora-mysql84-cluster \
  --db-instance-parameter-group-name my-aurora-mysql84-instance \
  --apply-immediately

進み具合はRDSコンソールのイベントで追えます。書き込みインスタンスのクリーンシャットダウン中は、未完了トランザクションのロールバックやundoのパージが15分ごとに進捗イベントとして記録されます。ここが長引くほど停止時間も延びます。上げる前に長いトランザクションが走っていないことを確かめてから始めてください。アップグレード後は、残っている mysql_native_password ユーザーの移行、監視とテンプレートの更新を片づけます。クラスターの作成から接続確認までの基本操作はAuroraのクラスターをCLIで作成する手順で扱っています。

8.4へ上げる時期の判断

判断の起点はサポート期限です。いま3.04 LTSや3.11で動いているなら、2026年中に標準サポートが切れるので、何もしない選択肢はありません。マイナーアップグレードは今より高い3.xへしか進めないため、行き先は今の版で変わります。3.04 LTSなら3.10 LTS（2028年4月30日まで）・3.12以降・8.4のいずれか、3.11以降なら3.12以降か8.4です。3.11から3.10 LTSへは戻れません。

新規構築と、ドライバがcaching_sha2_passwordとTLSに対応済みのアプリは8.4へ上げるべきです。version 3はどの版でも2028年4月30日に標準サポートが終わるので、3.10へ寄せても約1年半後にもう一度メジャーアップグレードが回ってきます。8.4.8なら2028年3月31日まで、8.4系全体なら2032年4月まで使えます。

8.4を見送り、version 3の範囲で期限を延ばしたほうがよいのは、次の条件のどれかに当てはまる場合です。3.04 LTSからなら3.10 LTS、3.11以降からなら3.12・3.13が受け皿になります。

• アプリや運用スクリプトに旧レプリケーション構文、新しい予約語の列名、非一意キーへの外部キーが多く残っていて、改修が今の版の期限に間に合わない。
• TLSに対応していない古いクライアントやバッチが接続していて、ライブラリの更新に時間がかかる。
• Fast insertに依存した一括投入の性能要件がある（8.4では使えない）。
• Amazon RedshiftやSageMakerへのゼロETL統合を使っている。2026年10月9日時点の公式の対応表には、Aurora MySQLの対応元としてversion 3（3.05.2以降）の列しかない。

反対に、改修の見込みが立たないまま8.4へ上げ、設定のOFFで乗り切る方法は勧めません。restrict_fk_on_non_standard_key のOFFは、8.4.8自身が「将来のリリースで削除する」と警告を出す一時しのぎです。require_secure_transport のOFFはAWSが代替策として案内している設定ですが、DBへの通信が暗号化されない状態に戻すことになります。どちらも、アプリ側の改修を終えるまでの期限付きの措置として扱ってください。

よくある質問

Aurora MySQL 8.4からversion 3へダウングレードできますか？

同じクラスターのまま版を下げる手段はありません。インプレースアップグレードでは、Auroraが開始時に手動スナップショットを作るので、そこから元の版のクラスターを新しく復元して戻します。アップグレード後に書き込んだデータはそのスナップショットに含まれないため、切り戻しの判断は書き込みを再開する前に済ませます。Blue/Greenなら、切替前にグリーン側を破棄すれば元のままです。

mysql_native_password のユーザーはAurora 8.4で接続できなくなりますか？

接続できます。コミュニティ版MySQL 8.4ではプラグインが既定で無効ですが、Aurora 8.4では有効のまま変更できない設定になっており、version 3から上げた既存ユーザーはそのまま使えます。新しく作るユーザーは既定で caching_sha2_password になります。マスターユーザーは、パスワードのリセットやSecrets Managerのローテーションのたびに、その時点の authentication_policy で指定したプラグインへ切り替わります（既定なら caching_sha2_password、*:mysql_native_password にしていれば mysql_native_password）。

Aurora MySQL version 2から8.4へ直接上げられますか？

できません。AWSは、version 2から8.4への直接アップグレードに対応していないと明記しています。version 2（MySQL 5.7互換）はまずversion 3へ上げ、そのうえで8.4へ上げます。version 2の延長サポートは2026年12月1日から3年目の料金に入るため、2段階分の検証期間を見込んで計画します。

Aurora MySQL 8.4にLTS版はありますか？

2026年10月9日時点では、Aurora MySQLのLTSとして指定されているのは3.04系と3.10系だけで、8.4系にはまだありません。AWSはAuroraのLTSを、各メジャー版のリリースから12か月以内に出すとしています。この方針どおりなら、8.4.7の公開（2026年5月21日）から数えて2027年5月頃までに出ることになります。なお、互換元のMySQL 8.4自体はOracleのLTSリリースです。

Aurora Serverless v2やグローバルデータベースでも8.4を使えますか？

使えます。AWSは8.4が最新のversion 3と同じAurora機能を持つと説明しており、例外はFast insertだけです。Serverless v2はversion 3以降が対象で、グローバルデータベースは modify-global-cluster でまとめてアップグレードします。グローバルデータベースのメジャーアップグレード中はカスタムパラメータグループを指定できないため、各リージョンで8.4用のグループを作っておき、アップグレード後に手動で当てます。

関連記事

• Aurora MySQLの実装ガイド：版の確認、MySQL 8.0との差分とRDSからの移行手順
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説
• MySQL 5.7と8.0の違いを比較｜性能・機能・認証とEOL後の移行先
• AWS RDSの料金を東京リージョンの実額で計算する：延長サポート課金と単価の下げ方