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.5k
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
大人の社会科見学 ~ NTT 技術史料館に行ってみよう!
hmatsu47
PRO
0
260
pgvector 0.6.0 以降の進化についてざっくり取り上げてみる
hmatsu47
PRO
0
21
Cloudflare Workes からMySQL 系 DB への接続事情(2024/4 現在)
hmatsu47
PRO
0
44
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
62
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
82
Aurora MySQL 3.06 の ML 機能で Bedrock アクセスを試してみた
hmatsu47
PRO
0
68
RDS Data API と Aurora zero-ETL 統合と BuriKaigi2024 の話
hmatsu47
PRO
0
32
RDS Data API のその後と Aurora zero-ETL 統合のデータ転送処理の話
hmatsu47
PRO
0
80
RDS_Aurora 関連アップデート 2023 版
hmatsu47
PRO
0
82
Other Decks in Technology
See All in Technology
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
3
1.2k
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
720
「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing a System for Continuous Inquiry about where we are
daitasu
0
170
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
360
コンテナ・K8s研修 - 後半 Kubernetes 基礎&ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
1
120
Featured
See All Featured
Infographics Made Easy
chrislema
238
18k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
24
1.8k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
GraphQLとの向き合い方2022年版
quramy
36
13k
The Invisible Side of Design
smashingmag
294
50k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
4 Signs Your Business is Dying
shpigford
178
21k
Statistics for Hackers
jakevdp
792
220k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
19k
Clear Off the Table
cherdarchuk
89
320k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
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