【バージョンアップ】Aurora MySQL8.0までの軌跡

## はじめに
思った通りに大変で険しい道のりだったので、記憶があるうちに備忘録として残しておきます。
MySQLのバージョンアップ対応をしようとしている皆様に少しでも役に立てばと思います！

もし何か間違っていることや、助言があればご指摘いただけると大変助かります！

## 対応した背景
MySQL 5.7のサポート期限が2024年2月（その後2024年10月に延期）まででした。
そのため、サポートが切れて想定外のエラーが発生・障害につながるのを防ぐためMySQL 8.0へのバージョンアップ対応を行いました。

#### ★エンジンとバージョンの詳細
<table>
  <thead>
    <tr>
      <th></th> <th>エンジン</th> <th>エンジンバージョン</th>
    </tr>
  </thead>
  <tr>
    <td> バージョンアップ前 </td> <td> Aurora MySQL </td> <td>5.7.mysql_aurora.2.11.1	</td>
  </tr>
  <tr>
    <td> バージョンアップ後 </td> <td> Aurora MySQL </td> <td>8.0.mysql_aurora.3.04.0</td>
  </tr>
</table>

## 大まかな対応手順

|  | 手順内容 |
|:-:|:-:|
| ① | テスト環境での手順確認を作成 |
| ② | テスト環境でMySQL8.0にする |
| ③ | ②ででた内容を修正 |
| ④ | 本番環境でRDSをクローンして検証 |
| ⑤ | ④の内容をもとに手順書を作成。 |
| ⑥ | 本番環境でバージョンアップ |
| ⑦ | 完了！！！ |

①～⑦までやりきるまでに約2カ月ほどかかりました。
下の軌跡にも書いてありますが、②のバージョンアップする方法の模索に一番時間を使いしました。

## MySQL8.0にバージョンアップするまでの軌跡

```mermaid
stateDiagram-v2
  [*] --> RDSからMySQLを5.7→8.0にバージョンアップしようとする
  RDSからMySQLを5.7→8.0にバージョンアップしようとする --> あるテーブル(huga)にFULLTEXTのINDEXがあることが上がらない原因だと、RDSのログを見て確認:バージョンアップに失敗する
  あるテーブル(huga)にFULLTEXTのINDEXがあることが上がらない原因だと、RDSのログを見て確認 --> いったんhugaをダンプし、hugaを消して入れなおす作業をして回避 
  いったんhugaをダンプし、hugaを消して入れなおす作業をして回避 --> 確かにMySQL8.0には上がった 
  確かにMySQL8.0には上がった--> 打開策を調べる: テーブルを入れ直す作業を本番環境ではやりたくない
  打開策を調べる--> innoDBをもう一回設定し直すと、INDEXが再設定されるので回避されるかも！
  innoDBをもう一回設定し直すと、INDEXが再設定されるので回避されるかも！-->無事MySQL8.0にバージョンアップ:ALTER TABLE hoge.huga ENGINE = InnoDB
```

## 上記軌跡をかいつまんで詳細を

### ★ あるテーブル(huga)にFULLTEXTのINDEXがあることが上がらない原因だと、RDSのログを見て確認
これのエラー内容は下記のようなエラーでした。

```jsonc
           {
            "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_ を再構築するだけでよかったみたいです。
```SQL
ALTER TABLE hoge.huga ENGINE = InnoDB
```
参照：https://dev.mysql.com/doc/refman/8.0/ja/innodb-file-defragmenting.html


## まとめ
この切り替え作業にあたり、2ヶ月前から検証期間を設けて、検証環境及び本番環境で**検証→確認→検証→確認**を繰り返しました。
このプロセスのおかげで、潜在的なバグが発生する可能性のある箇所を徹底的に洗い出すことができ、大きな不具合もなく対応完了することができました。

また**ブルーグリーンデプロイ**を活用することで、前回のバージョンアップの対応時間を約2時間から5分程度に短縮することができました。

バージョンアップ対応はどこかで必ずやらないといけない対応なので、少しでもこの記事が皆さんの参考になれば大変うれしく思います！