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
September 30, 2022
Technology
0
2.5k
Aurora MySQL v1 → v3 移行の経過報告
JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30
hmatsu47
PRO
September 30, 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
AI駆動開発に向けた新しいエンジニアマインドセット
kazue
0
290
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
820
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
11
4.4k
2025年にHCP Vaultを学び直して見えた景色 / Lessons and New Perspectives from Relearning HCP Vault in 2025
aeonpeople
0
220
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
160
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.4k
Kiroと学ぶコンテキストエンジニアリング
oikon48
6
9.4k
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
160
dbt開発 with Claude Codeのためのガードレール設計
10xinc
1
710
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
11
1.1k
Kubernetes における cgroup driver のしくみ: runwasi の bugfix より
z63d
2
250
Agile PBL at New Grads Trainings
kawaguti
PRO
1
330
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Making Projects Easy
brettharned
117
6.4k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
13k
Transcript
Aurora MySQL v1 → v3 移行の経過報告 JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています 以前 MySQL 8.0
の薄い本を作って配っていました ◦ Qiita の記事: https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を BOOTH で配布していました ◦ 2021/5 発行の 8.0.24 対応版を最後に更新停止しました https://note.com/hmatsu47/n/n3ad586c31dce 2
2022/2、恐れていたことが現実に • Aurora MySQL v1(5.6 互換)の EoL が発表 ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.
MySQL56.EOL.html • 2023/2/28 までに v2 または v3 へ移行が必要 • AWS の「本気度」やいかに? ◦ よく EoL を土壇場で延期してるし 3
とはいえ放置は危険 • 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ◦ 注 : 以下は(EoL まで)実行可能
▪ v1 スナップショットの復元 ▪ クラスタにリードレプリカ追加 ▪ インスタンス設定変更 ▪ ポイントインタイムリカバリ(PITR) ▪ 既存 v1 クラスタのクローン作成 • 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 4
とはいえ放置は危険 • 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ◦ 注 : 以下は(EoL まで)実行可能
▪ v1 スナップショットの復元 ▪ クラスタにリードレプリカ追加 ▪ インスタンス設定変更 ▪ ポイントインタイムリカバリ(PITR) ▪ 既存 v1 クラスタのクローン作成 • 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 5
とはいえ放置は危険 • 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ◦ 注 : 以下は(EoL まで)実行可能
▪ v1 スナップショットの復元 ▪ クラスタにリードレプリカ追加 ▪ インスタンス設定変更 ▪ ポイントインタイムリカバリ(PITR) ▪ 既存 v1 クラスタのクローン作成 • 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 6
とはいえ放置は危険 • 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ◦ 作成できちゃいました!(9/30 朝時点で) 7
とはいえ放置は危険 • 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 8
Aurora MySQL v2 の EoL はどうなる? • Amazon Aurora メジャーバージョンが利用可能な期間
◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.V ersionPolicy.html#Aurora.VersionPolicy.MajorVersionLifetime ▪ 現時点の予定 : 2024/2/29 2024/10/31 に変わった模様(English) ▪ 延長される可能性はある • 本家 MySQL 5.7 の EoL : 2023/10/21 ◦ https://endoflife.software/applications/databases/mysql ▪ あと 1 年後 9
なので、 • せっかく移行するなら v3 へ • v3 移行に必要な情報を集めて Zenn で本にまとめた
…というのが計画編の話(2022/4) • 計画編に関する登壇 • JAWS-UG 朝会(4/11) • JAWS-UG 浜松(4/29) • その後、JAWS-UG 東海道でも(7/9) 10
本はこちら(計画編) https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 11
そして、本日のネタ • 主に 2022/5 以降の「実践」の場で ◦ 見つかった問題点 ◦ その回避策 …について触れていきます。
12
①ソート順が変わる、変わる、変わる… • MySQL 8.0.13 で GROUP BY … ASC/DESC 廃止
◦ GROUP BY … ASC/DESC が書かれたコードは無し ◦ が、「ASC」が省略された「暗黙の昇順」が多数発掘される • それ以前に MySQL 8.0 では ◦ ORDER BY の列指定が一意ではない部分のソート順が不定に ▪ 例:氏名列でソート→同姓同名の人のソート順が不定に ▪ 仕様上は従来も不定だったが「暗黙の了解としてのソート順」ががが 13
①ソート順が変わる、の解決策 • まずはコードでアタリをつける ◦ GROUP BY はあるが ORDER BY が無いコード
▪ 順序不定で OK な Map・Set に格納するものは除外 ◦ ORDER BY の列指定が一意にならないコード ▪ 意外に多数(全体の把握が困難) • 動作確認を頑張る ◦ つらい→致命的でないものは一旦対応を諦めることに 14
②接続ライブラリ(MySQL Connector/J)関連 • 地味に出てくる ◦ INSERT 直後に ROW_COUNT() が取れない(8.0.29) ◦
java.sql.ResultSet.getObject() 時の日付フォーマットが変化 ▪ 詳細不明だが 8.0.20 以降のどこかで秒が欠落 ▪ java.sql.Timestamp へのキャストでエラーに ◦ connectionCollation 無指定時の照合順序が変わる ▪ 8.0.25 以前はサーバー設定側文字セットのデフォルト照合順序 ▪ 8.0.26 以降は utf8mb4_0900_ai_ci →文字セットが utf8 だとエラーに 15
②接続ライブラリ関連、の解決策 (1) • INSERT 直後に ROW_COUNT() が取れない(8.0.29) ◦ MySQL Connector/J
8.0.28 にバージョンダウン ▪ 8.0.29 はサーバーも含めてバグが多いバージョン ▪ サーバーは途中で公開停止に 16
②接続ライブラリ関連、の解決策 (2) • java.sql.ResultSet.getObject() 時の日付フォーマット が変化 ◦ java.sql.ResultSet.getTimestamp() で直接取得 ▪
java.sql.ResultSet.getObject() からのキャストをやめた 17
②接続ライブラリ関連、の解決策 (3) • connectionCollation 無指定時の照合順序が変わる ◦ utf8(3 バイト)で処理する箇所に utf8mb4(4 バイト)の文
字が入らないように入力チェック等を強化 ◦ 必要な箇所には照合順序を明示的に指定 18
③性能問題 • 思っていたほどでは無かったが ◦ v2(MySQL 5.7)への移行でよく言及される大量 IN() 列挙 ▪ ほぼ無し
▪ ただしアーキテクチャの変化でほんのり遅くなった感も ◦ クエリの実行計画の変化 ▪ v1 と違う実行計画が選択された結果、かえって遅くなる ◦ CPU 使用率(やや)上昇 ▪ ただし 100% に到達してもすぐにはサチらなくなった? 19
③性能問題、の解決策 • 主に 3 つ ◦ オプティマイザヒントで実行計画を調整 ▪ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ◦
Reader インスタンスの活用 ▪ 読み取り負荷の分散 ◦ インスタンスタイプの変更(オプション) ▪ サイズを上げる(スケールアップ) ▪ 新しいタイプに変える(db.r5 → db.r6g・db.r6i) 20
④DMS(CDC)レプリケーションが使えない • DMS(CDC)レプリケーションで一部のデータが不正に ◦ 大きなサイズの BLOB 列レプリケーションの問題だった ▪ 2 ステップでのデータ移行になるので
ON UPDATE CURRENT_TIMESTAMP が指定されている TIMESTAMP / DATETIME 列の値が誤って上書きされてし まう ▪ https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch 21
④DMS レプリケーション問題、の解決策 • v1 → v2 → v3 の多段 binlog
レプリケーションで代用 ◦ サポート外(無保証)のやり方だが致し方なし ▪ そうしないとメンテナンス停止時間が長引いてしまう ▪ 1 週間程度のレプリケーションを 2 回繰り返しても問題は出なかった ◦ ON UPDATE CURRENT_TIMESTAMP を外す・無くす手も ▪ 一旦レプリケーション先で ON UPDATE CURRENT_TIMESTAMP を外してお いてレプリケーション終了後に付け直すか、アプリケーションを改修 ▪ どちらも難しかったので不採用 22
そしてついに • 来月半ばに v1 → v3 移行予定 ◦ 何も出ないことを祈ってください 23
まとめ • いろいろ出ました ◦ ソート順変わる問題 ◦ 接続ライブラリ(MySQL Connector/J)問題 ◦ 性能問題
◦ DMS レプリケーション使えない問題 • いよいよ来月半ばに移行予定です ◦ 何も出ないことを祈ってください 24