Aurora MySQLを扱い始めて最初に詰まるのは、「いまどの版で動いているか」と「コミュニティ版のMySQLと何が違うか」の2点です。この記事では、aurora_version()とAWS CLIで稼働中の版を確かめる方法、2026年10月31日に標準サポートが終わる3.04 LTSなど直近の期限、MySQL 8.0から移すときに書き換える権限と認証の差分、Aurora MySQLだけのBacktrack、RDS for MySQLからAuroraリードレプリカで移行するCLI手順を、AWS公式ドキュメントに基づいて順に解説します。Aurora全体の仕組みと料金構成はAmazon Auroraの仕組みと採用判断を解説した記事で、クラスターをゼロから作る手順はCLIでAuroraを構築する手順の記事で扱っています。
まとめ：Aurora MySQLの版・MySQLとの差分・移行方式を決める要点
Aurora MySQLの現行の系統は、MySQL 8.0互換のversion 3と、MySQL 8.4互換の8.4系の2つです。新規構築なら標準サポートが2032年4月まである8.4系、MySQL 8.0前提の既存アプリならLTSの3.10（2028年4月30日まで）が基準になります。3.04 LTSで動くクラスターは2026年10月31日、3.11は同年11月13日に標準サポートが切れるため、更新の計画はもう先送りできません。
MySQL 8.0からの移行で書き換えが要るのは、mysql.userへ直接INSERTしてユーザーを作る処理と、@@server_idを数値として読む監視スクリプトです。移行元がRDS for MySQLなら、Auroraリードレプリカを作り、ラグが0になった時点で昇格させる方式を公式は推奨しています。止まるのは書き込みを止めてから昇格が終わるまでの間だけです。
Aurora MySQLの稼働中の版をSQLとCLIで確かめてサポート期限と照合
版の確認は移行でも保守でも最初の作業です。SQLで見る番号とCLIで見る番号は表記が違うので、両方を読めるようにしておきます。
aurora_version()とCLIのエンジン版表記で稼働中の版を特定する手順
Aurora MySQLの版番号の確認方法を説明した公式ページでは、SQLはaurora_version()か@@aurora_versionで3.05.2のような3桁の番号を返し、CLIやコンソールでは8.0.mysql_aurora.3.04.0の形式で表記されると説明されています。8.4系からは表記が単純になり、8.4.mysql_aurora.8.4.7のようにAuroraの番号とMySQLの版がそろいました。
-- 接続中のインスタンスで実行する
SELECT aurora_version(), @@aurora_version, @@aurora_server_id;
# AWS CLIでAurora MySQLのクラスターとエンジン版を一覧する
aws rds describe-db-clusters \
--filters Name=engine,Values=aurora-mysql \
--query 'DBClusters[].[DBClusterIdentifier,EngineVersion,Status]' \
--output tableversion 3の番号は、そのままではコミュニティ版のどの版に当たるかが分かりません。3.13ならMySQL 8.0.45互換、3.10なら8.0.42互換というように、次のリリースカレンダーで対応を引きます。公式によると、3.xの全版はMySQL 8.0.23以上とワイヤ互換です。
2026年10月末から順に切れるマイナー版の標準サポート期限と延長サポート
Aurora MySQLのリリースカレンダーに載っている、2026年9月時点でサポート中のマイナー版は次のとおりです。
| Aurora MySQLの版 | 互換するMySQL | リリース日 | 標準サポート終了 |
|---|---|---|---|
| 8.4.8 | 8.4.8 | 2026年9月3日 | 2028年3月31日 |
| 8.4.7 | 8.4.7 | 2026年5月21日 | 2027年11月30日 |
| 3.13 | 8.0.45 | 2026年8月27日 | 2027年8月27日 |
| 3.12 | 8.0.44 | 2026年2月17日 | 2027年2月17日 |
| 3.11 | 8.0.43 | 2025年11月13日 | 2026年11月13日 |
| 3.10（LTS） | 8.0.42 | 2025年7月31日 | 2028年4月30日 |
| 3.04（LTS） | 8.0.28 | 2023年7月31日 | 2026年10月31日 |
3.08と3.09は2026年8月31日で期限を過ぎました。3.04 LTSで動かしているなら、次のLTSである3.10へ上げると2028年4月30日まで同じマイナー版に留まれます。
メジャー版では、version 3の標準サポートが2028年4月30日までです。version 2（MySQL 5.7互換）は2024年10月31日に標準サポートを終え、有料のRDS延長サポートで動いています。version 2の延長サポートは2026年12月1日から3年目の料金に切り替わり、2029年6月30日に終わります。課金の仕組みはRDS延長サポートの公式ページ、単価はAmazon Auroraの公式料金ページで確かめてください。8.4系へ上げる場合の非互換は、Aurora MySQL 8.4の全体像と移行の前提を整理した記事にまとめています。
MySQL 8.0コミュニティ版からAurora MySQLへ移すときに書き換える箇所
Aurora MySQL version 3とMySQL 8.0コミュニティ版を比較した公式ページによると、version 3はおおむねコミュニティ版8.0.23の機能セットに対応しています。Auroraのストレージ構造と合わない機能や、RDSの管理機能で代わりが用意されている機能は外されました。影響の大きい順に見ていきます。
mysql.userへの直接INSERTが通らないロール型の権限モデルへの対応
version 3ではmysqlデータベースのテーブルを直接変更できません。mysql.userへのINSERTでユーザーを作るスクリプトや、mysqlデータベースにストアドプロシージャを置く運用は、そのまま動かすことはできないため、書き換えが必要です。マスターユーザーにはrds_superuser_roleが付与されますが、その権限一覧にSUPERは含まれていません。
-- CREATE USERとロールで権限を付与する（mysql.userへのINSERTは不可）
CREATE ROLE 'app_rw';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app_rw';
CREATE USER 'app'@'%' IDENTIFIED BY 'change-me';
GRANT 'app_rw' TO 'app'@'%';
SET DEFAULT ROLE 'app_rw' TO 'app'@'%';
-- マスターユーザーが持つ権限の中身を確かめる
SHOW GRANTS FOR rds_superuser_role@'%';公式は、マスターユーザーをアプリから直接使わず、必要最小限の権限を持つユーザーを作るよう強く推奨しています。外部のMySQLからユーザー定義を移すときは、mysqldumpではなくMySQL Shellのダンプユーティリティを使うよう案内されています。
既定の認証プラグインがmysql_native_passwordのままになる点の確認
コミュニティ版MySQL 8.0の既定の認証プラグインはcaching_sha2_passwordです。一方でAurora MySQL version 3はmysql_native_passwordを使い続けており、default_authentication_pluginは変更できません。ユーザー単位でなら新しい方式を指定できます。
-- ユーザーごとに認証方式を指定して作成する
CREATE USER 'batch'@'%' IDENTIFIED WITH caching_sha2_password BY 'change-me';
-- 既存ユーザーの認証方式を一覧する（参照はできる）
SELECT user, host, plugin FROM mysql.user
WHERE user NOT LIKE 'rds%' ORDER BY plugin, user;コミュニティ版8.0から移すと、既定値の違いで接続できるドライバの条件が変わります。8.4系では認証プラグインの扱いがさらに変わるため、この一覧を今のうちに残しておくと、次の更新で影響範囲を洗い出す時間が短くなります。
リソースグループやX Pluginなどversion 3で使えない機能と代わりの手段
公式の比較ページで、コミュニティ版8.0にあってversion 3に無い、または動きが違うとされている機能は次のとおりです。
- リソースグループと関連するSQL文
- ユーザー定義のundoテーブルスペース（
CREATE UNDO TABLESPACEなど）。undoの自動truncateは3.06以上で対応 - X Plugin（MySQL Shellのドキュメントストア接続）
- マルチソースレプリケーション
- プラグイン設定の変更（パスワード検証プラグイン自体は使える）
見落としやすいのがサーバーIDです。コミュニティ版の@@server_idは数値ですが、Auroraでは@@aurora_server_idがインスタンス識別子の文字列を返します。レプリケーションの監視や接続先の判定で数値のserver_idを前提にしているスクリプトは書き換えます。
Aurora MySQLだけの機能とBacktrackで誤操作の前へ巻き戻す手順
移行で失う機能がある一方、Aurora MySQLにしか無い機能もあります。運用を楽にする効果が大きいのはBacktrackと、他のAWSサービスを呼ぶためのロールです。
作成時にしか有効化できないBacktrackの72時間ウィンドウの設定
Backtrackは、バックアップから復元せずにクラスター全体を指定した時刻へ戻す機能です。Backtrackの公式ドキュメントによると、version 2・3・8.4で使え、東京リージョンは全版が対象です。ただし有効化できるのはクラスターの作成時か、スナップショットからの復元時だけで、既存のクラスターを後から変更して有効にはできません。
# 作成時に24時間（86400秒）のウィンドウを指定する。上限は259200秒（72時間）
aws rds create-db-cluster --db-cluster-identifier shop-aurora \
--engine aurora-mysql --engine-version "$VER" \
--master-username admin --manage-master-user-password \
--db-subnet-group-name app-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0 \
--backtrack-window 86400
# WHERE句なしのDELETEを流す前の時刻へ戻す（UTC・未来の時刻は不可）
aws rds backtrack-db-cluster --db-cluster-identifier shop-aurora \
--backtrack-to 2026-09-27T01:30:00Z
aws rds describe-db-cluster-backtracks --db-cluster-identifier shop-aurora--backtrack-windowの単位は秒で、create-db-clusterのリファレンス（CLI 2.37系）には0から259,200までと書かれています。戻せるのはクラスター全体で、テーブル1つだけを戻すことはできません。実行中は接続が閉じられ、未コミットの読み書きは破棄されるので、アプリを止めてから実行します。変更レコードの保存には時間単位の課金がかかり、binlogを有効にしたクラスターでは通常エラーになる仕様です。--forceで強行すると下流のレプリカが壊れます。
S3の読み込みやLambda呼び出しをロールで許可するSET ROLEの手順
version 3には、他のAWSサービスを呼ぶための組み込みロールがあります。S3からの読み込みはAWS_LOAD_S3_ACCESS、S3への書き出しはAWS_SELECT_S3_ACCESS、Lambdaの呼び出しはAWS_LAMBDA_ACCESSで、Amazon Bedrock用のAWS_BEDROCK_ACCESSもあります。
GRANT AWS_LOAD_S3_ACCESS TO 'etl'@'%';
-- 付与しただけでは有効にならない。セッションで有効化して確かめる
SET ROLE ALL;
SELECT CURRENT_ROLE();公式の例では、付与直後のCURRENT_ROLE()にはrds_superuser_roleしか表示されず、SET ROLE ALLの後に初めて追加したロールが現れます。「権限を付けたのにS3から読めない」という問い合わせの多くはこの有効化漏れです。クラスター側にも、S3やLambdaへアクセスするためのIAMロールを別途関連付けます。
RDS for MySQLからAurora MySQLへリードレプリカで移行するCLI手順
Auroraリードレプリカによる移行の公式手順は、RDS for MySQLからの移行でこの方式を推奨しています。RDSが移行元のスナップショットを取り、Auroraへデータを移したあと、binlogレプリケーションで差分を追い続ける仕組みです。データ移行にはTiBあたり数時間かかると明記されていますが、その間も移行元は通常どおり動きます。
移行前にMyISAMのInnoDB変換と暗号化・版の制約を確かめる
InnoDB以外のエンジンや圧縮行形式のテーブルが残っていると、リードレプリカの作成が遅くなります。binlogレプリケーションの公式ページも、MySQLとAurora MySQLの間ではInnoDBのテーブルだけを使うよう警告しています。
-- InnoDB以外のテーブルと圧縮行形式のテーブルを洗い出す
SELECT table_schema, table_name, engine, row_format
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys')
AND (engine != 'InnoDB' OR row_format = 'Compressed');
-- 見つかったテーブルをInnoDBへ変換する（テーブルはコピーされる）
ALTER TABLE shop.access_log ENGINE=InnoDB, ALGORITHM=COPY;作成の前に次の制約も確かめます。暗号化されたRDSインスタンスから非暗号化のAuroraクラスターは作れません。移行元がクロスリージョンリードレプリカの元になっている場合は作成できず、1つのRDSインスタンスに作れるAuroraリードレプリカは1つだけです。RDS for MySQL 8.0.11・8.0.13・8.0.15からはAurora MySQL 3.05以上へ移行できないため、先に8.0.28へ上げるよう公式は勧めています。
移行元のARNを指定してAuroraリードレプリカを作成するCLI手順
create-db-clusterに移行元インスタンスのARNを--replication-source-identifierで渡します。マスターユーザー名・パスワード・データベース名は移行元と同じになるため指定しません。公式手順のCLI例は--engine auroraという古い書き方ですが、現行のCLIリファレンスの有効値はaurora-mysqlです。
SRC_ARN=$(aws rds describe-db-instances --db-instance-identifier rds-mysql-prod \
--query 'DBInstances[0].DBInstanceArn' --output text)
# 移行先の版を決める（既定版を使わないなら本番と同じ互換の版を入れる）
VER=$(aws rds describe-db-engine-versions --engine aurora-mysql --default-only \
--query 'DBEngineVersions[0].EngineVersion' --output text)
aws rds create-db-cluster --db-cluster-identifier aurora-mig \
--engine aurora-mysql --engine-version "$VER" \
--replication-source-identifier "$SRC_ARN" \
--db-subnet-group-name app-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0 \
--storage-encrypted
# CLIではプライマリインスタンスを自分で作る
aws rds create-db-instance --db-instance-identifier aurora-mig-1 \
--db-cluster-identifier aurora-mig --engine aurora-mysql \
--db-instance-class db.r7g.largeコンソールから作るとプライマリインスタンスも自動で作られますが、CLIでは2つ目のコマンドを忘れると接続先が存在しません。サブネットグループやセキュリティグループの準備は、Auroraをゼロから構築する手順を解説した記事と同じです。
SHOW REPLICA STATUSでラグ0を確かめて昇格させる切り替え手順
切り替えの順番は、移行元への書き込みを止める、ラグが0になるのを待つ、昇格させる、の3段です。
-- Auroraリードレプリカ側で実行する（version 3の構文）
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source が 0 になっていることを確かめる
# 移行元への書き込みを止め、ラグ0を確認してから昇格させる
aws rds promote-read-replica-db-cluster --db-cluster-identifier aurora-mig
# 昇格完了のイベントを確かめる
aws rds describe-events --source-type db-cluster \
--source-identifier aurora-mig --duration 60 \
--query 'Events[].Message' --output textラグが0になる前にAurora側へ書き込み、移行元でも同じテーブルが更新されると、レプリケーションが壊れてリードレプリカを作り直すことになります。promote-read-replica-db-clusterのリファレンスを実行したあとは、昇格中も読み書きできますが、移行元の削除や切り離しはできません。Promoted Read Replica cluster to a stand-alone database clusterのイベントを確かめてから、アプリの接続先をAuroraのクラスターエンドポイントへ切り替えます。
Aurora MySQLへの移行方式を停止時間で選ぶ基準と見送るべき条件
結論から言うと、移行元がRDS for MySQLならAuroraリードレプリカ方式を選び、他の方式を比べる必要はありません。迷うのは移行元がオンプレミスやEC2上のMySQLの場合です。
リードレプリカ・ダンプ・binlogレプリケーションを選び分ける条件
3つの方式は、止まる範囲がまったく違います。
| 方式 | 使える移行元 | 止まる範囲 | 選ぶ条件 |
|---|---|---|---|
| Auroraリードレプリカ | RDS for MySQL | 書き込み停止から昇格まで | 移行元がRDSなら常にこれ |
| ダンプとリストア | RDS・外部MySQL | ダンプからリストアの完了まで | 数十GB以下で夜間停止が取れる |
| ダンプ＋binlogレプリケーション | 外部MySQL | 追いついた後の切り替えだけ | 停止を分単位に抑えたい |
ダンプとリストアは手順が単純な代わりに、停止時間がデータ量に比例して伸びます。数十GBを超えるなら選びません。binlogレプリケーションはGTIDの設定を移行元とそろえる手間がかかるため、外部MySQLで停止を短くしたい場合に限って使います。
Aurora MySQLを見送る場面と移行設計を外部に任せる判断の目安
Aurora MySQLを見送るべきなのは、MyISAMなどInnoDB以外のエンジンに依存し続ける必要があるシステムと、リソースグループ・X Plugin・マルチソースレプリケーションを本番で使っているシステムです。1台で足りる小規模なDBも、Auroraの分散ストレージの利点が出にくいため、標準RDSで十分です。判断の材料はAmazon RDSの対応エンジンと採用判断を解説した記事にまとめています。負荷の波が大きい小規模DBなら、Aurora Serverless v2の料金とスケーリングを解説した記事の構成で小さく始める選択肢もあります。
移行元が複数あり、5.7系と8.0系が混ざっている、停止の許容が分単位、ユーザー権限の棚卸しが済んでいない、のどれかに当てはまるなら、設計から外部の手を借りるほうが早く終わります。データベース設計・移行支援のサービスに、移行元の版・データ量・停止の許容時間の3点を伝えて相談すると、方式の選定から見積もりまでの前提がそろいます。
よくある質問
Aurora MySQLの版選びと移行で出やすい疑問を、AWS公式ドキュメントに基づいて整理します。
Aurora MySQLとMySQLの違いは何ですか？
SQLとクライアントの接続方式はMySQLと互換で、既存のドライバでそのまま接続できます。違うのは、3つのAZに複製される分散ストレージの上で動く点と、管理権限です。mysqlデータベースのテーブルを直接変更できず、SUPER権限もありません。version 3では既定の認証方式がmysql_native_passwordで、リソースグループやX Pluginは使えません。
Aurora MySQLのバージョンはどうやって確認しますか？
接続中のインスタンスでSELECT aurora_version();を実行すると、3.13.0や8.4.8のような番号が返ります。CLIではaws rds describe-db-clustersのEngineVersionに表示される番号の形式は8.0.mysql_aurora.3.13.0です。番号から互換するMySQLの版と標準サポートの期限を知るには、公式のリリースカレンダーを引きます。
Aurora MySQL version 2（MySQL 5.7互換）は今も使えますか？
動かし続けることはできますが、2024年10月31日に標準サポートが終わり、現在は有料のRDS延長サポートの対象です。2026年12月1日から延長サポートの3年目の料金に切り替わり、2029年6月30日に延長サポートも終わります。リリースカレンダーでは、延長サポートの対象となるマイナー版は2.11と2.12とされています。
RDS for MySQLからAurora MySQLへ移行すると、どのくらい止まりますか？
Auroraリードレプリカ方式なら、止まるのは移行元への書き込みを止めてから、ラグが0になり昇格が終わるまでです。公式の説明では、昇格は比較的速く終わる処理です。事前のデータコピーにはTiBあたり数時間かかりますが、その間も移行元はサービスを続けられます。止まる時間を見積もるなら、事前に同じ手順を検証環境で1回通して測っておきます。
Aurora MySQLのBacktrackは後から有効にできますか？
できません。Backtrackを有効にできるのはクラスターの作成時か、スナップショットから復元するときだけです。既存のクラスターで使いたい場合は、スナップショットを取り、--backtrack-windowを指定して新しいクラスターとして復元します。ウィンドウの上限は72時間で、変更レコードの保存に時間単位の課金がかかります。
関連記事
- Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：Aurora MySQLの土台になる分散ストレージと料金構成、採用判断を整理した記事
- Aurora（AWS）の構築手順：CLIでクラスター作成・接続・フェイルオーバー検証まで：移行先のクラスターをCLIで作り、フェイルオーバーまで検証する手順の記事
- Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提：version 3から8.4系へ上げるときの非互換と更新手順を扱った記事
- Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説：移行元のRDS for MySQLと標準RDSを選ぶ場面を確認できる記事
- MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】：コミュニティ版MySQLの版の系統とサポート期限を押さえられる記事
