Aurora MySQL v1→v3移行の経過報告

869 Views

September 30, 22

スライド概要

JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30

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

シェア

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

各ページのテキスト
1.

Aurora MySQL v1 → v3 移行の経過報告 JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30 まつひさ(hmatsu47)

2.

自己紹介 松久裕保(@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

3.

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

4.

とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は(EoL まで)実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ(PITR) ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 4

5.

とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は(EoL まで)実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ(PITR) ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 5

6.

とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は(EoL まで)実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ(PITR) ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 6

7.

とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 作成できちゃいました!(9/30 朝時点で) 7

8.

とはいえ放置は危険 ● 2023/2/28 : EoL(予定)※時刻はいずれも 00:00:00 UTC 8

9.

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

10.

なので、 ● せっかく移行するなら v3 へ ● v3 移行に必要な情報を集めて Zenn で本にまとめた …というのが計画編の話(2022/4) ● 計画編に関する登壇 ● JAWS-UG 朝会(4/11) ● JAWS-UG 浜松(4/29) ● その後、JAWS-UG 東海道でも(7/9) 10

11.

本はこちら(計画編) https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 11

12.

そして、本日のネタ ● 主に 2022/5 以降の「実践」の場で ○ 見つかった問題点 ○ その回避策 …について触れていきます。 12

13.

①ソート順が変わる、変わる、変わる… ● MySQL 8.0.13 で GROUP BY … ASC/DESC 廃止 ○ GROUP BY … ASC/DESC が書かれたコードは無し ○ が、「ASC」が省略された「暗黙の昇順」が多数発掘される ● それ以前に MySQL 8.0 では ○ ORDER BY の列指定が一意ではない部分のソート順が不定に ■ 例:氏名列でソート→同姓同名の人のソート順が不定に ■ 仕様上は従来も不定だったが「暗黙の了解としてのソート順」ががが 13

14.

①ソート順が変わる、の解決策 ● まずはコードでアタリをつける ○ GROUP BY はあるが ORDER BY が無いコード ■ 順序不定で OK な Map・Set に格納するものは除外 ○ ORDER BY の列指定が一意にならないコード ■ 意外に多数(全体の把握が困難) ● 動作確認を頑張る ○ つらい→致命的でないものは一旦対応を諦めることに 14

15.

②接続ライブラリ(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

16.

②接続ライブラリ関連、の解決策 (1) ● INSERT 直後に ROW_COUNT() が取れない(8.0.29) ○ MySQL Connector/J 8.0.28 にバージョンダウン ■ 8.0.29 はサーバーも含めてバグが多いバージョン ■ サーバーは途中で公開停止に 16

17.

②接続ライブラリ関連、の解決策 (2) ● java.sql.ResultSet.getObject() 時の日付フォーマット が変化 ○ java.sql.ResultSet.getTimestamp() で直接取得 ■ java.sql.ResultSet.getObject() からのキャストをやめた 17

18.

②接続ライブラリ関連、の解決策 (3) ● connectionCollation 無指定時の照合順序が変わる ○ utf8(3 バイト)で処理する箇所に utf8mb4(4 バイト)の文 字が入らないように入力チェック等を強化 ○ 必要な箇所には照合順序を明示的に指定 18

19.

③性能問題 ● 思っていたほどでは無かったが ○ v2(MySQL 5.7)への移行でよく言及される大量 IN() 列挙 ■ ほぼ無し ■ ただしアーキテクチャの変化でほんのり遅くなった感も ○ クエリの実行計画の変化 ■ v1 と違う実行計画が選択された結果、かえって遅くなる ○ CPU 使用率(やや)上昇 ■ ただし 100% に到達してもすぐにはサチらなくなった? 19

20.

③性能問題、の解決策 ● 主に 3 つ ○ オプティマイザヒントで実行計画を調整 ■ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ○ Reader インスタンスの活用 ■ 読み取り負荷の分散 ○ インスタンスタイプの変更(オプション) ■ サイズを上げる(スケールアップ) ■ 新しいタイプに変える(db.r5 → db.r6g・db.r6i) 20

21.

④DMS(CDC)レプリケーションが使えない ● DMS(CDC)レプリケーションで一部のデータが不正に ○ 大きなサイズの BLOB 列レプリケーションの問題だった ■ 2 ステップでのデータ移行になるので ON UPDATE CURRENT_TIMESTAMP が指定されている TIMESTAMP / DATETIME 列の値が誤って上書きされてし まう ■ https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch 21

22.

④DMS レプリケーション問題、の解決策 ● v1 → v2 → v3 の多段 binlog レプリケーションで代用 ○ サポート外(無保証)のやり方だが致し方なし ■ そうしないとメンテナンス停止時間が長引いてしまう ■ 1 週間程度のレプリケーションを 2 回繰り返しても問題は出なかった ○ ON UPDATE CURRENT_TIMESTAMP を外す・無くす手も ■ 一旦レプリケーション先で ON UPDATE CURRENT_TIMESTAMP を外してお いてレプリケーション終了後に付け直すか、アプリケーションを改修 ■ どちらも難しかったので不採用 22

23.

そしてついに ● 来月半ばに v1 → v3 移行予定 ○ 何も出ないことを祈ってください 23

24.

まとめ ● いろいろ出ました ○ ソート順変わる問題 ○ 接続ライブラリ(MySQL Connector/J)問題 ○ 性能問題 ○ DMS レプリケーション使えない問題 ● いよいよ来月半ばに移行予定です ○ 何も出ないことを祈ってください 24