Aurora MySQL v1→v3移行の経過報告
4.2K Views
September 30, 22
スライド概要
JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30
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
関連スライド
各ページのテキスト
Aurora MySQL v1 → v3 移行の経過報告 JAWS-UG 名古屋 オンラインフリーテーマ会 2022/9/30 まつひさ（hmatsu47）
自己紹介 松久裕保（@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
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
とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は（EoL まで）実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ（PITR） ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL（予定）※時刻はいずれも 00:00:00 UTC 4
とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は（EoL まで）実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ（PITR） ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL（予定）※時刻はいずれも 00:00:00 UTC 5
とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 注 : 以下は（EoL まで）実行可能 ■ v1 スナップショットの復元 ■ クラスタにリードレプリカ追加 ■ インスタンス設定変更 ■ ポイントインタイムリカバリ（PITR） ■ 既存 v1 クラスタのクローン作成 ● 2023/2/28 : EoL（予定）※時刻はいずれも 00:00:00 UTC 6
とはいえ放置は危険 ● 2022/9/27 : 新しいクラスタ・インスタンス作成停止 ○ 作成できちゃいました！（9/30 朝時点で） 7
とはいえ放置は危険 ● 2023/2/28 : EoL（予定）※時刻はいずれも 00:00:00 UTC 8
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
なので、 ● せっかく移行するなら v3 へ ● v3 移行に必要な情報を集めて Zenn で本にまとめた …というのが計画編の話（2022/4） ● 計画編に関する登壇 ● JAWS-UG 朝会（4/11） ● JAWS-UG 浜松（4/29） ● その後、JAWS-UG 東海道でも（7/9） 10
本はこちら（計画編） https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book 11
そして、本日のネタ ● 主に 2022/5 以降の「実践」の場で ○ 見つかった問題点 ○ その回避策 …について触れていきます。 12
①ソート順が変わる、変わる、変わる… ● MySQL 8.0.13 で GROUP BY … ASC/DESC 廃止 ○ GROUP BY … ASC/DESC が書かれたコードは無し ○ が、「ASC」が省略された「暗黙の昇順」が多数発掘される ● それ以前に MySQL 8.0 では ○ ORDER BY の列指定が一意ではない部分のソート順が不定に ■ 例：氏名列でソート→同姓同名の人のソート順が不定に ■ 仕様上は従来も不定だったが「暗黙の了解としてのソート順」ががが 13
①ソート順が変わる、の解決策 ● まずはコードでアタリをつける ○ GROUP BY はあるが ORDER BY が無いコード ■ 順序不定で OK な Map・Set に格納するものは除外 ○ ORDER BY の列指定が一意にならないコード ■ 意外に多数（全体の把握が困難） ● 動作確認を頑張る ○ つらい→致命的でないものは一旦対応を諦めることに 14
②接続ライブラリ（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
②接続ライブラリ関連、の解決策 (1) ● INSERT 直後に ROW_COUNT() が取れない（8.0.29） ○ MySQL Connector/J 8.0.28 にバージョンダウン ■ 8.0.29 はサーバーも含めてバグが多いバージョン ■ サーバーは途中で公開停止に 16
②接続ライブラリ関連、の解決策 (2) ● java.sql.ResultSet.getObject() 時の日付フォーマット が変化 ○ java.sql.ResultSet.getTimestamp() で直接取得 ■ java.sql.ResultSet.getObject() からのキャストをやめた 17
②接続ライブラリ関連、の解決策 (3) ● connectionCollation 無指定時の照合順序が変わる ○ utf8（3 バイト）で処理する箇所に utf8mb4（4 バイト）の文 字が入らないように入力チェック等を強化 ○ 必要な箇所には照合順序を明示的に指定 18
③性能問題 ● 思っていたほどでは無かったが ○ v2（MySQL 5.7）への移行でよく言及される大量 IN() 列挙 ■ ほぼ無し ■ ただしアーキテクチャの変化でほんのり遅くなった感も ○ クエリの実行計画の変化 ■ v1 と違う実行計画が選択された結果、かえって遅くなる ○ CPU 使用率（やや）上昇 ■ ただし 100% に到達してもすぐにはサチらなくなった？ 19
③性能問題、の解決策 ● 主に 3 つ ○ オプティマイザヒントで実行計画を調整 ■ https://qiita.com/hmatsu47/items/9b1090111f2683d386bc ○ Reader インスタンスの活用 ■ 読み取り負荷の分散 ○ インスタンスタイプの変更（オプション） ■ サイズを上げる（スケールアップ） ■ 新しいタイプに変える（db.r5 → db.r6g・db.r6i） 20
④DMS（CDC）レプリケーションが使えない ● DMS（CDC）レプリケーションで一部のデータが不正に ○ 大きなサイズの BLOB 列レプリケーションの問題だった ■ 2 ステップでのデータ移行になるので ON UPDATE CURRENT_TIMESTAMP が指定されている TIMESTAMP / DATETIME 列の値が誤って上書きされてし まう ■ https://zenn.dev/hmatsu47/articles/mysql-dms-cdc-timestamp-mismatch 21
④DMS レプリケーション問題、の解決策 ● v1 → v2 → v3 の多段 binlog レプリケーションで代用 ○ サポート外（無保証）のやり方だが致し方なし ■ そうしないとメンテナンス停止時間が長引いてしまう ■ 1 週間程度のレプリケーションを 2 回繰り返しても問題は出なかった ○ ON UPDATE CURRENT_TIMESTAMP を外す・無くす手も ■ 一旦レプリケーション先で ON UPDATE CURRENT_TIMESTAMP を外してお いてレプリケーション終了後に付け直すか、アプリケーションを改修 ■ どちらも難しかったので不採用 22
そしてついに ● 来月半ばに v1 → v3 移行予定 ○ 何も出ないことを祈ってください 23
まとめ ● いろいろ出ました ○ ソート順変わる問題 ○ 接続ライブラリ（MySQL Connector/J）問題 ○ 性能問題 ○ DMS レプリケーション使えない問題 ● いよいよ来月半ばに移行予定です ○ 何も出ないことを祈ってください 24