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
いろんなところに居る Amazon Q(Developer)を使い分けてみた
hmatsu47
PRO
0
24
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
20
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
47
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
19
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
16
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
26
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
61
Other Decks in Technology
See All in Technology
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
430
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
600
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
shift_evolve
PRO
3
330
Why Governance Matters: The Key to Reducing Risk Without Slowing Down
sarahjwells
0
110
LLM時代にデータエンジニアの役割はどう変わるか?
ikkimiyazaki
4
780
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
330
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
1k
Trust as Infrastructure
bcantrill
0
350
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
150
自動テストのコストと向き合ってみた
qa
0
190
「Verify with Wallet API」を アプリに導入するために
hinakko
1
240
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
431
66k
How to train your dragon (web standard)
notwaldorf
96
6.3k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Become a Pro
speakerdeck
PRO
29
5.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
4 Signs Your Business is Dying
shpigford
185
22k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
The World Runs on Bad Software
bkeepers
PRO
71
11k
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