Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Aurora MySQL v1 → v3 の移行完了報告
Search
hmatsu47
PRO
October 28, 2022
Technology
1
1.9k
Aurora MySQL v1 → v3 の移行完了報告
JAWS-UG 浜松 AWS 勉強会 2022#10 2022/10/28
hmatsu47
PRO
October 28, 2022
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
7
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
17
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
14
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
12
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
7
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
17
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
32
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
31
ベクトルストア入門
hmatsu47
PRO
0
25
Other Decks in Technology
See All in Technology
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
500
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
myamashii
1
250
20250708オープンエンドな探索と知識発見
sakana_ai
PRO
3
570
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
54
22k
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
270
LLM時代の検索
shibuiwilliam
2
620
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
980
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
1
330
オフィスビルを監視しよう:フィジカル×デジタルにまたがるSLI/SLO設計と運用の難しさ / Monitoring Office Buildings: The Challenge of Physical-Digital SLI/SLO Design & Operation
bitkey
1
290
ゼロからはじめる採用広報
yutadayo
3
1k
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
230
公開初日に Gemini CLI を試した話や FFmpeg と組み合わせてみた話など / Gemini CLI 初学者勉強会(#AI道場)
you
PRO
0
860
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Code Review Best Practice
trishagee
69
19k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Agile that works and the tools we love
rasmusluckow
329
21k
A Tale of Four Properties
chriscoyier
160
23k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Typedesign – Prime Four
hannesfritz
42
2.7k
Embracing the Ebb and Flow
colly
86
4.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Transcript
Aurora MySQL v1 → v3 の移行完了報告 JAWS-UG 浜松 AWS 勉強会
2022#10 2022/10/28 まつひさ(hmatsu47)
本日のネタ(自己紹介は省略) • 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-book 5
ポイント • ソート順の変化との戦い • 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