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 22, 2023
Technology
1
890
Aurora MySQL v1 から v3 へ一段飛ばしのバージョンアップをした話
データベース移行のウラガワ - 円滑なリリースのために取り組んだ LT
2023/9/26
hmatsu47
PRO
September 22, 2023
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
10
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
Aurora DSQL について
hmatsu47
PRO
0
29
Other Decks in Technology
See All in Technology
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
240
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
300
GitHub Copilot の概要
tomokusaba
1
150
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.2k
ドメイン特化なCLIPモデルとデータセットの紹介
tattaka
2
540
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
180
一体いつからSRE NEXTがSREだけのカンファレンスだと錯覚していた? / When did you ever get the idea that SRE NEXT was a conference just for SREs?
vtryo
1
130
怖くない!はじめてのClaude Code
shinya337
0
320
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
140
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
1.4k
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
2
8.2k
asken AI勉強会(Android)
tadashi_sato
0
150
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
331
24k
Typedesign – Prime Four
hannesfritz
42
2.7k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
What's in a price? How to price your products and services
michaelherold
246
12k
Docker and Python
trallard
44
3.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
940
It's Worth the Effort
3n
185
28k
How STYLIGHT went responsive
nonsquared
100
5.6k
Six Lessons from altMBA
skipperchong
28
3.9k
Designing for Performance
lara
609
69k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Transcript
Aurora MySQL v1 から v3 へ 一段飛ばしのバージョンアップをした話 データベース移行のウラガワ - 円滑なリリースのために取り組んだ
LT 2023/9/26 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) • https://my.prairie.cards/u/hmatsu47 • 名古屋で Web インフラのお守り係をしています ◦ SRE
チーム所属 ◦ 技術統括チームのお手伝い(フロントエンド・テストコード実装推進など) • かつて「MySQL 8.0 の薄い本」を作って配っていました ◦ 現在は GitHub リポジトリで印刷用データと Re:VIEW(3.0)原稿を公開中 https://github.com/hmatsu47/mysql80_no_usui_hon 2
本日お話しする内容(1/2) • 昨年(自社で)実施した DB バージョンアップについて ◦ 一段飛ばしのバージョンアップを選んだ理由 ◦ あえて停止時間を設けてバージョンアップした理由 ◦
バージョンアップ作業の流れ(列挙のみ) ◦ バージョンアップ時に直面した問題 → 詳細は Zenn で 2 冊の本にまとめてあります ◦ https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book ◦ https://zenn.dev/hmatsu47/books/aurora-mysql-do-book 3
本日お話しする内容(2/2) • これから Aurora MySQL をバージョンアップされる方へ ◦ 対象 DB の使われ方次第で「ハマるポイント」が変わる
◦ Aurora MySQL v3 のバージョン間差異に気を付ける • まとめ 4
一段飛ばしのバージョンアップを選んだ理由 • 原則:1 バージョンずつ上げていくべき • 今回のケース ◦ 対象 DB を利用しているプロダクトの事情
◦ 「MySQL 8.0 の薄い本」の製作を通して得た知識があった →加えて、Aurora MySQL v1 の EoL まで時間的な余裕があった 5
対象 DB を利用しているプロダクトの事情 • テストコードが実装されていない ◦ 手作業による詳細動作確認必須→手間がかかる ◦ 2 回バージョンアップ作業を行うのは(できれば)避けたい
▪ プロダクト開発の時間を確保したい ▪ 2 回に分ける→動作確認等の所要時間が合計 1.5 ~ 2 倍 【注】DB のバージョンアップ × 言語環境のバージョンアップのような 異種混合のバージョンアップ→より慎重に実施したほうが良い 6
「MySQL 8.0の薄い本」の製作(趣味の活動) • MySQL 8.0 の新機能・変更点のまとめ ◦ 利用例(サンプル) ◦ それを扱ったブログ記事等へのリンク
▪ https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d • MySQL 8.0 は継続提供モデル ◦ 8.0.x の x が進むと機能追加等がある → 8.0.15(試作版)から 8.0.24 まで製作 7
あえて停止時間を設けてバージョンアップした理由 • 深夜の利用が少ない ◦ toB のプロダクトで利用 • データ不整合リスクの低減を優先 ◦ 停止時間のほとんど
: データ比較の実行時間 →旧 DB 〜新 DB レプリケーションによりデータ比較以外の時間を短縮 ◦ Blue / Green できるように ◦ インプレースアップグレードより短い時間での切り替えが目標 8
バージョンアップ作業の流れ • 準備 ◦ 情報収集とアプリケーション修正の先行調査(SRE) ◦ アプリケーション修正(開発チーム全体) ◦ DB 切り替え作業計画・リハーサル・性能試験
• バージョンアップ ◦ 修正版アプリケーションリリース ◦ 旧 DB →新 DB 切り替え作業 9
バージョンアップ時に直面した問題(1/5) • 暗黙のソート順→不定に(昇順/降順が変化) ◦ ORDER BY がない、または列の指定が足りないケース ▪ GROUP BY
... ASC / DESC が廃止された影響も →ソート順の完全な再現は諦め、不具合にならない範囲で対応 10
バージョンアップ時に直面した問題(2/5) • DMS レプリケーションで一部の日時値が変化 ◦ DMS で MEDIUMBLOB / LONGBLOB
が 2 段階処理になる影響 ▪ ON UPDATE CURRENT_TIMESTAMP により日時値を現在時刻で上書き • https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch ◦ 旧 DB 〜新 DB を DMS レプリケーションする予定だった ▪ Aurora MySQL v1 〜 v3 の binlog レプリケーションは保証外 ▪ v1 〜 v2 〜 v3 の 2 段 binlog レプリケーションも保証外 11
バージョンアップ時に直面した問題(3/5) • v1 〜 v2 〜 v3 の 2 段
binlog レプリケーションで対応 12 変更 当初予定 実際 ※保証外
バージョンアップ時に直面した問題(4/5) • MySQL Connector/J のバージョン問題 ◦ Java 用接続ライブラリ ◦ サーバー同様、8.0.x
の x が変わると挙動が変わる ▪ 例 : 日付のキャスト処理や TLS 対応バージョンなど ▪ サーバーで Deprecated → MySQL Connector/J では先行 Removed が多い →最新ではない少し古いバージョンに変更 13
バージョンアップ時に直面した問題(5/5) • その他(主なものをピックアップ) ◦ テーブル全件 COUNT(*) の失速 ▪ https://zenn.dev/hmatsu47/articles/mysql80-count-slowdown ◦
実行計画の変化 ▪ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ◦ 主キーなしテーブルの差分確認失敗 ◦ binlog レプリケーション設定変更時エラー ▪ サービス再開後にレプリケーション方向を変える際に発生(本番⇔ DR 間) 14
Aurora MySQL をバージョンアップされる方へ(1/2) • 対象 DB の使われ方次第で「ハマるポイント」が変わる ◦ 概ね共通 ▪
暗黙のソート順 ▪ デフォルト Collation の変更 ▪ TempTable エンジン・内部一時テーブル処理の変更(主に Reader) etc. ◦ 共通しない問題(意外と多い) ▪ 接続ライブラリ問題 ▪ レプリケーショントラブル ▪ 性能・サイジング etc. →他社事例は参考程度に見る(自社プロダクトの状況を必ず確認する) 15
Aurora MySQL をバージョンアップされる方へ(2/2) • Aurora MySQL v3 のバージョン間差異に注意 →サーバーのバージョンと同様、接続ライブラリのバージョンの違い にも注意する
16 Aurora バージョン MySQL バージョン 備考 〜 3.02.x 8.0.23 一部キーワードは 8.0.26 3.03.x 8.0.26 Deprecated temptable_use_mmap Deprecated TLS 1.0・1.1 support 3.04.x 8.0.28 Added tmp_table_size Removed TLS 1.0・1.1 support
まとめ • 状況に合ったバージョンアップ戦略を採用する ◦ デッドライン(EoL など)までの猶予期間と修正ボリューム ◦ プロダクト開発業務(新機能開発・機能改善など)とのバランス ◦ サービスの特性
etc. • 他社事例は参考程度に見る ◦ 対象 DB の使われ方次第で「ハマるポイント」が変わる • Aurora MySQL v3 のバージョン間差異に注意 17