MySQL5.6から8.4へ 戦いの記録

CakePHPとGoで構築された社内ユーザー向けシステムのデータベースをMySQL5.6から8.4へアップグレードしました。
その旅路は非常に困難で苦難の連続でした。

このトークではMySQLのバージョンによる仕様的な話は多くは語りません。
代わりに、下記の点をお話します。
・なぜMySQL5.6から8.4へアップグレードしたのか
・リスク最小化のための方針
・対応した内容
・アップグレード当日の対応手順と失敗時の手順

社内向けとはいえ、基本的にはデータベースを止めることができない中でどう検証し、何が大変だったかをご紹介します。

Transcript

1. 1 MySQL5.6から8.4へ 戦いの記録 よしだ(@theyoshida3) | GMO Creators Network, Inc. PHP Conference Japan 2025 2025.06.28
2. 2 ⾃⼰紹介 事業戦略部 新規開発チーム 2024年 中途⼊社 よしだ @theyoshida3 • GMOクリエイターズネットワーク株式会社 • GMOペパボの可愛い妹分 • 好きなお酒はメガジョッキハイボール • 最近はPHPとGoを使うことが多い
3. 今回お話すること 3 PHPとGoのWebシステムから使⽤ しているMySQL5.6を8.4にアップ グレードした際に対応したことを 説明します。 今後5.6から8.4へアップグレードす る⽅の参考になれば幸いです。 アップグレード⽅針と対応
4. 4 ⽬次 1. システム構成 2. ⽅針 3. 先⾏対応 4. アップグレード当⽇ 5. まとめ
5. システム構成 5
6. システム構成 6 • 「フリーナンス」の社内管理システム群が対象 • 管理システムはGoogle Cloudで稼働 • IP制限やIAPにより社内ユーザーしかアクセスできない • ⼀部外部システム連携が存在 概要
7. システム構成 7 フリーナンスとは フリーランス・個人事業主を支える お金と保険のサービス
8. 8 システム構成 構成図 管理システム Cloud Run Cloud Run Cloud SQL Cloud SQL データ基盤 Resash BigQuery
9. ⽅針 9
10. ⽅針 10 • 社内向けとはいえサポートが切れている • 2025/05/01から延⻑サポートにより追加課⾦が発⽣ • 本番‧検証を含めると「$982/⽉」発⽣⾒込み なぜアップグレードを⾏うか
11. • MySQL5.6は2025/05/01から追加課⾦ • MySQL5.7は2025/05/01から追加課⾦ • MySQL8.0は2026/07/01から延⻑サポート ⽅針 11 アップグレードするバージョンはMySQL8.4
12. • 社内業務が停⽌してしまう • 外部システム連携による売上影響を最⼩化 ⽅針 12 アップグレードは夜間実施
13. • アップグレードはデータベース毎に実施⽇を分ける • 検証コスト、売上影響とのバランスも取り、バージョンは⼀晩で5.6→8.4へ • 先⾏対応可能なものは細かくリリース • ⽂字コードはutf8mb3から変更しない ⽅針 13 リスク最⼩化
14. • 公式ドキュメントを読む • 公式ドキュメントのNotebookLMに読み込ませ質問 • ChatGPTやGeminiに相談 • DevinやCursorで調査 ⽅針 14 影響範囲の特定
15. • 開発環境(ローカル)⽤にmysqlコンテナを各バージョン⽤意 • 外部検証環境(Google Cloud)⽤にクローンをMySQL8.4へアップグレード ⽅針 15 検証環境の⽤意
16. 先⾏対応 16
17. • 概要 • rank, groups, windowなどが新たに予約語として追加 • `(バッククォート)でエスケープして回避可能 • 対応 • 各DBにgroupsテーブルが存在し、将来的にDB統合の予定 • テーブル名変更とコード修正 先⾏対応 17 予約語
18. • 概要 • SELECT team_id, name FROM users GROUP BY team_id;はエラー • ONLY_FULL_GROUP_BYをオフにすることで回避はできる • ANYVALUEという関数も存在する • 対応 • 該当箇所があり、任意の値で良いケースが存在しない • クエリを修正 先⾏対応 18 GROUP BY厳格化
19. • 概要 • 不正な値を⾒逃さないモード • 例) NOT NULLでDEFAULTなしのカラムを値指定しないでinsertするとエラー • STRICT_MODEをオフにすることで回避はできる • 対応 • カラムにDEFAULT値を指定 • オンラインDDLに対応していないため実施タイミングに注意 先⾏対応 19 STRICT MODE
20. • 概要 • DATE型へ「0000-00-00」, DATETIME型へ「0000-00-00 00:00:00」などはエラー • STRICT MODE, NO_ZERO_DATEをオフにすることで回避はできる • 対応 • Goのtime.Time型は「0001-01-01」が初期状態、そのまま保存していた • *time.Timeへ変更しnilを許容 • カラムのNOT NULLをNULL許容に変更 • オンラインDDLに対応していないため実施タイミングに注意 • 保存済みのデータをnullに変更するクエリ実⾏ 先⾏対応 20 ゼロ⽇付
21. 21 先⾏対応 • MySQLユーザーの認証⽅式 ◦ mysql_native_password → caching_sha2_password ◦ PHP7.4.4で完全対応 • 照合順序 • 実⾏計画 その他確認事項
22. • 個々⼈がredashを使って業務を⾏っている • 使⽤しているクエリの集計 • 対応毎に修正を実施 • query resultの検証がひと⼿間 先⾏対応 22 redashクエリ修正
23. 23 先⾏対応 ほぼゼロ⽇付だったが、統合を考えた際にnull許容と混ざることは避けたい。 ゼロ⽇付によりアップグレードができず、検証が進まない。 “ ゼロ⽇付 多すぎ！！！”
24. アップグレード当⽇ 24
25. • メンテナンスモードへ移⾏ • バッチ停⽌ • DBバックアップ • MySQLアップグレード • 動作確認 • バッチ再開 • メンテナンス解除 • IaC辻褄合わせ • redash動作確認 アップグレード当⽇ 25 作業⼿順
26. • 営業開始後の切り戻しは困難 • 失敗したインスタンスは停⽌ • クローンを起動し向き先を変える(IPアドレスが変わる) • Webアプリケーション • redash • BigQuery アップグレード当⽇ 26 切り戻しの⽅針
27. • コンソールで実施 • 1インスタンス1バージョン上げるのに10分前後 • レプリカ、プライマリの順番でアップグレードする必要がある • アップグレード後にTerraformにも反映 アップグレード当⽇ 27 MySQLアップグレード
28. • 外部システムのデータ保存処理でエラー • 早期発⾒により事業影響はなかった • STRICT MODEが有効になった影響 • varchar(255)のカラムに255⽂字以上を保存しようとした • MySQL5.6の際は255⽂字で切り捨てて保存されていた • カラムをtext型へ変更 アップグレード当⽇ 28 発⽣した障害
29. おまけ 29
30. 「Cloud Runを使っている⽅はCloud SQL for MySQLをv8.4にするのは待った⽅がいいかも」 (syosan,⽣涯未熟, https://syossan.hateblo.jp/entry/2025/06/12/221836)2025/06/21 おまけ 30 Cloud Run × Cloud SQL for MySQL8.4でDBに接続できなくなる？
31. • DBインスタンスのメンテナンス後に接続できなくなる報告あり • Cloud Runの再デプロイ、Cloud SQL Studio(コンソール)でのログインで復旧 • 発⽣するのは下記の組み合わせ • Cloud SQL Proxyを使⽤したUnixソケット接続 • caching_sha2_password認証プラグインでの接続 おまけ 31 Cloud Run × Cloud SQL for MySQL8.4でDBに接続できなくなる？
32. まとめ 32
33. • 公式ドキュメントとAIを使って影響調査をすると効率的 • 複数バージョンによる検証環境を⽤意し効率的に対応 • 予約語、GROUP BY、STRICT MODE、ゼロ⽇付の先⾏対応を実施 • 認証⽅式変更、照合順序、実⾏計画も考慮すること • 既に保存されているデータにも気をつける まとめ 33
34. 34 ご清聴ありがとうございました 戦友になってくれる⽅は @theyoshida3 までご連絡ください！ カジュアル⾯談でもお待ちしております。