Aurora MySQL v1 から v3 へ 一段飛ばしのバージョンアップをした話 データベース移行のウラガワ - 円滑なリリースのために取り組んだ LT 2023/9/26 まつひさ（hmatsu47） 

自己紹介 松久裕保（@hmatsu47） ● https://my.prairie.cards/u/hmatsu47 ● 名古屋で Web インフラのお守り係をしています ○ SRE チーム所属 ○ 技術統括チームのお手伝い（フロントエンド・テストコード実装推進など） ● かつて「MySQL 8.0 の薄い本」を作って配っていました ○ 現在は GitHub リポジトリで印刷用データと Re:VIEW（3.0）原稿を公開中 https://github.com/hmatsu47/mysql80_no_usui_hon 2 

本日お話しする内容（1/2） ● 昨年（自社で）実施した DB バージョンアップについて ○ 一段飛ばしのバージョンアップを選んだ理由 ○ あえて停止時間を設けてバージョンアップした理由 ○ バージョンアップ作業の流れ（列挙のみ） ○ バージョンアップ時に直面した問題 　→ 詳細は Zenn で 2 冊の本にまとめてあります ○ https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book ○ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book 3 

本日お話しする内容（2/2） ● これから Aurora MySQL をバージョンアップされる方へ ○ 対象 DB の使われ方次第で「ハマるポイント」が変わる ○ Aurora MySQL v3 のバージョン間差異に気を付ける ● まとめ 4 

一段飛ばしのバージョンアップを選んだ理由 ● 原則：1 バージョンずつ上げていくべき ● 今回のケース ○ 対象 DB を利用しているプロダクトの事情 ○ 「MySQL 8.0 の薄い本」の製作を通して得た知識があった 　→加えて、Aurora MySQL v1 の EoL まで時間的な余裕があった 5 

対象 DB を利用しているプロダクトの事情 ● テストコードが実装されていない ○ 手作業による詳細動作確認必須→手間がかかる ○ 2 回バージョンアップ作業を行うのは（できれば）避けたい ■ プロダクト開発の時間を確保したい ■ 2 回に分ける→動作確認等の所要時間が合計 1.5 ～ 2 倍 【注】DB のバージョンアップ × 言語環境のバージョンアップのような 　　　異種混合のバージョンアップ→より慎重に実施したほうが良い 6 

「MySQL 8.0の薄い本」の製作（趣味の活動） ● MySQL 8.0 の新機能・変更点のまとめ ○ 利用例（サンプル） ○ それを扱ったブログ記事等へのリンク ■ https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ● MySQL 8.0 は継続提供モデル ○ 8.0.x の x が進むと機能追加等がある 　→ 8.0.15（試作版）から 8.0.24 まで製作 7 

あえて停止時間を設けてバージョンアップした理由 ● 深夜の利用が少ない ○ toB のプロダクトで利用 ● データ不整合リスクの低減を優先 ○ 停止時間のほとんど : データ比較の実行時間 　→旧 DB 〜新 DB レプリケーションによりデータ比較以外の時間を短縮 ○ Blue / Green できるように ○ インプレースアップグレードより短い時間での切り替えが目標 8 

バージョンアップ作業の流れ ● 準備 ○ 情報収集とアプリケーション修正の先行調査（SRE） ○ アプリケーション修正（開発チーム全体） ○ DB 切り替え作業計画・リハーサル・性能試験 ● バージョンアップ ○ 修正版アプリケーションリリース ○ 旧 DB →新 DB 切り替え作業 9 

バージョンアップ時に直面した問題（1/5） ● 暗黙のソート順→不定に（昇順／降順が変化） ○ ORDER BY がない、または列の指定が足りないケース ■ GROUP BY ... ASC / DESC が廃止された影響も 　→ソート順の完全な再現は諦め、不具合にならない範囲で対応 10 

バージョンアップ時に直面した問題（2/5） ● DMS レプリケーションで一部の日時値が変化 ○ DMS で MEDIUMBLOB / LONGBLOB が 2 段階処理になる影響 ■ ON UPDATE CURRENT_TIMESTAMP により日時値を現在時刻で上書き ● https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch ○ 旧 DB 〜新 DB を DMS レプリケーションする予定だった ■ Aurora MySQL v1 〜 v3 の binlog レプリケーションは保証外 ■ v1 〜 v2 〜 v3 の 2 段 binlog レプリケーションも保証外 11 

バージョンアップ時に直面した問題（3/5） ● v1 〜 v2 〜 v3 の 2 段 binlog レプリケーションで対応 12 変更 当初予定 実際 ※保証外 

バージョンアップ時に直面した問題（4/5） ● MySQL Connector/J のバージョン問題 ○ Java 用接続ライブラリ ○ サーバー同様、8.0.x の x が変わると挙動が変わる ■ 例 : 日付のキャスト処理や TLS 対応バージョンなど ■ サーバーで Deprecated → MySQL Connector/J では先行 Removed が多い 　→最新ではない少し古いバージョンに変更 13 

バージョンアップ時に直面した問題（5/5） ● その他（主なものをピックアップ） ○ テーブル全件 COUNT(*) の失速 ■ https://zenn.dev/hmatsu47/articles/mysql80-count-slowdown ○ 実行計画の変化 ■ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ○ 主キーなしテーブルの差分確認失敗 ○ binlog レプリケーション設定変更時エラー ■ サービス再開後にレプリケーション方向を変える際に発生（本番⇔ DR 間） 14 

Aurora MySQL をバージョンアップされる方へ（1/2） ● 対象 DB の使われ方次第で「ハマるポイント」が変わる ○ 概ね共通 ■ 暗黙のソート順 ■ デフォルト Collation の変更 ■ TempTable エンジン・内部一時テーブル処理の変更（主に Reader） etc. ○ 共通しない問題（意外と多い） ■ 接続ライブラリ問題 ■ レプリケーショントラブル ■ 性能・サイジング etc. 　→他社事例は参考程度に見る（自社プロダクトの状況を必ず確認する） 15 

Aurora MySQL をバージョンアップされる方へ（2/2） ● Aurora MySQL v3 のバージョン間差異に注意 　→サーバーのバージョンと同様、接続ライブラリのバージョンの違い 　　にも注意する 16 Aurora バージョン MySQL バージョン 備考 〜 3.02.x 　 8.0.23 一部キーワードは 8.0.26 3.03.x 8.0.26 Deprecated temptable_use_mmap Deprecated TLS 1.0・1.1 support 3.04.x 8.0.28 Added tmp_table_size Removed TLS 1.0・1.1 support 

まとめ ● 状況に合ったバージョンアップ戦略を採用する ○ デッドライン（EoL など）までの猶予期間と修正ボリューム ○ プロダクト開発業務（新機能開発・機能改善など）とのバランス ○ サービスの特性 etc. ● 他社事例は参考程度に見る ○ 対象 DB の使われ方次第で「ハマるポイント」が変わる ● Aurora MySQL v3 のバージョン間差異に注意 17