$30 off During Our Annual Pro Sale. View Details »

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

hmatsu47
September 22, 2023

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

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

hmatsu47

September 22, 2023
Tweet

More Decks by hmatsu47

Other Decks in Technology

Transcript

  1. 自己紹介 松久裕保(@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
  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
  3. 一段飛ばしのバージョンアップを選んだ理由 • 原則:1 バージョンずつ上げていくべき • 今回のケース ◦ 対象 DB を利用しているプロダクトの事情

    ◦ 「MySQL 8.0 の薄い本」の製作を通して得た知識があった  →加えて、Aurora MySQL v1 の EoL まで時間的な余裕があった 5
  4. 対象 DB を利用しているプロダクトの事情 • テストコードが実装されていない ◦ 手作業による詳細動作確認必須→手間がかかる ◦ 2 回バージョンアップ作業を行うのは(できれば)避けたい

    ▪ プロダクト開発の時間を確保したい ▪ 2 回に分ける→動作確認等の所要時間が合計 1.5 ~ 2 倍 【注】DB のバージョンアップ × 言語環境のバージョンアップのような    異種混合のバージョンアップ→より慎重に実施したほうが良い 6
  5. 「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
  6. あえて停止時間を設けてバージョンアップした理由 • 深夜の利用が少ない ◦ toB のプロダクトで利用 • データ不整合リスクの低減を優先 ◦ 停止時間のほとんど

    : データ比較の実行時間  →旧 DB 〜新 DB レプリケーションによりデータ比較以外の時間を短縮 ◦ Blue / Green できるように ◦ インプレースアップグレードより短い時間での切り替えが目標 8
  7. バージョンアップ時に直面した問題(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
  8. バージョンアップ時に直面した問題(3/5) • v1 〜 v2 〜 v3 の 2 段

    binlog レプリケーションで対応 12 変更 当初予定 実際 ※保証外
  9. バージョンアップ時に直面した問題(4/5) • MySQL Connector/J のバージョン問題 ◦ Java 用接続ライブラリ ◦ サーバー同様、8.0.x

    の x が変わると挙動が変わる ▪ 例 : 日付のキャスト処理や TLS 対応バージョンなど ▪ サーバーで Deprecated → MySQL Connector/J では先行 Removed が多い  →最新ではない少し古いバージョンに変更 13
  10. バージョンアップ時に直面した問題(5/5) • その他(主なものをピックアップ) ◦ テーブル全件 COUNT(*) の失速 ▪ https://zenn.dev/hmatsu47/articles/mysql80-count-slowdown ◦

    実行計画の変化 ▪ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ◦ 主キーなしテーブルの差分確認失敗 ◦ binlog レプリケーション設定変更時エラー ▪ サービス再開後にレプリケーション方向を変える際に発生(本番⇔ DR 間) 14
  11. Aurora MySQL をバージョンアップされる方へ(1/2) • 対象 DB の使われ方次第で「ハマるポイント」が変わる ◦ 概ね共通 ▪

    暗黙のソート順 ▪ デフォルト Collation の変更 ▪ TempTable エンジン・内部一時テーブル処理の変更(主に Reader) etc. ◦ 共通しない問題(意外と多い) ▪ 接続ライブラリ問題 ▪ レプリケーショントラブル ▪ 性能・サイジング etc.  →他社事例は参考程度に見る(自社プロダクトの状況を必ず確認する) 15
  12. 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
  13. まとめ • 状況に合ったバージョンアップ戦略を採用する ◦ デッドライン(EoL など)までの猶予期間と修正ボリューム ◦ プロダクト開発業務(新機能開発・機能改善など)とのバランス ◦ サービスの特性

    etc. • 他社事例は参考程度に見る ◦ 対象 DB の使われ方次第で「ハマるポイント」が変わる • Aurora MySQL v3 のバージョン間差異に注意 17