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
4
いろんなところに居る Amazon Q(Developer)を使い分けてみた
hmatsu47
PRO
0
24
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
12
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
29
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
16
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
13
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
22
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
56
Other Decks in Technology
See All in Technology
Vault を基盤として整備し、 みんなに使ってもらえるようになるまで
takahiko
1
110
Agile PBL at New Grads Trainings
kawaguti
PRO
1
330
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
1
160
Codeful Serverless / 一人運用でもやり抜く力
_kensh
6
340
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
3
470
ヘブンバーンズレッドのレンダリングパイプライン刷新
gree_tech
PRO
0
600
Webブラウザ向け動画配信プレイヤーの 大規模リプレイスから得た知見と学び
yud0uhu
0
210
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
2
150
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
1.4k
データアナリストからアナリティクスエンジニアになった話
hiyokko_data
2
430
テストを軸にした生き残り術
kworkdev
PRO
0
180
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
120
Featured
See All Featured
A designer walks into a library…
pauljervisheath
207
24k
Facilitating Awesome Meetings
lara
55
6.5k
Why Our Code Smells
bkeepers
PRO
339
57k
Unsuck your backbone
ammeep
671
58k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
What's in a price? How to price your products and services
michaelherold
246
12k
Art, The Web, and Tiny UX
lynnandtonic
302
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Fireside Chat
paigeccino
39
3.6k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
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