Aurora MySQL v1 → v3 移行完了報告

381 Views

October 28, 22

スライド概要

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

profile-image

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

埋め込む »CMSなどでJSが使えない場合

各ページのテキスト
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