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