Amazon Aurora MySQL 8.4.8 が GA したので 8.4.7 からの変更点を確認してみた
はじめに
2026年9月3日に、Amazon Aurora MySQL 8.4.8のGAがWhat's Newで発表されました。
2026年5月にGAとなったAurora MySQL 8.4の初回リリース、バージョン8.4.7については、TLS接続の必須化を中心に、Aurora MySQL 8.0からの接続・認証まわりの変更点を以下の記事で紹介しました。
今回は、東京リージョンでAurora MySQL 8.4.8のクラスターを実際に起動し、8.4.7からの主な変更点を確認してみます。
検証内容
確認は AWS CLI と RDS Data API で行いました。
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| エンジンバージョン | 8.4.mysql_aurora.8.4.8 |
| インスタンスクラス | db.r8g.large |
| SQL 実行経路 | RDS Data API |
| クラスターパラメータグループ | aurora848-verify-binlog-row（binlog_format=ROW） |
提供バージョンとクラスター作成
東京リージョンでの提供状況と、8.4.7 からのアップグレード経路を確認しました。
aws rds describe-db-engine-versions \
--engine aurora-mysql \
--engine-version 8.4 \
--region ap-northeast-1
8.4.7 のエントリから、アップグレード先の部分を抜粋します。
"EngineVersion": "8.4.mysql_aurora.8.4.7",
"ValidUpgradeTarget": [
{
"Engine": "aurora-mysql",
"EngineVersion": "8.4.mysql_aurora.8.4.8",
"Description": "Aurora MySQL 8.4.8 (compatible with MySQL 8.4.8)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": false,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsLocalWriteForwarding": true,
"SupportsIntegrations": true
}
],
東京リージョンでは 8.4.8 のステータスは available でした。8.4.7 のアップグレード先は 8.4.8 の 1 件だけで、マイナーバージョンアップグレードとして提供されています。8.4.8 のエントリにはアップグレード先が 1 件もなく、8.4.8 が現時点の最新でした。
8.4.7 と 8.4.8 のエントリを比べると、アップグレード先の一覧以外に違いはありませんでした。対応するエンジン機能、エクスポートできるログ種別、選択できる CA 証明書は同じです。ただし 8.4.8 で追加された機能はこのメタデータに現れないため、以降はサーバー側で確認しています。
クラスター作成時に指定するバージョン文字列は 8.4.mysql_aurora.8.4.8 です。8.4.8 だけでは指定できません。8.4.7 でも同じ制約を確認しました。
別記事で扱うレプリケーションの確認に備えて、binlog_format を ROW にしたカスタムクラスターパラメータグループを用意しました。binlog_format は静的パラメータなので、クラスターを作る前にパラメータグループ側で設定しておきます。
適用したパラメータファイル（cluster-parameters.json）
[
{"ParameterName":"binlog_format","ParameterValue":"ROW","ApplyMethod":"pending-reboot"}
]
aws rds create-db-cluster-parameter-group \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--db-parameter-group-family aurora-mysql8.4 \
--description "binlog row for replication verification"
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--parameters file://cluster-parameters.json
このパラメータグループを指定して、クラスターとライターインスタンスを作成しました。SQL の実行に RDS Data API を使うため、クラスター側で --enable-http-endpoint を指定しました。
aws rds create-db-cluster \
--db-cluster-identifier aurora848-verify-source \
--engine aurora-mysql \
--engine-version 8.4.mysql_aurora.8.4.8 \
--master-username admin \
--manage-master-user-password \
--db-subnet-group-name aurora848-verify-subnet-group \
--vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \
--db-cluster-parameter-group-name aurora848-verify-binlog-row \
--database-insights-mode standard \
--backup-retention-period 1 \
--no-deletion-protection \
--enable-http-endpoint
aws rds create-db-instance \
--db-instance-identifier aurora848-verify-source-1 \
--db-cluster-identifier aurora848-verify-source \
--db-instance-class db.r8g.large \
--engine aurora-mysql \
--enable-performance-insights \
--performance-insights-retention-period 7 \
--no-publicly-accessible
指定どおりのバージョンと構成でクラスターが作成できました。作成レスポンスの主な項目は次のとおりです。
| レスポンス項目 | 値 |
|---|---|
| EngineVersion | 8.4.mysql_aurora.8.4.8 |
| HttpEndpointEnabled | true |
| DatabaseInsightsMode | standard |
HttpEndpointEnabled が true になり、8.4.8 のプロビジョンドクラスターで RDS Data API を有効化できました。以降の SQL はすべて Data API 経由で実行しています。
クラスター上でバージョンを確認しました。
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SELECT VERSION() AS mysql_version, AURORA_VERSION() AS aurora_version;"
VERSION() と AURORA_VERSION() はどちらも 8.4.8 を返しました。
レプリケーション系プロシージャ
マルチソースレプリケーションと遅延レプリケーションは、8.4.8 以降で利用できると案内されています。
Multi-source replication and Delayed replication are supported on Aurora MySQL version 8.4.8 and higher, in all AWS Regions where Aurora MySQL is available.
これらの機能を操作する管理プロシージャが用意されているかを確認しました。
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SHOW PROCEDURE STATUS WHERE Db='mysql';"
遅延レプリケーションで遅延時間を指定するプロシージャは、次の 4 件が用意されていました。
rds_set_source_delay
rds_set_source_delay_for_channel
rds_set_external_source_with_delay
rds_set_external_source_with_delay_for_channel
マルチソースレプリケーションではソースごとにチャネルを分けるため、チャネル名を引数に取る _for_channel 版が必要です。レプリケーションの開始・停止やソース指定など、主要な操作に _for_channel 版が揃っていました。
レプリケーション関連プロシージャの一覧
rds_clean_replication_status_for_channel
rds_external_source
rds_import_binlog_ssl_material
rds_next_source_log
rds_next_source_log_for_channel
rds_remove_binlog_ssl_material
rds_reset_external_source
rds_reset_external_source_for_channel
rds_set_binlog_source_ssl
rds_set_binlog_source_ssl_for_channel
rds_set_external_source
rds_set_external_source_for_channel
rds_set_external_source_with_auto_position
rds_set_external_source_with_auto_position_for_channel
rds_set_external_source_with_delay
rds_set_external_source_with_delay_for_channel
rds_set_source_auto_position
rds_set_source_auto_position_for_channel
rds_set_source_delay
rds_set_source_delay_for_channel
rds_skip_repl_error
rds_skip_repl_error_for_channel
rds_start_replication
rds_start_replication_for_channel
rds_start_replication_until
rds_start_replication_until_for_channel
rds_start_replication_until_gtid
rds_start_replication_until_gtid_for_channel
rds_stop_replication
rds_stop_replication_for_channel
接続・認証・TLS の既定値
マイナーアップグレードで接続関連の再対応が必要になるかを確認するため、8.4.8 の既定値を、既存記事で実測した 8.4.7 の値と突き合わせました。
| 項目 | 8.4.7 | 8.4.8 |
|---|---|---|
| authentication_policy | *:caching_sha2_password | *:caching_sha2_password |
| require_secure_transport | ON | ON |
| validate_password.policy | MEDIUM | MEDIUM |
| validate_password.length | 8 | 8 |
認証方式、通信暗号化の必須化、パスワードポリシーの既定値は 8.4.7 と同じでした。表に挙げていない項目では、大文字・小文字、数字、記号の必要数がどちらのバージョンも 1 です。接続設定の見直しが必要になる変更は見当たりませんでした。
Data API のセッションでは、Ssl_version が TLSv1.3、Ssl_cipher が TLS_AES_256_GCM_SHA384 でした。いずれもセッション単位の値で、クライアント実装とネゴシエーションの結果で変わります。
TLS 関連のサーバー変数も、Data API 経由で SHOW VARIABLES LIKE 'tls%' と LIKE 'ssl%' を実行して確認しました。tls_version は TLSv1.2 と TLSv1.3、tls_ciphersuites は TLS_AES_128_GCM_SHA256 と TLS_AES_256_GCM_SHA384、tls_certificates_enforced_validation は OFF、ssl_fips_mode は ON でした。
トランザクションタイムアウト
長時間のトランザクションが InnoDB のパージを妨げる問題への対策として、トランザクションタイムアウトが 8.4.8 で使えるようになりました。対応するサーバー変数を確認しました。
aws rds-data execute-statement \
--resource-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:aurora848-verify-source \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-xxxxxxxx \
--database mysql \
--format-records-as JSON \
--sql "SHOW VARIABLES LIKE '%transaction%';"
aurora_transaction_timeout が存在し、値は 0 でした。SHOW VARIABLES LIKE '%timeout%' も実行しましたが、トランザクションタイムアウトに対応する変数はこれだけでした。既定では無効で、使うには値の設定が必要です。
サポート期限とバージョン選択
8.4 系のマイナーバージョンは、リリースカレンダーに 8.4.7 と 8.4.8 の 2 つが載っています。
| Aurora MySQL バージョン | 互換 MySQL | リリース日 | 標準サポート終了日 |
|---|---|---|---|
| 8.4.8 | 8.4.8 | 2026-09-03 | 2027-09-03 |
| 8.4.7 | 8.4.7 | 2026-05-21 | 2027-11-30 |
どちらも標準サポートは 2027 年中に終わります。8.4 系には LTS 指定のバージョンがなく、LTS は 3.10 と 3.04 の 2 つだけです。
メジャーバージョンで見ると、標準サポート終了は次のとおりです。
| Aurora メジャーバージョン | 互換 MySQL | 標準サポート終了 |
|---|---|---|
| 8.4 | MySQL 8.4 | 2032 年 4 月 |
| 3 | MySQL 8.0 | 2028-04-30 |
メジャーとして長く使えるのは 8.4 系ですが、その中のマイナーは 1 年程度で入れ替わります。年 1 回程度のマイナーアップグレードを前提にできるなら 8.4 系、同じマイナーバージョンに長く留まることを優先するなら 3 系の LTS である 3.10（標準サポート 2028-04-30）という判断になります。
まとめ
Aurora MySQL 8.4.8は8.4系のマイナーアップデートで、東京リージョンでは8.4.7からアップグレードできます。接続に関する既定値は8.4.7と同じであり、既定値で運用している場合は接続設定を変更する必要はありません。
8.4.8では、マルチソースレプリケーションと遅延レプリケーションに加え、PQ-TLSの鍵交換も利用できます。これらの機能が必要な場合、またはガイドラインなどでポスト量子暗号への対応を求められる環境では、8.4.8を選ぶ理由になります。更新を先送りして後でまとめて対応するリスクを避けたい場合にも、早めに8.4.8を選択するのも一案です。
レプリケーション機能やポスト量子暗号への対応など、Aurora MySQL 8.4.8の新機能の詳細は、後日別記事で紹介する予定です。
