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 移行で 気を付けたほうが良いこと (7 つ + α)
Search
hmatsu47
PRO
July 08, 2022
Technology
0
2.5k
Aurora MySQL v1 → v3 移行で 気を付けたほうが良いこと (7 つ + α)
JAWS ミート 〜Re:Born 東海道〜 2022/7/9
hmatsu47
PRO
July 08, 2022
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
今年の FESTA で初当日スタッフ+登壇してきました
hmatsu47
PRO
0
6
攻略!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
4
PostgreSQL でもできる!GraphRAG
hmatsu47
PRO
0
2
Aurora DSQL のトランザクション(スナップショット分離と OCC)
hmatsu47
PRO
0
8
いろんなところに居る Amazon Q(Developer)を使い分けてみた
hmatsu47
PRO
0
25
「ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)」の結果ログから Aurora DSQL の動作を考察する
hmatsu47
PRO
0
2
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
33
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
47
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
Other Decks in Technology
See All in Technology
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.5k
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
フレームワークを意識させないワークショップづくり
keigosuda
0
210
OAuthからOIDCへ ― 認可の仕組みが認証に拡張されるまで
yamatai1212
0
140
LLMアプリの地上戦開発計画と運用実践 / 2025.10.15 GPU UNITE 2025
smiyawaki0820
1
670
FinOps について (ちょっと) 本気出して考えてみた
skmkzyk
0
170
データ戦略部門 紹介資料
sansan33
PRO
1
3.8k
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
220
大規模サーバーレスAPIの堅牢性・信頼性設計 〜AWSのベストプラクティスから始まる現実的制約との向き合い方〜
maimyyym
10
5k
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
240
Wasmのエコシステムを使った ツール作成方法
askua
0
220
現場データから見える、開発生産性の変化コード生成AI導入・運用のリアル〜 / Changes in Development Productivity and Operational Challenges Following the Introduction of Code Generation AI
nttcom
0
350
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Rails Girls Zürich Keynote
gr2m
95
14k
Six Lessons from altMBA
skipperchong
29
4k
Speed Design
sergeychernyshev
32
1.2k
Leading Effective Engineering Teams in the AI Era
addyosmani
7
500
Practical Orchestrator
shlominoach
190
11k
For a Future-Friendly Web
brad_frost
180
10k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
190
55k
Transcript
Aurora MySQL v1 → v3 移行で 気を付けたほうが良いこと (7 つ +
α) JAWS ミート 〜Re:Born 東海道〜 2022/7/9 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っていました
◦ https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を BOOTH で配布していました ◦ 2021/5 発行の 8.0.24 対応版を最後に更新停止しました 2
本日のネタ • Aurora MySQL v1(5.6 互換)EoL 発表 ◦ https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUs erGuide/Aurora.MySQL56.EOL.html
• 2023/2/28 までに v2 または v3 へ移行が必要 ◦ せっかく移行するなら v3 へ • ただいま移行に向けて作業中→気を付ける点は? 3
Aurora MySQL v1 の EoL までの流れ(一応) • 2022/9/27 : 新規クラスタ等作成停止
◦ 以下は(EoL まで)実行可能 ▪ v1 スナップショットの復元 ▪ クラスタにリードレプリカ追加 ▪ インスタンス設定変更 など • 2023/2/28 : EoL(予定)※時刻は 00:00:00 UTC 4
v3 移行で気を付ける点 • v1 → v2 と比べると結構たくさんある • ただし本日は網羅的な話はしない •
面倒なことになりやすい点だけピックアップ 5
https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 移行全体の話は Zenn の本で 6
気を付ける点① 予約語 • テーブル名・列名と被る場合→要バッククォート • マイナーバージョンアップでも追加の可能性 ◦ MySQL 8.0(Aurora MySQL
v3 )から方針変更 • ORM・クエリビルダの機能で対応可ならそれを 使ってバッククォート対応する 7
気を付ける点② 結果の(暗黙)ソート • GROUP BY … ASC/DESC 廃止 ◦ GROUP
BY & 同じ列を指定した ORDER BY と等価 • GROUP BY(ORDER BY なし)ソート順不定 ◦ 以前は GROUP BY … ASC と同じ結果に • GROUP BY / ORDER BY 無指定 ◦ 主キー順 or 使用インデックス順→本来は不定 8
気を付ける点③ 一時テーブル • CREATE TEMPORARY TABLE • Reader でディスクに書き出し不可 ◦
「ENGINE=」の指定に制約 ◦ 一時テーブル用メモリ容量不足の恐れ ◦ https://aws.amazon.com/jp/blogs/database/use-the-temptable-stor age-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/ 9
気を付ける点④ 内部一時テーブル • こちらは UNION の処理などで内部的に使われる 一時テーブルの話 • CREATE TEMPORARY
TABLE 同様、Reader での ディスク書き出し不可 ◦ メモリ容量不足の恐れあり 10
気を付ける点⑤ 接続用ライブラリ • 公式 Connector と非公式ライブラリがある • いずれにせよバージョンアップ時に挙動が変わる 可能性がある ◦
例:ON UPDATE CURRENT_TIMESTAMP 列に MySQL Connector/J にて null で更新→ OK だったのが NG に ▪ explicit_defaults_for_timestamp 有効時 11
気を付ける点⑥ レプリケーション(移行時) • 3 バージョン間レプリケーション→サポート外に ◦ MySQL 5.6 → 8.0
のレプリケーションも • 切り戻し方向を考えれば移行は DMS 使用が妥当 • DMS : time・float 列がそのままでは移行不可 ◦ テーブルマッピングで該当列の型変換を個別指定する ▪ 精度(桁数)指定ありの float は NG 12
気を付ける点⑦ 管理系の情報 • Information Schema / Performance Schema ◦ MySQL
5.7 で sys スキーマ追加導入、8.0 で再編 ◦ かなり変化しているので先の本でも対象外に • 管理情報を使って自動化をしている場合は要注意 ◦ 自動化していなくても情報の見方が変わる点に注意 ◦ Performance Insights の待機イベントも変化 13
おまけ : COUNT(*) が失速する New!! • MySQL 8.0.14 から COUNT(*)
が並列処理可に • 実際には失速した ◦ CPU 使用率が 100% に ▪ でも Performance Insights では接続数分の負荷しかない謎 ◦ バッファプールに載っているのに Disk 読んでる? ▪ MySQL の既知の不具合っぽい挙動(本家では解決済み) 14
番外 : 組織内ロストテクノロジー化 • 注 : もちろん本来の意味ではない • 近年、「メールが分かる」技術者が減少 ◦
雰囲気でメールを送受信している • RDBMS についてもそれに近づきつつある ◦ 技術を理解しているメンバー不在←つらい ▪ 修正対応プロジェクトで割と話が伝わりづらい 15
まとめ • 結論:がんばりましょう ◦ AWS と MySQL の知識の両方が必要です ◦ くれぐれも無理はしないように
◦ ノールックバージョンアップは、運が良ければ行ける かもしれませんが事故ると死にます 16