2022年3月1日にRDS Mysql5.6のサポートが終了しました。

思いきってバージョンアップした方や、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 (予定)

5.7のサポート状況＆予測

RDS5.6ののサポート終了アナウンスから推測するに、
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それぞれの変更点の大枠も解説してくれているので、一度は見ておくといいですね。

5.7へのバージョンアップ時の考慮・対応事項

公式が記載している内容からかいつまんで記載いきます。

日時カラムの内部構造変換に伴い、移行に時間がかかる可能性がある

ver5.6.4よりdatetime,time,timestampが秒未満精度に対応しました。

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

事前に日時カラムを新形式に変更しておくこともできる

現在のテーブルが新旧どちらの形式かは下記SQLでチェックできます。
CHECK TABLE table_A, table_B FOR UPGRADE;

旧形式のカラムだった場合でも、AWSのリファレンス新形式へ変換するクエリも記載されているので、バージョンアップの前準備として対応を検討するといいと思います。

デフォルトのSQLモードの変更

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

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

厳密なSQLモード

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へ上げる対応をするのも良さそうです。

GROUP BYで未指定・未使用の非集計カラム参照クエリの拒否

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

具体例はこちらを参照: 12.20.3 MySQL での GROUP BY の処理

テーブル作成・変更時ストレージエンジンが利用できない時にエラー

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

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

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

資料

公式 Mysql
wikipedia Mysql
end of life
Amazon Aurora MySQL v1（5.6 互換）→ v3（8.0 互換）移行を計画する（1）はじめに