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
13
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
33
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
17
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
14
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
22
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
57
Other Decks in Technology
See All in Technology
dbt開発 with Claude Codeのためのガードレール設計
10xinc
2
1.3k
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
310
Agile PBL at New Grads Trainings
kawaguti
PRO
1
440
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
450
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.5k
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
220
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
540
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
260
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
270
「Linux」という言葉が指すもの
sat
PRO
4
140
Modern Linux
oracle4engineer
PRO
0
150
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
980
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Scaling GitHub
holman
463
140k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
The Invisible Side of Design
smashingmag
301
51k
Designing for Performance
lara
610
69k
Become a Pro
speakerdeck
PRO
29
5.5k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Navigating Team Friction
lara
189
15k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Music & Morning Musume
bryan
46
6.8k
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