こんにちは。クイックSREチームのみっちーです。

過日、AWSよりRDS Aurora MySQL 各Versionのサポート終了期限が公表されました。 ※ 『Aurora Version 1.x（MySQL5.6互換）』は、2023年2月28日に終了しています。　『Aurora Version 2.x（MySQL5.7互換）』は、2024年10月31日にサポート終了となります。

現在クイックで運用しているシステムでは『Aurora Version 2.x（MySQL5.7互換）』を主軸としていますが、一部で『Aurora Version 1.x（MySQL5.6互換）』も利用している状況でした。
このため『Aurora Version 1.x（MySQL5.6互換）』の環境を優先してアップグレードし、先日無事にすべて完了しました。

ここで得たノウハウは、今後予定している『Aurora Version 2.x（MySQL5.7互換）』から『Aurora Version 3.x（MySQL8.0互換）』へのアップグレード対応でも活用できると感じているため、これを機にまとめました。

特に、MySQL8.0ではクエリキャッシュが廃止されるなど。変更点が多いことは事前に確認していましたが、それでも事前に確認しきれなかった部分がありました。
※ 今回は、その点を中心にまとめています。

クイック内での今後のアップグレード作業だけでなく、同様の作業を計画中のみなさまに少しでもお役に立てば幸いです。

はじめに（この記事のターゲット）
クイックで行ったアップグレード作業の流れ
ポイントと対応
- アップグレード作業編
  - MySQLコミュニティエディションとのsql_modeの差分
  - アップグレードに伴うサービス停止時間の短縮
- 運用編
  - temporary table の初期挙動の変化

はじめに（この記事のターゲット）

この記事で想定しているターゲットは以下の通りです。

MySQL（コミュニティエディション、Aurora MySQL互換等）の運用経験が半年以上ある方
MySQL8.0、Aurora Version 3.x（MySQL8.0互換）のリリースノートの概要を把握されている方
RDS Aurora MySQLのアップグレード方法（インプレースアップグレード）の概要を把握されている方
- docs.aws.amazon.com
- docs.aws.amazon.com

クイックで行ったアップグレード作業の流れ

クイックでは、AWSの公式ドキュメントに記載されている手順（インプレースアップグレード）ではなく、以下の方法で行いました。
※ アップグレード前：『Aurora Version 1.x（MySQL5.6互換）』、アップグレード後：『Aurora Version 3.x（MySQL8.0互換）』

MySQL8.0コミュニティエディションのdockerコンテナをダウンロードし、手元で検証を実施
検証結果に基づいて、『Aurora Version 1.x（MySQL5.6互換）』クラスターの本番データを修正
『Aurora Version 3.x（MySQL8.0互換）』クラスターを新規構築
『Aurora Version 1.x（MySQL5.6互換）』クラスターからmysqldump でデータを抽出
『Aurora Version 3.x（MySQL8.0互換）』クラスターへ restoreを実施
運用開始

この手順とした理由は、
過去の同様の作業経験と今回対象となったサービスのデータ量の関係で、
インプレースアップグレードではサービス停止時間が非常に長い（検証では数日かかりました）ことに起因します。

今回はmysqldump & restoreの手順を利用し、サービス停止は2時間程度に抑えることができました。

ポイントと対応

アップグレード作業編

MySQLコミュニティエディションとのsql_modeの差分

まずはじめに、MySQL8.0コミュニティエディションのdockerコンテナをダウンロードし、検証を実施しました。

その際、MySQL8.0コミュニティエディションとAurora Version 3.x（MySQL8.0互換）とはいくつかの相違点があることが判明していますが、
中でも運用上の影響が大きそうな以下については、『Aurora Version 3.x（MySQL8.0互換）』の設定を正として、検証用dockerコンテナの設定を修正する対応を行いました。

sql_mode の差分

# Aurora Version 3.x 
sql_mode = 0

# MySQL8.0コミュニティエディション
sql_mode = NLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION

※ 運用（開発）をしていく上でバグや検証コストの増加につながる可能性があるため、埋めておくと良いと考えています。

アップグレードに伴うサービス停止時間の短縮

今回はサービス停止時間を抑えるためにmysqldump & restoreの方法を利用しましたが、
バイナリレプリケーション方式とすることでリリースタイミングでレプリケーションを停止し、接続先エンドポイントを切り替える程度でリリースが行えることがわかりました。
それにより、今回の方法よりも停止時間を短縮できたものと考えています。
※ このことは作業後の反省会で気づきました。

なおバイナリレプリケーション方式にするには、事前にいくつかの準備が必要です。
詳細は以下をご確認ください。
docs.aws.amazon.com

運用編

temporary table の初期挙動の変化

MySQL8.0からtemporary tableの作成処理が、「Memory storage engine」から「TempTable storage engine」へ変更されました。
これによりtemporary tableの挙動が変更となっており、クエリによっては動作不具合となる可能性がある部分です。

クエリ自体の軽量化ができれば良いですが、難しい場合にはこちらも有効打と考えています。
※ 『Aurora Version 3.x（MySQL8.0互換）』も同様です。

temporary tableを利用するクエリの実行例

SELECT user_xxx … GROUP BY … GROUP BY … INNER JOIN > user_xxx.count) WHERE (user_xxx_id) IS NULL ORDER BY user_xxx_id

MySQL5.7（Aurora Version 2.x）まで

Memory storage engine では、『tmp_table_size』と『max_heap_table_size』で調整する。

MySQL8.0（Aurora Version 3.x）

TempTable storage engine では、『temptable_max_ram』パラメータで調整する。
もしくは、Memory storage engine へ変更し、『tmp_table_size』と『max_heap_table_size』で調整する。

以上です。

最後までお付き合いいただきありがとうございました。
私たちと一緒にクイックの事業発展・拡大にチャレンジしたい方をお待ちしております！

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

クイックエンジニアリングブログ

株式会社クイック Web事業企画開発本部のエンジニアリングチームが運営する技術ブログです。

AWS RDS 『Aurora Version 3.x（MySQL8.0互換）』導入時のノウハウ