Aurora MySQL v1 → v3 移行で気を付けたほうが良いこと(7 つ + α)

29.9K Views

July 08, 22

スライド概要

JAWS ミート 〜Re:Born 東海道〜 2022/7/9

profile-image

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Aurora MySQL v1 → v3 移行で 気を付けたほうが良いこと (7 つ + α) JAWS ミート 〜Re:Born 東海道〜 2022/7/9 まつひさ(hmatsu47)

2.

自己紹介 松久裕保(@hmatsu47) ● https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っていました ○ https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ○ GitHub リポジトリの他、印刷版を BOOTH で配布していました ○ 2021/5 発行の 8.0.24 対応版を最後に更新停止しました 2

3.

本日のネタ ● 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

4.

Aurora MySQL v1 の EoL までの流れ(一応) ● 2022/9/27 : 新規クラスタ等作成停止 ○ 以下は(EoL まで)実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 など ● 2023/2/28 : EoL(予定)※時刻は 00:00:00 UTC 4

5.

v3 移行で気を付ける点 ● v1 → v2 と比べると結構たくさんある ● ただし本日は網羅的な話はしない ● 面倒なことになりやすい点だけピックアップ 5

6.

移行全体の話は Zenn の本で https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 6

7.

気を付ける点① 予約語 ● テーブル名・列名と被る場合→要バッククォート ● マイナーバージョンアップでも追加の可能性 ○ MySQL 8.0(Aurora MySQL v3 )から方針変更 ● ORM・クエリビルダの機能で対応可ならそれを 使ってバッククォート対応する 7

8.

気を付ける点② 結果の(暗黙)ソート ● GROUP BY … ASC/DESC 廃止 ○ GROUP BY & 同じ列を指定した ORDER BY と等価 ● GROUP BY(ORDER BY なし)ソート順不定 ○ 以前は GROUP BY … ASC と同じ結果に ● GROUP BY / ORDER BY 無指定 ○ 主キー順 or 使用インデックス順→本来は不定 8

9.

気を付ける点③ 一時テーブル ● 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

10.

気を付ける点④ 内部一時テーブル ● こちらは UNION の処理などで内部的に使われる 一時テーブルの話 ● CREATE TEMPORARY TABLE 同様、Reader での ディスク書き出し不可 ○ メモリ容量不足の恐れあり 10

11.

気を付ける点⑤ 接続用ライブラリ ● 公式 Connector と非公式ライブラリがある ● いずれにせよバージョンアップ時に挙動が変わる 可能性がある ○ 例:ON UPDATE CURRENT_TIMESTAMP 列に MySQL Connector/J にて null で更新→ OK だったのが NG に ■ explicit_defaults_for_timestamp 有効時 11

12.

気を付ける点⑥ レプリケーション(移行時) ● 3 バージョン間レプリケーション→サポート外に ○ MySQL 5.6 → 8.0 のレプリケーションも ● 切り戻し方向を考えれば移行は DMS 使用が妥当 ● DMS : time・float 列がそのままでは移行不可 ○ テーブルマッピングで該当列の型変換を個別指定する ■ 精度(桁数)指定ありの float は NG 12

13.

気を付ける点⑦ 管理系の情報 ● Information Schema / Performance Schema ○ MySQL 5.7 で sys スキーマ追加導入、8.0 で再編 ○ かなり変化しているので先の本でも対象外に ● 管理情報を使って自動化をしている場合は要注意 ○ 自動化していなくても情報の見方が変わる点に注意 ○ Performance Insights の待機イベントも変化 13

14.

おまけ : COUNT(*) が失速する New!! ● MySQL 8.0.14 から COUNT(*) が並列処理可に ● 実際には失速した ○ CPU 使用率が 100% に ■ でも Performance Insights では接続数分の負荷しかない謎 ○ バッファプールに載っているのに Disk 読んでる? ■ MySQL の既知の不具合っぽい挙動(本家では解決済み) 14

15.

番外 : 組織内ロストテクノロジー化 ● 注 : もちろん本来の意味ではない ● 近年、「メールが分かる」技術者が減少 ○ 雰囲気でメールを送受信している ● RDBMS についてもそれに近づきつつある ○ 技術を理解しているメンバー不在←つらい ■ 修正対応プロジェクトで割と話が伝わりづらい 15

16.

まとめ ● 結論:がんばりましょう ○ AWS と MySQL の知識の両方が必要です ○ くれぐれも無理はしないように ○ ノールックバージョンアップは、運が良ければ行ける かもしれませんが事故ると死にます 16