Amazon RDS Blue/Green Deploymentsを用いたアップグレードでハマったこと2選
こんにちは。ユビレジ開発グループ基盤ユニットの松塚です。
データベースのバージョンアップ作業を担当した時の話をしようと思います。
ユビレジでは AWS RDS MySQL Auroraをデータベースのエンジンとして使っています。
今年、
3月にマイナーバージョンのアップグレード
8月にMySQL8にアップグレード
をしました。
ちょうどこの頃、Amazon RDS Blue/Green Deployments が利用可能になったのでそれを用いてアップグレードをしようとしました。
手動でやると手間のかかる作業が大幅に効率化され、便利で優れたものであると思いました。
基本的に何事もなく順調に扱えるものだと思いますが、ユビレジのDBアップグレードにおいてAmazon RDS Blue/Green Deployments利用中にハマったことがあったので紹介します。
利用中のバージョンがAmazon RDS Blue/Green Deploymentsの対象バージョン外でGreen DBがプロビジョニングのステータスで止まり、作成されなかった
Aurora MySQL 2.10.2 -> Aurora MySQL 2.11.1 に上げようとした時の話となります。
要約
2023/1月、Amazon RDS Blue/Green DeploymentsでGreen DBを作成できることを確認
2023/3月7日、突如Amazon RDS Blue/Green DeploymentsでGreen DBを作成できなくなっていることを確認
やむをえずAmazon RDS Blue/Green Deploymentsを使わずにDBアップグレードした。
起きたこと推測
Aurora MySQL 2.10.2が1月の時点ではGreen DBを作成できたが、それ以降どこかのタイミングでAmazon RDS Blue/Green Deploymentsの対象バージョン外となりGreen DBを作成することができなかった。
詳細
ことの発端として、以下のメールが2023/2/21日にawsから来ていたのでその対応のためにバージョンを上げようとしていました。
Amazon RDS Blue/Green Deployments が気になっていたこともあり、これでやってみようと早速検証用DBを作成しAmazon RDS Blue/Green Deploymentsを試してみたところ
問題なくGreen DBが作成され、あとは切り替えるだけとなりました。
この時はすごく簡単だと感動しました。
Green DBを立てたままにしているとその分のお金がかかるので、
切り替え予定日の一週間前に本番のDBでGreen DBを作ることにしました。
本番DBでGreen DBを作成しようとしたところ、30 ~ 60分程度経ってもGreen DBがプロビジョニング中というステータスのままで、進みませんでした。
describe-blue-green-deploymentsコマンドで見てみると以下のような様子です。
% aws rds describe-blue-green-deployments
{
"BlueGreenDeployments": [
{
"BlueGreenDeploymentIdentifier": "test-blue-green-deployment-identifier",
"BlueGreenDeploymentName": "test-db-cluster-blue-green",
"Source": "xxxx",
"SwitchoverDetails": [
{
"SourceMember": "xxxxxx:cluster",
"Status": "PROVISIONING"
},
{
"SourceMember": "xxxxxx:instance",
"Status": "PROVISIONING"
}
],
"Tasks": [
{
"Name": "CREATING_READ_REPLICA_OF_SOURCE",
"Status": "IN_PROGRESS"
},
{
"Name": "DB_ENGINE_VERSION_UPGRADE",
"Status": "PENDING"
}
],
"Status": "PROVISIONING",
"CreateTime": "2023-03-10T12:01:15.326000+00:00",
"TagList": []
}
]
}
通常は1枚目の画像のように30分もすればGreen DBが出来上がっているはずでした。
厄介だったのは
エラーメッセージ等も一切表示されず、ただプロビジョニング中で状態が止まったまま
1月の段階ではできていた実績があった
点でした。
AWS サポートに入っていればテクニカルサポートに相談することもできたのですが、
問題の起きたアカウントではテクサポに入っておらず問い合わせるのにも時間がかかりそうな状態でしたので、やむを得ずAmazon RDS Blue/Green Deploymentsを用いない方法でアップグレードしました。
なぜGreen DBを作成できなくなっていたのか?
後日知った・気づいたことですが、
AWSからのメールに以下のように書いてあります
Green DBが作れなかった理由は、
MySQL 2.10 以前のバージョンで新しいクラスターを作成することはできません。
に引っかかっていたからでした。
1月の時点ではまだ新しいクラスターを作成することが可能な状態でしたが、
3月の時点では不可能な状態に変わっていたのです。
対処法
(作れた場合)早めにGreen DBを作っておいて切り替え当日まで消さずに残しておく
料金が気になる場合、Green DBのインスタンスサイズを下げるなどして節約する
(作れなかった場合)他の方法でDBをアップグレードする
しかなさそうです。
Fast DDLを利用したためpendingレコードが残っている状態になり、Green DBを作ろうとした際にprecheckでエラーになって作成できなかった
要約
これは、Aurora MySQLのDBをv2 → v3に上げようとした時の話です。
Amazon RDS Blue/Green DeploymentsでGreen DBを作ろうとしたが、Green DB作成時にprecheckでエラー。
ログにエラーメッセージがあった。Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>'
エラーメッセージで検索すると、repostがあった。
エラーメッセージとrepostの内容から、対象のテーブルにOPTIMIZE TABLE実行。
pendingレコードが消えて、Green DBが作成可能になった。
詳細
アップグレードに必要な諸々の検証が終わり、いざGreen DBを作ろうとしたら、下のエラーになってGreen DBを作成できませんでした。
2095 {
2096 "id": "auroraFODUpgradeCheck",
2097 "title": "Check for artifacts related to Aurora fast DDL feature",
2098 "status": "OK",
2099 "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
2100 "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
2101 "detectedProblems": [
2102 {
2103 "level": "Error",
2104 "dbObject": "(database).(table_name)",
2105 "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
2106 }
2107 ]
2108 },
DBへの変更を見てみると、Green DB作成作業の前日にFast DDLを利用したmigrationがおこなわれていました。
参考: Fast DDLについて
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html
今回は、エラーメッセージに
エラーになった理由と
対処法
も載っていたので、解決できそうです。
v3ではサポートしていないFast DDLの操作が途中になっているから
'OPTIMIZE TABLE <table name>' してください。
と言っているように見えます。
その辺りを調べていくと、repostにも記述がありました。
書いてあるように、INNODB_SYS_INDEXES_HISTORY を確認するとレコードがありました。
mysql> select * from INNODB_SYS_INDEXES_HISTORY;
+--------------+----------+---------+----------+------+----------+---------+-------+
| ALTER_LSN | INDEX_ID | NAME | TABLE_ID | TYPE | N_FIELDS | PAGE_NO | SPACE |
+--------------+----------+---------+----------+------+----------+---------+-------+
| 146105637324 | 1899 | PRIMARY | 697 | 3 | 1 | 3 | 674 |
| 146105648217 | 1899 | PRIMARY | 697 | 3 | 1 | 3 | 674 |
+--------------+----------+---------+----------+------+----------+---------+-------+
2 rows in set (0.02 sec)
mysql>
pendingなレコードがあることが確認できます。
そして、OPTIMIZE TABLE <table name>してみると…
(対象のテーブルが巨大だったため、4xlargeで7時間もかかりました)
mysql> select * from INNODB_SYS_INDEXES_HISTORY;
Empty set (0.13 sec)
pendingなレコードはなくなったようです。
再度Green DBを作成したところ、エラーなく作成されました。
まとめ
Amazon RDS Blue/Green Deployments について記事を書かせていただきました。
通常の利用においては基本的に順調にGreen DB作成→切り替えができるものだと思うのですが、
今回記載したような、うまくいかないパターンに遭遇することもあると思いましたので記事にしました。
少しでも皆様のお役に立つ内容になっていれば幸いです。
この記事が気に入ったらサポートをしてみませんか?