--- title: "Aurora MySQL 8.4とは？8.4.8の新機能とversion 3からのアップグレード手順・非互換の確認方法" url: "https://www.issoh.co.jp/tech/details/12354/" published: 2026-06-03 updated: 2026-10-09 categories: ["AWS"] publisher: "株式会社一創" --- # 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との差分をまとめた実装ガイド](/tech/details/17889/)で扱っています。 ### version 3と8.4の標準サポート終了日 AWSの[Aurora MySQLのリリースカレンダー](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.release-calendars.html)（2026年10月9日時点）から、移行計画に関わる版だけを抜き出しました。期限は更新されることがあるので、計画を確定する前にこのページで再確認してください。 | 版 | 互換MySQL | リリース日 | 標準サポート終了 | | --------- | ------- | ---------- | ---------- | | 8.4.8 | 8.4.8 | 2026-09-03 | 2028-03-31 | | 8.4.7 | 8.4.7 | 2026-05-21 | 2027-11-30 | | 3.13 | 8.0.45 | 2026-08-27 | 2027-08-27 | | 3.12 | 8.0.44 | 2026-02-17 | 2027-02-17 | | 3.11 | 8.0.43 | 2025-11-13 | 2026-11-13 | | 3.10（LTS） | 8.0.42 | 2025-07-31 | 2028-04-30 | | 3.04（LTS） | 8.0.28 | 2023-07-31 | 2026-10-31 | メジャー単位では、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の料金を東京リージョンの実額で計算した記事](/tech/details/17883/)にまとめています。 ## 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で増えた機能は、リリースノートに次のとおり載っています。 | 版 | 追加された機能 | 設定・確認の入口 | | ----- | -------------------------- | ------------------------------------------- | | 8.4.7 | パスワード有効期限・再利用制限 | `default_password_lifetime` ほか | | 8.4.7 | validate\_password コンポーネント | `aurora_enable_validate_password_component` | | 8.4.7 | メモリ不足による再起動の自動回避 | `aurora_enable_memory_management`（既定ON） | | 8.4.8 | マルチソースのbinlogレプリケーション | チャネルごとのストアドプロシージャ | | 8.4.8 | 遅延レプリケーション | binlogレプリカ側で秒数を指定 | | 8.4.8 | トランザクションのタイムアウト | `aurora_transaction_timeout` | | 8.4.8 | TLS 1.3の耐量子ハイブリッド鍵交換 | `Aurora_ssl_named_group` | 運用で効くのは `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で通っていた書き方がそのまま失敗するので、監視スクリプトや運用手順書に残っていると、アップグレード直後に気づくことになります。 | 8.4で構文エラー | 置き換え先（8.4.8で実行を確認） | | ---------------------------- | -------------------------------- | | `SHOW SLAVE STATUS` | `SHOW REPLICA STATUS` | | `SHOW MASTER STATUS` | `SHOW BINARY LOG STATUS` | | `SHOW SLAVE HOSTS` | `SHOW REPLICAS` | | `RESET MASTER` | `RESET BINARY LOGS AND GTIDS` | | `PURGE MASTER LOGS` | `PURGE BINARY LOGS` | | `CHANGE MASTER TO` | `CHANGE REPLICATION SOURCE TO` | | `START SLAVE` ／ `STOP SLAVE` | `START REPLICA` ／ `STOP REPLICA` | | `RESET SLAVE ALL` | `RESET REPLICA ALL` | 左列の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`）を新しく作り、置き換え先の値を入れてからアップグレードで指定します。 | version 3のパラメータ | 8.4での置き換え先 | | ------------------------------- | ----------------------------------------- | | `expire_logs_days` | `binlog_expire_logs_seconds` | | `default_authentication_plugin` | `authentication_policy` | | `validate_password_length` など | `validate_password.length` など（クラスターパラメータ） | 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 8.4.8（実測） | Aurora MySQL 8.4（公式） | | -------------------------- | ---------------- | ------------------------- | | `mysql_native_password` | 未ロード（ERROR 1524） | 有効・変更不可 | | `authentication_policy` | `*,,` | `*:caching_sha2_password` | | `require_secure_transport` | 0（OFF） | ON | | ヒストグラムの `AUTO UPDATE` | 受け付ける | 警告を出しMANUAL扱い | | `temptable_max_mmap` | 0 | ストレージの3%（上限4GiB） | | 多要素認証 | 設定可能 | 非対応 | ### 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の仕組みと導入手順](/tech/details/6798/)）。 ## version 3から8.4へのアップグレード手順 ### インプレース・スナップショット復元・Blue/Greenの選び方 8.4へは、サポート中のversion 3ならどの版からでも上げられます。version 2からの直接アップグレードはできないため、いったんversion 3を経由します。方式は3つです。 | 方式 | 停止 | 戻し方 | 向いている構成 | | ---------- | ------------- | ------------------ | ---------------------------------- | | インプレース | アップグレード中は停止 | 開始時の自動スナップショットから復元 | 停止枠を取れる本番・検証環境 | | スナップショット復元 | 新クラスターへ切替 | 元クラスターが残る | RDS for MySQLやオンプレからbinlogを受けている構成 | | Blue/Green | 切替時のみ（通常1分未満） | 切替前なら破棄するだけ | 停止を最小にしたい本番 | インプレースでは、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` に残します。本番でいきなり取り消されないよう、先にクローンでリハーサルします。クローンを作ったらすぐにアップグレードを始めてください。クローンを放置すると裏でクリーンアップ処理が進み、本番を上げるときの再現になりません。 | チェック名 | レベル | 見つけるもの | | ----------------------------------- | --- | -------------------------------- | | `partitionsWithPrefixKeys` | エラー | プレフィックス索引の列でKEYパーティション | | `columnDefinition` | エラー | FLOAT・DOUBLEのAUTO\_INCREMENTなど | | `auroraUnsupportedPluginsCheck` | エラー | 8.4で使えないプラグイン | | `auroraUnsupportedComponentsCheck` | エラー | 8.4で使えないコンポーネント | | `deprecatedDefaultAuth` | 警告 | 既定プラグインが mysql\_native\_password | | `foreignKeyReferences` | 警告 | 一意でないキーを参照する外部キー | | `auroraValidatePasswordPluginCheck` | 警告 | validate\_password プラグイン | 警告はアップグレードを止めませんが、外部キーの警告を放置すると、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で作成する手順](/tech/details/17844/)で扱っています。 ## 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からの移行手順](/tech/details/17889/) - [Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説](/tech/details/15447/) - [MySQL 5.7と8.0の違いを比較｜性能・機能・認証とEOL後の移行先](/tech/details/4251/) - [AWS RDSの料金を東京リージョンの実額で計算する：延長サポート課金と単価の下げ方](/tech/details/17883/) --- 出典: [Aurora MySQL 8.4とは？8.4.8の新機能とversion 3からのアップグレード手順・非互換の確認方法]()（株式会社一創）