この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ボタンひとつでインプレースメジャーアップグレードに対応
Amazon Aurora MySQL のデータベースエンジンは
- 5.6 互換の1.x 系
- 5.7 互換の2.x 系
の2系統があります。
従来、1系から2系にメジャーアップグレードするには
- スナップショットからのリストア時に2系エンジンを指定
- 1系のプライマリから2系レプリカに同期してダウンタイム無しにスイッチオーバー
といった方針が取られてきました。
今回のアップデートにより、Amazon Aurora MySQLをクリックひとつでインプレースにメジャーアップグレードできるようになりました。
Amazon Aurora supports in-place upgrades from MySQL 5.6 to 5.7
アップグレード手順が大幅に簡略化され、エンドポイントの変更もありません。
アップグレード中はデータベースを利用できない点にはご注意ください。
やってみた
コンソールからアップグレード
コンソールからバージョンアップグレードするには、クラスターの変更画面で、2系エンジンを指定し、関連するDBパラメーターグループを指定するだけです。
コマンドラインからアップグレード
コマンドラインからバージョンアップグレードするには、 aws rds modify-db-cluster API を使います。
$ aws rds modify-db-cluster \
--db-cluster-id YOUR-CLUSTER-NAME \
--engine-version 5.7.mysql_aurora.2.09.1 \
--db-cluster-parameter-group-name YOUR-DB-CLUSTER-PARAMETER-GROUP-NAME \
--allow-major-version-upgrade \
--apply-immediatelyアップグレード可能なバージョンは aws rds describe-db-engine-versions API で確認可能です。
1系の最新版 1.23.1 の場合、 2.09.1 にのみアップグレード可能です。
$ aws rds describe-db-engine-versions \
--engine aurora \
--engine-version 5.6.mysql_aurora.1.23.1 \
--query '*[].[ValidUpgradeTarget]' \
--output table
------------------------------------------------------------------------------------------------------------------
| DescribeDBEngineVersions |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+
| AutoUpgrade | Description | Engine | EngineVersion | IsMajorVersionUpgrade |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+
| False | Aurora (MySQL 5.7) 2.09.1 | aurora-mysql | 5.7.mysql_aurora.2.09.1 | True |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+メジャーアップグレードのため
- AutoUpgrade : False
- IsMajorVersionUpgrade : True
となっています。
1系最新版ではない 1.22.3 の場合、より多くのアップグレードパスが存在します。
$ aws rds describe-db-engine-versions \
--engine aurora \
--engine-version 5.6.mysql_aurora.1.22.3 \
--query '*[].[ValidUpgradeTarget]' \
--output table
------------------------------------------------------------------------------------------------------------------
| DescribeDBEngineVersions |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+
| AutoUpgrade | Description | Engine | EngineVersion | IsMajorVersionUpgrade |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+
| False | Aurora (MySQL 5.6) 1.23.1 | aurora | 5.6.mysql_aurora.1.23.1 | False |
| False | Aurora (MySQL 5.7) 2.07.3 | aurora-mysql | 5.7.mysql_aurora.2.07.3 | True |
| False | Aurora (MySQL 5.7) 2.09.1 | aurora-mysql | 5.7.mysql_aurora.2.09.1 | True |
+-------------+-----------------------------+---------------+--------------------------+-------------------------+インプレースアップグレードの準備
ドキュメントの「Planning a major version upgrade for an Aurora MySQL cluster」から、アップグレード時の検討事項を抜粋します。
- クラスターをクローンしてインプレースアップグレードできることを確認
- アップグレード後のバージョンでレグレッションテストを入念に実施
- メジャーアップグレード前に1系の最新版へ一旦アップグレードするため、事前に1系の最新版まで上げてアップグレード時間を短縮
- ワークロードが少ないタイミングを選んでアップグレードを実施
詳細はドキュメントをご確認下さい。
アップグレード失敗時のリカバリについて
データベース操作はトラブルがつきものです。
ドキュメントの「How the Aurora MySQL in-place major version upgrade works」から障害発生時の振る舞いとそのリカバリ方法をピンポイントで紹介します。
アップグレードはキャンセルできない
一度アップグレードが始まると、途中でキャンセルできません。
完了、または、失敗するまで気長に待ちましょう。
Once the process begins, it runs until the upgrade either succeeds or fails. You can't cancel the upgrade while it's underway.
データベースの構成変更はなかなか終わらずにハラハラすることが多いですが、インプレースアップグレードは、間違いなく横綱級のハラハラ機能です。
アップグレードに失敗したらクラスターはどうなる?
アップグレード開始時にクラスターを Clone します。
インプレースアップグレードに失敗すると、このクローンしたクラスターで復旧されます。
Aurora clones your cluster volume. Cloning is a fast operation that doesn't involve copying the actual table data. If Aurora encounters an issue during the upgrade, it reverts to the original data from the cloned cluster volume and brings the cluster back online. The temporary cloned volume during the upgrade isn't subject to the usual limit on the number of clones for a single cluster volume.
アップグレード後に元のバージョンに戻したい
アップグレード完了後に一部の機能が使えない事が判明したり、クエリー速度の劣化などにより、クラスターを1系に戻すことになるかもしれません。
そのような場合は、インプレースアップグレード実行時に取得されるマニュアルスナップショットからクラスターをリストアしましょう。
preupgrade-[クラスター名]-[アップグレード元バージョン]-[アップグレード先バージョン]-[実行日時]という命名規則のスナップショットがそれです。
具体的には preupgrade-test-5-6-mysql-aurora-1-22-2-to-5-7-mysql-aurora-2-09-1-2021-01-12-12-59 というような名前です。
メジャーアップグレード中のステータスの変化
1.22.2(1系最新版の一つ前のバージョン)から 2.09.1 へのメジャーアップグレード中に
aws rds describe-db-clustersaws rds describe-db-instances
などでAuroraクラスター、DBインスタンスのステータスを確認すると、次の表のようになりました。
アップグレード中の多くの時間帯ではクラスターエンドポイントに接続できませんでした。
また、ドキュメントにはメジャーアップグレード前に1系の最新版(1.22.3)にアップグレードすると記載がありましたが、 APIから確認できるDBエンジンバージョンは、1.22.2から 2 系に直接アップグレードされていました。
RDSイベントを確認すると、 Cluster の "Upgrade in progress: Performing online pre-upgrade checks." でアップグレードが始まり、最後は
- Cluster の Database cluster major version has been upgraded
- Instances の Updated to use DBParameterGroup YOUR-Parameter-Group-Name
でアップグレードが完了していました。
どのメジャーアップグレード方法を選ぶ？
今回のインプレースアップグレード対応により、メジャーアップグレードは以下の3通りが存在します。
- 本記事で紹介したインプレースアップグレード
- スナップショットからリストア
- レプリケーション後にスイッチオーバー
どのように使い分ければ良いでしょうか?
ダウンタイムを許容できない場合は、レプリケーション方式一択です。
難しいのは1つ目と2つ目の違いです。
操作がかんたんなことと、エンドポイント名が変わらないことは、インプレース方式のスナップショット・リストア方式に対する大きなメリットです。
元のクラスターを残す場合はスナップショット、残さなくて良い場合はインプレースとすれば良さそうです。
とはいえ、クラスターをクローン後にインプレースアップグレードすれば、スナップショット・リストア方式と同等のことを実現できます。
そのため、まずは
- ダウンタイムを許容できるならインプレース方式
- 許容できないならレプリケーション方式
で検討してみるとよいのではないかと思います。
それでは。
参考
- Amazon Aurora supports in-place upgrades from MySQL 5.6 to 5.7
- Upgrading the major version of an Aurora MySQL DB cluster from 1.x to 2.x - Amazon Aurora
- Restoring from a DB cluster snapshot - Amazon Aurora
- Performing major version upgrades for Amazon Aurora MySQL with minimum downtime | AWS Database Blog
2
