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
9
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
17
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
14
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
12
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
7
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
17
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
33
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
31
ベクトルストア入門
hmatsu47
PRO
0
25
Other Decks in Technology
See All in Technology
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
290
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
5
2.2k
AI エージェントと考え直すデータ基盤
na0
18
7.3k
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
myamashii
1
340
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
200
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
1
250
CDK Toolkit Libraryにおけるテストの考え方
smt7174
1
460
[ JAWS-UG千葉支部 x 彩の国埼玉支部 ]ムダ遣い卒業!FinOpsで始めるAWSコスト最適化の第一歩
sh_fk2
2
150
CDK Vibe Coding Fes
tomoki10
1
540
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
470
Claude Code に プロジェクト管理やらせたみた
unson
8
4.9k
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7k
Featured
See All Featured
Designing for Performance
lara
610
69k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Typedesign – Prime Four
hannesfritz
42
2.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
How GitHub (no longer) Works
holman
314
140k
A Tale of Four Properties
chriscoyier
160
23k
Visualization
eitanlees
146
16k
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