Aurora MySQL v1 から v3 へ一段飛ばしのバージョンアップをした話

データベース移行のウラガワ - 円滑なリリースのために取り組んだ LT
2023/9/26

Transcript

1. Aurora MySQL v1 から v3 へ 一段飛ばしのバージョンアップをした話 データベース移行のウラガワ - 円滑なリリースのために取り組んだ LT 2023/9/26 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@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
3. 本日お話しする内容（1/2） • 昨年（自社で）実施した DB バージョンアップについて ◦ 一段飛ばしのバージョンアップを選んだ理由 ◦ あえて停止時間を設けてバージョンアップした理由 ◦ バージョンアップ作業の流れ（列挙のみ） ◦ バージョンアップ時に直面した問題 　→ 詳細は Zenn で 2 冊の本にまとめてあります ◦ https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book ◦ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book 3
4. 本日お話しする内容（2/2） • これから Aurora MySQL をバージョンアップされる方へ ◦ 対象 DB の使われ方次第で「ハマるポイント」が変わる ◦ Aurora MySQL v3 のバージョン間差異に気を付ける • まとめ 4
5. 一段飛ばしのバージョンアップを選んだ理由 • 原則：1 バージョンずつ上げていくべき • 今回のケース ◦ 対象 DB を利用しているプロダクトの事情 ◦ 「MySQL 8.0 の薄い本」の製作を通して得た知識があった 　→加えて、Aurora MySQL v1 の EoL まで時間的な余裕があった 5
6. 対象 DB を利用しているプロダクトの事情 • テストコードが実装されていない ◦ 手作業による詳細動作確認必須→手間がかかる ◦ 2 回バージョンアップ作業を行うのは（できれば）避けたい ▪ プロダクト開発の時間を確保したい ▪ 2 回に分ける→動作確認等の所要時間が合計 1.5 ～ 2 倍 【注】DB のバージョンアップ × 言語環境のバージョンアップのような 　　　異種混合のバージョンアップ→より慎重に実施したほうが良い 6
7. 「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
8. あえて停止時間を設けてバージョンアップした理由 • 深夜の利用が少ない ◦ toB のプロダクトで利用 • データ不整合リスクの低減を優先 ◦ 停止時間のほとんど : データ比較の実行時間 　→旧 DB 〜新 DB レプリケーションによりデータ比較以外の時間を短縮 ◦ Blue / Green できるように ◦ インプレースアップグレードより短い時間での切り替えが目標 8
9. バージョンアップ作業の流れ • 準備 ◦ 情報収集とアプリケーション修正の先行調査（SRE） ◦ アプリケーション修正（開発チーム全体） ◦ DB 切り替え作業計画・リハーサル・性能試験 • バージョンアップ ◦ 修正版アプリケーションリリース ◦ 旧 DB →新 DB 切り替え作業 9
10. バージョンアップ時に直面した問題（1/5） • 暗黙のソート順→不定に（昇順／降順が変化） ◦ ORDER BY がない、または列の指定が足りないケース ▪ GROUP BY ... ASC / DESC が廃止された影響も 　→ソート順の完全な再現は諦め、不具合にならない範囲で対応 10
11. バージョンアップ時に直面した問題（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
12. バージョンアップ時に直面した問題（3/5） • v1 〜 v2 〜 v3 の 2 段 binlog レプリケーションで対応 12 変更 当初予定 実際 ※保証外
13. バージョンアップ時に直面した問題（4/5） • MySQL Connector/J のバージョン問題 ◦ Java 用接続ライブラリ ◦ サーバー同様、8.0.x の x が変わると挙動が変わる ▪ 例 : 日付のキャスト処理や TLS 対応バージョンなど ▪ サーバーで Deprecated → MySQL Connector/J では先行 Removed が多い 　→最新ではない少し古いバージョンに変更 13
14. バージョンアップ時に直面した問題（5/5） • その他（主なものをピックアップ） ◦ テーブル全件 COUNT(*) の失速 ▪ https://zenn.dev/hmatsu47/articles/mysql80-count-slowdown ◦ 実行計画の変化 ▪ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ◦ 主キーなしテーブルの差分確認失敗 ◦ binlog レプリケーション設定変更時エラー ▪ サービス再開後にレプリケーション方向を変える際に発生（本番⇔ DR 間） 14
15. Aurora MySQL をバージョンアップされる方へ（1/2） • 対象 DB の使われ方次第で「ハマるポイント」が変わる ◦ 概ね共通 ▪ 暗黙のソート順 ▪ デフォルト Collation の変更 ▪ TempTable エンジン・内部一時テーブル処理の変更（主に Reader） etc. ◦ 共通しない問題（意外と多い） ▪ 接続ライブラリ問題 ▪ レプリケーショントラブル ▪ 性能・サイジング etc. 　→他社事例は参考程度に見る（自社プロダクトの状況を必ず確認する） 15
16. 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
17. まとめ • 状況に合ったバージョンアップ戦略を採用する ◦ デッドライン（EoL など）までの猶予期間と修正ボリューム ◦ プロダクト開発業務（新機能開発・機能改善など）とのバランス ◦ サービスの特性 etc. • 他社事例は参考程度に見る ◦ 対象 DB の使われ方次第で「ハマるポイント」が変わる • Aurora MySQL v3 のバージョン間差異に注意 17