はじめに
思った通りに大変で険しい道のりだったので、記憶があるうちに備忘録として残しておきます。
MySQLのバージョンアップ対応をしようとしている皆様に少しでも役に立てばと思います！
もし何か間違っていることや、助言があればご指摘いただけると大変助かります！
対応した背景
MySQL 5.7のサポート期限が2024年2月（その後2024年10月に延期）まででした。
そのため、サポートが切れて想定外のエラーが発生・障害につながるのを防ぐためMySQL 8.0へのバージョンアップ対応を行いました。
★エンジンとバージョンの詳細
| エンジン | エンジンバージョン | |
|---|---|---|
| バージョンアップ前 | Aurora MySQL | 5.7.mysql_aurora.2.11.1 |
| バージョンアップ後 | Aurora MySQL | 8.0.mysql_aurora.3.04.0 |
大まかな対応手順
| 手順内容 | |
|---|---|
| ① | テスト環境での手順確認を作成 |
| ② | テスト環境でMySQL8.0にする |
| ③ | ②ででた内容を修正 |
| ④ | 本番環境でRDSをクローンして検証 |
| ⑤ | ④の内容をもとに手順書を作成。 |
| ⑥ | 本番環境でバージョンアップ |
| ⑦ | 完了！！！ |
①～⑦までやりきるまでに約2カ月ほどかかりました。
下の軌跡にも書いてありますが、②のバージョンアップする方法の模索に一番時間を使いしました。
MySQL8.0にバージョンアップするまでの軌跡
上記軌跡をかいつまんで詳細を
★ あるテーブル(huga)にFULLTEXTのINDEXがあることが上がらない原因だと、RDSのログを見て確認
これのエラー内容は下記のようなエラーでした。
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "hoge.huga",
"description": " The auxiliary tables of FTS indexes on the table 'hoge.huga' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
}
※このエラーログはRDSのインスタンス＞ログとイベント＞ログの箇所で「upgrade-precheck.log」に記載されてます。
「description」の中に「To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.」とあるように FTS indexes をドロップするかテーブルを再構築するかとあります。
これが解決の糸口でした。
★innoDBをもう一回設定し直すと、INDEXが再設定されるので回避されるかも！
上記でも説明した通り、テーブル再構築って最初はつくりかえないといけないのかと思って、「テーブルを入れ直す作業」を行ったのですが、その必要はなく InnoDB を再構築するだけでよかったみたいです。
ALTER TABLE hoge.huga ENGINE = InnoDB
参照：https://dev.mysql.com/doc/refman/8.0/ja/innodb-file-defragmenting.html
まとめ
この切り替え作業にあたり、2ヶ月前から検証期間を設けて、検証環境及び本番環境で検証→確認→検証→確認を繰り返しました。
このプロセスのおかげで、潜在的なバグが発生する可能性のある箇所を徹底的に洗い出すことができ、大きな不具合もなく対応完了することができました。
またブルーグリーンデプロイを活用することで、前回のバージョンアップの対応時間を約2時間から5分程度に短縮することができました。
バージョンアップ対応はどこかで必ずやらないといけない対応なので、少しでもこの記事が皆さんの参考になれば大変うれしく思います！