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

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

Transcript

1. Aurora MySQL v1 → v3 の移行完了報告 JAWS-UG 浜松 AWS 勉強会 2022#10　2022/10/28 まつひさ（hmatsu47）
2. 本日のネタ（自己紹介は省略） • Aurora MySQL v1（5.6 互換）の EoL 発表が今年の 2 月 • 10 月、自社で使っていた Aurora MySQL を v3 に移行 • 移行で発生した問題やその解決についてまとめてみた 2
3. 移行の流れ（1/2） • 2022/2 〜 情報収集 • 2022/3 〜 手元での確認とまとめ • 2022/5 〜 アプリケーション修正の全社展開 • 2022/6 〜 移行手順の検討 • 2022/8 〜 リハーサル • 2022/9 〜 性能試験 3
4. 移行の流れ（2/2） • 2022/10 修正後アプリケーションのリリース • 2022/10 移行実施（深夜作業） 4
5. 全体については • Qiita の記事として投稿済み ◦ https://qiita.com/hmatsu47/items/ef48b8673f4775bef4a6 • Zenn の本も完成しました（10/28） ◦ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book 5
6. ポイント • ソート順の変化との戦い • MySQL Connector/J のバージョン間差異が曲者 • 移行手順を途中で変えざるをえない事態が発生 6
7. ポイント • ソート順の変化との戦い ◦ 諦めが大事 • MySQL Connector/J のバージョン間差異が曲者 ◦ 可能ならこれを先に解決しておくべきだったかも • 移行手順を途中で変えざるをえない事態が発生 ◦ 「非推奨」な手順の採用とリスクの受容 7
8. ソート順の変化 • ①GROUP BY あり ORDER BY なしのケース • ②ORDER BY はあってもソート順が一意ではないケース • ①＋②両者の複合ケース …全部洗い出して対処するのは困難なため、不具合に繋がるケース以外 　は一旦目をつぶる 8
9. ソート順の変化（そもそもコーディングに問題あり） • ①GROUP BY あり ORDER BY なしのケース • ②ORDER BY はあってもソート順が一意ではないケース • ①＋②両者の複合ケース …全部洗い出して対処するのは困難なため、不具合に繋がるケース以外 　は一旦目をつぶる 9
10. MySQL Connector/J のバージョン間差異 • 大半が作業終盤に発覚 ◦ 逆に、サーバ側の差異で終盤に問題になったのは 1 点のみ ▪ この点は事前の情報収集の成果？ • 一部はリリース後の不具合に繋がる …後から考えると MySQL Connector/J 変更に関する修正リリースを先に 　出しておけば良かった →今後移行に取り組む場合は参考にしてもらえると良いかも 10
11. 移行手順を急遽変更 • DMS（CDC）レプリケーション利用不可 ◦ https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch …非推奨だが Aurora MySQL v1 → v2 → v3 binlog レプリケーションに 　切り替え（実験で可能なことを確認） →移行本番で主キーのないテーブルの存在が発覚（後述）したので、 　結果として別の問題への発展を免れることができた 　（DMS CDC は主キーなしテーブル非サポート） 11
12. その他の問題点 • 性能が足りるか微妙… ◦ Reader 活用とスケールアップで対処 • データ整合確認で突然の不一致 ◦ 原因は「主キーのないテーブル」と「バッチ処理が終わらない」 • 作業時間延長で定時（cron）処理にトラブル発生 ◦ 意図しないタイミングで Web サーバが起動 12
13. 性能が足りるか微妙… • メインのクラスタをスケールアップ ◦ 移行前からバッファプール不足による速度低下が顕著化 ◦ スケールアップによって高負荷も速度低下も改善 • Reader を使っていなかったクラスタで Reader を使用 ◦ 従来はフェイルオーバー目的のみで Reader を配置していた ◦ アプリケーションから Reader を使うようにして Writer 負荷を 軽減 13
14. データ整合確認で突然の不一致 • 主キーなしテーブル→データダンプの出力順が不定に ◦ ダンプファイル細分化後の diff で発見 ◦ データ自体に差分がなさそうなことを確認 • バッチ処理が終わらずデータ更新が継続していた ◦ バッチ処理を中断 ◦ 必須の処理でなかったので後回しに ▪ データの差分も許容（後で修正しても問題なし） 14
15. 作業時間延長で定時（cron）処理にトラブル発生 • データ整合確認が予定より 30 分以上延長 • バッチ処理とは別の定時処理によって、それまで止めて いた Web サーバーが誤って起動 ◦ DB の旧→新切り替え作業中 …深夜・早朝作業のリスクとして頭に入れておくべき 15
16. ポイント（再掲） • ソート順の変化との戦い ◦ 諦めが大事 • MySQL Connector/J のバージョン間差異が曲者 ◦ 可能ならこれを先に解決しておくべきだったかも • 移行手順を途中で変えざるをえない事態が発生 ◦ 「非推奨」な手順の採用とリスクの受容 16
17. ポイント（再掲＋α） • ソート順の変化との戦い ◦ 諦めが大事 • MySQL Connector/J のバージョン間差異が曲者 ◦ 可能ならこれを先に解決しておくべきだったかも • 移行手順を途中で変えざるをえない事態が発生 ◦ 「非推奨」な手順の採用とリスクの受容 • 移行作業時のトラブル→起こりうるものとして備える 17
18. おまけ：深夜作業の是非 • 求められがち ◦ 特に無停止メンテが無理な場合（無停止メンテの場合でもよくある） • 事故のリスクが上がる ◦ 作業者の集中力・判断力低下 ◦ バッチ処理や定時処理とのバッティング回避の難しさ ▪ 停止・手動実行の順番とタイミング、実行回避の判断 …作業内容との兼ね合いで深夜作業にするのかを判断すべき 18