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

Transcript

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

   View Slide

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
   

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide