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

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

Transcript

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