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
1
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
12
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
12
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
11
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
6
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
16
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
32
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
30
ベクトルストア入門
hmatsu47
PRO
0
25
Other Decks in Technology
See All in Technology
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
4.7k
解析の定理証明実践@Lean 4
dec9ue
1
210
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
120
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
410
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
120
Backlog ユーザー棚卸しRTA、多分これが一番早いと思います
__allllllllez__
1
120
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
110
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
160
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
400
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
480
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
180
CursorによるPMO業務の代替 / Automating PMO Tasks with Cursor
motoyoshi_kakaku
2
870
Featured
See All Featured
Music & Morning Musume
bryan
46
6.6k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
How to train your dragon (web standard)
notwaldorf
94
6.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
GraphQLとの向き合い方2022年版
quramy
49
14k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
Designing for Performance
lara
610
69k
Raft: Consensus for Rubyists
vanstee
140
7k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
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