データベース移行のウラガワ - 円滑なリリースのために取り組んだ LT 2023/9/26
Aurora MySQL v1 から v3 へ一段飛ばしのバージョンアップをした話データベース移行のウラガワ- 円滑なリリースのために取り組んだ LT 2023/9/26まつひさ（hmatsu47）
View Slide
自己紹介松久裕保（@hmatsu47）● https://my.prairie.cards/u/hmatsu47● 名古屋で Web インフラのお守り係をしています○ SRE チーム所属○ 技術統括チームのお手伝い（フロントエンド・テストコード実装推進など）● かつて「MySQL 8.0 の薄い本」を作って配っていました○ 現在は GitHub リポジトリで印刷用データと Re:VIEW（3.0）原稿を公開中https://github.com/hmatsu47/mysql80_no_usui_hon2
本日お話しする内容（1/2）● 昨年（自社で）実施した DB バージョンアップについて○ 一段飛ばしのバージョンアップを選んだ理由○ あえて停止時間を設けてバージョンアップした理由○ バージョンアップ作業の流れ（列挙のみ）○ バージョンアップ時に直面した問題 → 詳細は Zenn で 2 冊の本にまとめてあります○ https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book○ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book3
本日お話しする内容（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 のバージョン間差異に注意 →サーバーのバージョンと同様、接続ライブラリのバージョンの違い にも注意する16Aurora バージョン MySQL バージョン 備考〜 3.02.x 8.0.23 一部キーワードは 8.0.263.03.x 8.0.26Deprecated temptable_use_mmapDeprecated TLS 1.0・1.1 support3.04.x 8.0.28Added tmp_table_sizeRemoved TLS 1.0・1.1 support
まとめ● 状況に合ったバージョンアップ戦略を採用する○ デッドライン（EoL など）までの猶予期間と修正ボリューム○ プロダクト開発業務（新機能開発・機能改善など）とのバランス○ サービスの特性 etc.● 他社事例は参考程度に見る○ 対象 DB の使われ方次第で「ハマるポイント」が変わる● Aurora MySQL v3 のバージョン間差異に注意17
hmatsu47
nwiizo
replu
lwug
mosa_siru
radkmb
mraible
masa5555
optimisuke
nishiuma
chiroito
bengo4com
muziyoshiz
paulrobertlloyd
cassininazir
yeseniaperezcruz
lemiorhan
morganepeng
revolveconf
lynnandtonic
reverentgeek
aarron
hannesfritz
thekraken
cherdarchuk