【Aurora】Mysql5.6から5.7へのバージョンアップについて

2022年3月1日に[RDS Mysql5.6のサポートが終了](https://aws.amazon.com/jp/blogs/news/amazon-rds-for-mysql-5-6-extending/)しました。

思いきってバージョンアップした方や、Auroraだからまだ大丈夫。。。
というプロダクトもいるかもしれません。

この辺りのサポートスケジュールやバージョンアップはどんな感じになりそうか？
また、5.6から5.7に上げるときに必要になるであろう対応について書いていこうと思います。

### mysqlの各バージョンのメンテ&サポート状況
5.6以下のバージョンは割愛させてもらっています。
RDSの時はサポート延長がありましたが、Auroraにそれを期待するのは難しそうですね。

| バージョン | リリース | メンテ期間 | RDS | Aurora |
|:-:|:-:|:-:|:-:|:-:|
| 8.0 | 2018/4/19  | 2026/4 | アナウンスなし |アナウンスなし|
| 5.7 | 2015/10/21  |2023/10 | アナウンスなし | アナウンスなし |
| 5.6 | 2013/2/5  | 2021/2/5 | 2022/3/1 | [2023/2/23 (予定)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html)|


#### 5.7のサポート状況＆予測
[RDS5.6ののサポート終了アナウンス](https://aws.amazon.com/jp/blogs/news/amazon-rds-for-mysql-5-6-retirement/)から推測するに、
5.7もコミュニティがメンテ終了する**2023年10月前後**にアナウンスがされる可能性が高いです(5.6のとき同様の猶予期間？猶予延長されるか？は未知数ですが)。


### バージョンアップに関して

#### Mysqlのメジャーバージョンアップは段階的に行う必要がある
Auroraで5.6を使っているプロダクトは、タイムリミットに向けて動きだす頃合いですね。

Mysqlはメジャーバージョンアップをする際は**1つ上のバージョンまで**しか上げられません。
つまり、5.6から8.0へいきなり移行はできず、5.6 => 5.7 => 8.0 と段階を踏む必要があります。

5.7に上げ作業が終わり次第すぐに8へ移行することもできなくはないようですが、
その分、移行計画はしっかり立てる必要となります。

#### Auroraでバージョンアップ時のインフラ対応が異なる
当たり前かもしれませんが、
RDSはインスタンス、Auroraはクラスターで構成されるサービスです。バージョンアップ時のバックアップ対応に行うレプリケーション方法が異なります。

RDSならリードレプリカ、Auroraならスナップショットかクローン
で複製したDBをバージョンアップし、切り替えることになります。

この辺り、下記AWSセミナーページ内の動画(*RDS for MySQL/Aurora MySQL upgrade (major/minor version up)**)でRDS、Auroraそれぞれの場合の対応について解説しています。

5.7、8.0それぞれの変更点の大枠も解説してくれているので、一度は見ておくといいですね。

https://aws.amazon.com/jp/blogs/news/amazon-rds-online-seminar-20210617/

#### 5.7へのバージョンアップ時の考慮・対応事項
公式が記載している内容からかいつまんで記載いきます。

https://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html

##### 日時カラムの内部構造変換に伴い、移行に時間がかかる可能性がある
ver5.6.4より`datetime`,`time`,`timestamp`が秒未満精度に対応しました。

ver5.6.4未満から5.7へアップグレードする際、新形式のテーブル作成するためにコピー処理が発生するため、テーブルサイズに応じた時間がかかることになります。

###### 事前に日時カラムを新形式に変更しておくこともできる
現在のテーブルが新旧どちらの形式かは下記SQLでチェックできます。
`CHECK TABLE table_A, table_B FOR UPGRADE;`

旧形式のカラムだった場合でも、[AWSのリファレンス](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html#USER_UpgradeDBInstance.MySQL.Major)新形式へ変換するクエリも記載されているので、バージョンアップの前準備として対応を検討するといいと思います。

#### デフォルトのSQLモードの変更
ver5.7.5からSQLモード設定
`STRICT_TRANS_TABLES`
`ONLY_FULL_GROUP_BY`
`NO_ENGINE_SUBSTITUTION`
が**デフォルトで有効**になります。

以下、それぞれについて簡単に見てみます。


##### [厳密なSQLモード](https://dev.mysql.com/doc/refman/8.0/ja/sql-mode.html#sqlmode_strict_trans_tables)
MysqlはNot nullableカラムに対して無効or欠落になるようなINSERT,UPDATE文が実行された時に値を調整してしまうことがありました(警告は出る)。
動的型付け言語でいうところ暗黙の型変換ですね。

```.sql
/*
name varchar 5 not null 
email varchar 255 not null 
verified_at timestamp not null 
*/

INSERT users(name, email, verified_at)
VALUES('hirohiro', 'email@gmail.com', '')

/*
 nameは 'hiroh' の5文字に切り詰め
 verified_atは'0000-00-00 00:00:00'に変換されてしまう
*/
```

厳密なSQLモードによっていい加減な登録・更新SQLを防げることになりますが、
なんだかんだうまいことやっていた箇所が**エラーで動かなくなる可能性**があります。

事前にSQLを修正するか、場合によってはバージョンアップ後にOFFにする必要があります。

ver5.6でも手動で厳密なSQLモードをONにして動作確認した上で、5.7へ上げる対応をするのも良さそうです。

https://qiita.com/park-jh/items/32b21d7b8d24b0ab3dba

#### [GROUP BYで未指定・未使用の非集計カラム参照クエリの拒否](https://dev.mysql.com/doc/refman/8.0/ja/sql-mode.html#sqlmode_only_full_group_by)

SELECT、HAVING、ORDER BYで、GROUP BY 句で指定されておらず、GROUP BY カラムに依存しない (一意に決定される) 非集計カラムを参照するクエリはエラーになります。

具体例はこちらを参照: [12.20.3 MySQL での GROUP BY の処理](https://dev.mysql.com/doc/refman/8.0/ja/group-by-handling.html)

#### [テーブル作成・変更時ストレージエンジンが利用できない時にエラー](https://dev.mysql.com/doc/refman/8.0/ja/sql-mode.html#sqlmode_no_engine_substitution)

CREATE TABLE、 ALTER TABLE などのSQLで無効だったりコンパイルされていないストレージエンジンを指定したときにエラーが発生しするようになります。

`NO_ENGINE_SUBSTITUTION`が無効の場合は警告の発生、CREATE TABLE についてはデフォルトエンジンが使用されてたりしてました。

今後テーブル定義する時に考慮すべきことなので、特に対応は必要なさそうです。

### 資料
[公式 Mysql](https://dev.mysql.com/)
[wikipedia Mysql](https://ja.wikipedia.org/wiki/MySQL)
[end of life]((https://endoflife.software/applications/databases/mysql))
[Amazon Aurora MySQL v1（5.6 互換）→ v3（8.0 互換）移行を計画する（1）はじめに](https://zenn.dev/hmatsu47/articles/aurora-mysql3-001-top)