概要
タイトルの通り、先日Auroraのアップグレードを行ったので、備忘として残しておきます
作業の大枠としては、
- mysql8.0のRDSクラスターを新規作成
- メンテナンスを入れてアクセスを遮断
- データ移行
- アプリケーション側の接続先DBを変更
- mysql5.6のクラスターを削除
という手順で行いました
他にもバージョンを5.6→5.7→8.0と段階的に上げる方法もあるようなのですが、こちらはアプリ側の接続先を変えなくてもよいというメリットはあるのですが、アップグレード待ちの分メンテナンス時間が長くなります
それに対して上記の手順の場合はアップグレード作業当日の所要時間は短く済み、かつあらかじめデータ移行をしてテストも行うことができるというメリットがあります
クラスターの作成
バージョン8.0のクラスターを新規作成します。作成方法については一般的なRDS構築手順なので割愛します。
注意点として、パラメータグループはデフォルトのものをそのまま使うとパラメータを後から変更できないので、バージョン8.0用のパラメータグループを作成してアタッチする必要があります
インスタンス用とクラスター用でそれぞれ作成するので以下のようなイメージです
また、パラメータグループの差分についてはパラメータアクション→比較から確認することができます
データ移行
これはmysqldumpを使いました
データ量が多いとバックアップ/リストアでそれなりに時間がかかるので、なかなか終わらなくても不安にならず待ちましょう
またそれなりに負荷がかかるため、リードレプリカがある場合接続先エンドポイントはリーダーインスタンスとするのが良いでしょう
バックアップ
mysqldump -u USER_NAME -p -h CURRENT_HOST_NAME DB_NAME > OUTPUT_FILE_NAME
リストア
mysql -u USER_NAME -p -h NEW_HOST_NAME DB_NAME < OUTPUT_FILE_NAME
また、charasetやcollationがデータ移行前後で一致しているか確認しましょう
SHOW TABLE STATUS FROM DB_NAME;
# charaset変更（utf8mb4に変更する場合）
alter table TABLE_NAME default character set utf8mb4;
# collation変更（utf8mb4_general_ciに変更する場合）
alter table TABLE_NAME COLLATE 'utf8mb4_general_ci'
クラスターの削除
削除方法については一般的なRDS削除手順なので割愛します
筆者の場合は何か問題があった場合の切り分けやもしもの時の切り戻し用に一週間はインスタンスを稼働させておき、その後スナップショットを作成した上で削除しました
まとめ
手順としては意外とシンプルかなと思います
むしろアプリケーション側のテストをどこまでやるかが難しいところですね