Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Aurora MySQL v1 → v3 の移行完了報告

Aurora MySQL v1 → v3 の移行完了報告

JAWS-UG 浜松 AWS 勉強会 2022#10 2022/10/28

hmatsu47
PRO

October 28, 2022
Tweet

More Decks by hmatsu47

Other Decks in Technology

Transcript

  1. Aurora MySQL v1 → v3 の移行完了報告
    JAWS-UG 浜松 AWS 勉強会 2022#10 2022/10/28
    まつひさ(hmatsu47)

    View Slide

  2. 本日のネタ(自己紹介は省略)
    ● Aurora MySQL v1(5.6 互換)の EoL 発表が今年の 2 月
    ● 10 月、自社で使っていた Aurora MySQL を v3 に移行
    ● 移行で発生した問題やその解決についてまとめてみた
    2

    View Slide

  3. 移行の流れ(1/2)
    ● 2022/2 〜 情報収集
    ● 2022/3 〜 手元での確認とまとめ
    ● 2022/5 〜 アプリケーション修正の全社展開
    ● 2022/6 〜 移行手順の検討
    ● 2022/8 〜 リハーサル
    ● 2022/9 〜 性能試験
    3

    View Slide

  4. 移行の流れ(2/2)
    ● 2022/10 修正後アプリケーションのリリース
    ● 2022/10 移行実施(深夜作業)
    4

    View Slide

  5. 全体については
    ● Qiita の記事として投稿済み
    ○ https://qiita.com/hmatsu47/items/ef48b8673f4775bef4a6
    ● Zenn の本も完成しました(10/28)
    ○ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book
    5

    View Slide

  6. ポイント
    ● ソート順の変化との戦い
    ● MySQL Connector/J のバージョン間差異が曲者
    ● 移行手順を途中で変えざるをえない事態が発生
    6

    View Slide

  7. ポイント
    ● ソート順の変化との戦い
    ○ 諦めが大事
    ● MySQL Connector/J のバージョン間差異が曲者
    ○ 可能ならこれを先に解決しておくべきだったかも
    ● 移行手順を途中で変えざるをえない事態が発生
    ○ 「非推奨」な手順の採用とリスクの受容
    7

    View Slide

  8. ソート順の変化
    ● ①GROUP BY あり ORDER BY なしのケース
    ● ②ORDER BY はあってもソート順が一意ではないケース
    ● ①+②両者の複合ケース
    …全部洗い出して対処するのは困難なため、不具合に繋がるケース以外
     は一旦目をつぶる
    8

    View Slide

  9. ソート順の変化(そもそもコーディングに問題あり)
    ● ①GROUP BY あり ORDER BY なしのケース
    ● ②ORDER BY はあってもソート順が一意ではないケース
    ● ①+②両者の複合ケース
    …全部洗い出して対処するのは困難なため、不具合に繋がるケース以外
     は一旦目をつぶる
    9

    View Slide

  10. MySQL Connector/J のバージョン間差異
    ● 大半が作業終盤に発覚
    ○ 逆に、サーバ側の差異で終盤に問題になったのは 1 点のみ
    ■ この点は事前の情報収集の成果?
    ● 一部はリリース後の不具合に繋がる
    …後から考えると MySQL Connector/J 変更に関する修正リリースを先に
     出しておけば良かった
    →今後移行に取り組む場合は参考にしてもらえると良いかも
    10

    View Slide

  11. 移行手順を急遽変更
    ● DMS(CDC)レプリケーション利用不可
    ○ https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch
    …非推奨だが Aurora MySQL v1 → v2 → v3 binlog レプリケーションに
     切り替え(実験で可能なことを確認)
    →移行本番で主キーのないテーブルの存在が発覚(後述)したので、
     結果として別の問題への発展を免れることができた
     (DMS CDC は主キーなしテーブル非サポート)
    11

    View Slide

  12. その他の問題点
    ● 性能が足りるか微妙…
    ○ Reader 活用とスケールアップで対処
    ● データ整合確認で突然の不一致
    ○ 原因は「主キーのないテーブル」と「バッチ処理が終わらない」
    ● 作業時間延長で定時(cron)処理にトラブル発生
    ○ 意図しないタイミングで Web サーバが起動
    12

    View Slide

  13. 性能が足りるか微妙…
    ● メインのクラスタをスケールアップ
    ○ 移行前からバッファプール不足による速度低下が顕著化
    ○ スケールアップによって高負荷も速度低下も改善
    ● Reader を使っていなかったクラスタで Reader を使用
    ○ 従来はフェイルオーバー目的のみで Reader を配置していた
    ○ アプリケーションから Reader を使うようにして Writer 負荷を
    軽減
    13

    View Slide

  14. データ整合確認で突然の不一致
    ● 主キーなしテーブル→データダンプの出力順が不定に
    ○ ダンプファイル細分化後の diff で発見
    ○ データ自体に差分がなさそうなことを確認
    ● バッチ処理が終わらずデータ更新が継続していた
    ○ バッチ処理を中断
    ○ 必須の処理でなかったので後回しに
    ■ データの差分も許容(後で修正しても問題なし)
    14

    View Slide

  15. 作業時間延長で定時(cron)処理にトラブル発生
    ● データ整合確認が予定より 30 分以上延長
    ● バッチ処理とは別の定時処理によって、それまで止めて
    いた Web サーバーが誤って起動
    ○ DB の旧→新切り替え作業中
    …深夜・早朝作業のリスクとして頭に入れておくべき
    15

    View Slide

  16. ポイント(再掲)
    ● ソート順の変化との戦い
    ○ 諦めが大事
    ● MySQL Connector/J のバージョン間差異が曲者
    ○ 可能ならこれを先に解決しておくべきだったかも
    ● 移行手順を途中で変えざるをえない事態が発生
    ○ 「非推奨」な手順の採用とリスクの受容
    16

    View Slide

  17. ポイント(再掲+α)
    ● ソート順の変化との戦い
    ○ 諦めが大事
    ● MySQL Connector/J のバージョン間差異が曲者
    ○ 可能ならこれを先に解決しておくべきだったかも
    ● 移行手順を途中で変えざるをえない事態が発生
    ○ 「非推奨」な手順の採用とリスクの受容
    ● 移行作業時のトラブル→起こりうるものとして備える
    17

    View Slide

  18. おまけ:深夜作業の是非
    ● 求められがち
    ○ 特に無停止メンテが無理な場合(無停止メンテの場合でもよくある)
    ● 事故のリスクが上がる
    ○ 作業者の集中力・判断力低下
    ○ バッチ処理や定時処理とのバッティング回避の難しさ
    ■ 停止・手動実行の順番とタイミング、実行回避の判断
    …作業内容との兼ね合いで深夜作業にするのかを判断すべき
    18

    View Slide