--- title: "Aurora MySQLの実装ガイド：版の確認、MySQL 8.0との差分とRDSからの移行手順" url: "https://www.issoh.co.jp/tech/details/17889/" published: 2026-09-27 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # Aurora MySQLの実装ガイド：版の確認、MySQL 8.0との差分とRDSからの移行手順 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の仕組みと採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15447/)で、クラスターをゼロから作る手順は[CLIでAuroraを構築する手順の記事](https://www.issoh.co.jp/tech/details/17844/)で扱っています。 ## まとめ：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の版番号の確認方法を説明した公式ページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html)では、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 table ``` version 3の番号は、そのままではコミュニティ版のどの版に当たるかが分かりません。3.13ならMySQL 8.0.45互換、3.10なら8.0.42互換というように、次のリリースカレンダーで対応を引きます。公式によると、3.xの全版はMySQL 8.0.23以上とワイヤ互換です。 ### 2026年10月末から順に切れるマイナー版の標準サポート期限と延長サポート [Aurora MySQLのリリースカレンダー](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.release-calendars.html)に載っている、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延長サポートの公式ページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/extended-support.html)、単価は[Amazon Auroraの公式料金ページ](https://aws.amazon.com/jp/rds/aurora/pricing/)で確かめてください。8.4系へ上げる場合の非互換は、[Aurora MySQL 8.4の全体像と移行の前提を整理した記事](https://www.issoh.co.jp/tech/details/12354/)にまとめています。 ## MySQL 8.0コミュニティ版からAurora MySQLへ移すときに書き換える箇所 [Aurora MySQL version 3とMySQL 8.0コミュニティ版を比較した公式ページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-80-v3.html)によると、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の公式ドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html)によると、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のリファレンス](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)（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リードレプリカによる移行の公式手順](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html)は、RDS for MySQLからの移行でこの方式を推奨しています。RDSが移行元のスナップショットを取り、Auroraへデータを移したあと、binlogレプリケーションで差分を追い続ける仕組みです。データ移行にはTiBあたり数時間かかると明記されていますが、その間も移行元は通常どおり動きます。 ### 移行前にMyISAMのInnoDB変換と暗号化・版の制約を確かめる InnoDB以外のエンジンや圧縮行形式のテーブルが残っていると、リードレプリカの作成が遅くなります。[binlogレプリケーションの公式ページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)も、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をゼロから構築する手順を解説した記事](https://www.issoh.co.jp/tech/details/17844/)と同じです。 ### 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のリファレンス](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html)を実行したあとは、昇格中も読み書きできますが、移行元の削除や切り離しはできません。`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の対応エンジンと採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15426/)にまとめています。負荷の波が大きい小規模DBなら、[Aurora Serverless v2の料金とスケーリングを解説した記事](https://www.issoh.co.jp/tech/details/4586/)の構成で小さく始める選択肢もあります。 移行元が複数あり、5.7系と8.0系が混ざっている、停止の許容が分単位、ユーザー権限の棚卸しが済んでいない、のどれかに当てはまるなら、設計から外部の手を借りるほうが早く終わります。[データベース設計・移行支援のサービス](https://www.issoh.co.jp/service/system/database/)に、移行元の版・データ量・停止の許容時間の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との違いと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15447/)：Aurora MySQLの土台になる分散ストレージと料金構成、採用判断を整理した記事 - [Aurora（AWS）の構築手順：CLIでクラスター作成・接続・フェイルオーバー検証まで](https://www.issoh.co.jp/tech/details/17844/)：移行先のクラスターをCLIで作り、フェイルオーバーまで検証する手順の記事 - [Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提](https://www.issoh.co.jp/tech/details/12354/)：version 3から8.4系へ上げるときの非互換と更新手順を扱った記事 - [Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15426/)：移行元のRDS for MySQLと標準RDSを選ぶ場面を確認できる記事 - [MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】](https://www.issoh.co.jp/tech/details/13135/)：コミュニティ版MySQLの版の系統とサポート期限を押さえられる記事 --- 出典: [Aurora MySQLの実装ガイド：版の確認、MySQL 8.0との差分とRDSからの移行手順]()（株式会社一創）