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

by Koji Yoshida

Slide 1

Slide 1 text

1 MySQL5.6から8.4へ戦いの記録よしだ(@theyoshida3) | GMO Creators Network, Inc. PHP Conference Japan 2025 2025.06.28

Slide 2

Slide 2 text

2 ⾃⼰紹介事業戦略部新規開発チーム 2024年中途⼊社よしだ @theyoshida3 ● GMOクリエイターズネットワーク株式会社 ● GMOペパボの可愛い妹分 ● 好きなお酒はメガジョッキハイボール ● 最近はPHPとGoを使うことが多い

Slide 3

Slide 3 text

今回お話すること 3 PHPとGoのWebシステムから使⽤しているMySQL5.6を8.4にアップグレードした際に対応したことを説明します。今後5.6から8.4へアップグレードする⽅の参考になれば幸いです。アップグレード⽅針と対応

Slide 4

Slide 4 text

4 ⽬次 1. システム構成 2. ⽅針 3. 先⾏対応 4. アップグレード当⽇ 5. まとめ

Slide 5

Slide 5 text

システム構成 5

Slide 6

Slide 6 text

システム構成 6 • 「フリーナンス」の社内管理システム群が対象 • 管理システムはGoogle Cloudで稼働 • IP制限やIAPにより社内ユーザーしかアクセスできない • ⼀部外部システム連携が存在概要

Slide 7

Slide 7 text

システム構成 7 フリーナンスとはフリーランス・個人事業主を支えるお金と保険のサービス

Slide 8

Slide 8 text

8 システム構成構成図管理システム Cloud Run Cloud Run Cloud SQL Cloud SQL データ基盤 Resash BigQuery

Slide 9

Slide 9 text

⽅針 9

Slide 10

Slide 10 text

⽅針 10 • 社内向けとはいえサポートが切れている • 2025/05/01から延⻑サポートにより追加課⾦が発⽣ • 本番‧検証を含めると「$982/⽉」発⽣⾒込みなぜアップグレードを⾏うか

Slide 11

Slide 11 text

• MySQL5.6は2025/05/01から追加課⾦ • MySQL5.7は2025/05/01から追加課⾦ • MySQL8.0は2026/07/01から延⻑サポート⽅針 11 アップグレードするバージョンはMySQL8.4

Slide 12

Slide 12 text

• 社内業務が停⽌してしまう • 外部システム連携による売上影響を最⼩化⽅針 12 アップグレードは夜間実施

Slide 13

Slide 13 text

• アップグレードはデータベース毎に実施⽇を分ける • 検証コスト、売上影響とのバランスも取り、バージョンは⼀晩で5.6→8.4へ • 先⾏対応可能なものは細かくリリース • ⽂字コードはutf8mb3から変更しない⽅針 13 リスク最⼩化

Slide 14

Slide 14 text

• 公式ドキュメントを読む • 公式ドキュメントのNotebookLMに読み込ませ質問 • ChatGPTやGeminiに相談 • DevinやCursorで調査⽅針 14 影響範囲の特定

Slide 15

Slide 15 text

• 開発環境(ローカル)⽤にmysqlコンテナを各バージョン⽤意 • 外部検証環境(Google Cloud)⽤にクローンをMySQL8.4へアップグレード⽅針 15 検証環境の⽤意

Slide 16

Slide 16 text

先⾏対応 16

Slide 17

Slide 17 text

• 概要 • rank, groups, windowなどが新たに予約語として追加 • `(バッククォート)でエスケープして回避可能 • 対応 • 各DBにgroupsテーブルが存在し、将来的にDB統合の予定 • テーブル名変更とコード修正先⾏対応 17 予約語

Slide 18

Slide 18 text

• 概要 • SELECT team_id, name FROM users GROUP BY team_id;はエラー • ONLY_FULL_GROUP_BYをオフにすることで回避はできる • ANYVALUEという関数も存在する • 対応 • 該当箇所があり、任意の値で良いケースが存在しない • クエリを修正先⾏対応 18 GROUP BY厳格化

Slide 19

Slide 19 text

• 概要 • 不正な値を⾒逃さないモード • 例) NOT NULLでDEFAULTなしのカラムを値指定しないでinsertするとエラー • STRICT_MODEをオフにすることで回避はできる • 対応 • カラムにDEFAULT値を指定 • オンラインDDLに対応していないため実施タイミングに注意先⾏対応 19 STRICT MODE

Slide 20

Slide 20 text

• 概要 • 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 ゼロ⽇付

Slide 21

Slide 21 text

21 先⾏対応 • MySQLユーザーの認証⽅式 ○ mysql_native_password → caching_sha2_password ○ PHP7.4.4で完全対応 • 照合順序 • 実⾏計画その他確認事項

Slide 22

Slide 22 text

• 個々⼈がredashを使って業務を⾏っている • 使⽤しているクエリの集計 • 対応毎に修正を実施 • query resultの検証がひと⼿間先⾏対応 22 redashクエリ修正

Slide 23

Slide 23 text

23 先⾏対応ほぼゼロ⽇付だったが、統合を考えた際にnull許容と混ざることは避けたい。ゼロ⽇付によりアップグレードができず、検証が進まない。 “ ゼロ⽇付多すぎ！！！”

Slide 24

Slide 24 text

アップグレード当⽇ 24

Slide 25

Slide 25 text

• メンテナンスモードへ移⾏ • バッチ停⽌ • DBバックアップ • MySQLアップグレード • 動作確認 • バッチ再開 • メンテナンス解除 • IaC辻褄合わせ • redash動作確認アップグレード当⽇ 25 作業⼿順

Slide 26

Slide 26 text

• 営業開始後の切り戻しは困難 • 失敗したインスタンスは停⽌ • クローンを起動し向き先を変える(IPアドレスが変わる) • Webアプリケーション • redash • BigQuery アップグレード当⽇ 26 切り戻しの⽅針

Slide 27

Slide 27 text

• コンソールで実施 • 1インスタンス1バージョン上げるのに10分前後 • レプリカ、プライマリの順番でアップグレードする必要がある • アップグレード後にTerraformにも反映アップグレード当⽇ 27 MySQLアップグレード

Slide 28

Slide 28 text

• 外部システムのデータ保存処理でエラー • 早期発⾒により事業影響はなかった • STRICT MODEが有効になった影響 • varchar(255)のカラムに255⽂字以上を保存しようとした • MySQL5.6の際は255⽂字で切り捨てて保存されていた • カラムをtext型へ変更アップグレード当⽇ 28 発⽣した障害

Slide 29

Slide 29 text

おまけ 29

Slide 30

Slide 30 text

「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に接続できなくなる？

Slide 31

Slide 31 text

• DBインスタンスのメンテナンス後に接続できなくなる報告あり • Cloud Runの再デプロイ、Cloud SQL Studio(コンソール)でのログインで復旧 • 発⽣するのは下記の組み合わせ • Cloud SQL Proxyを使⽤したUnixソケット接続 • caching_sha2_password認証プラグインでの接続おまけ 31 Cloud Run × Cloud SQL for MySQL8.4でDBに接続できなくなる？

Slide 32

Slide 32 text

まとめ 32

Slide 33

Slide 33 text

• 公式ドキュメントとAIを使って影響調査をすると効率的 • 複数バージョンによる検証環境を⽤意し効率的に対応 • 予約語、GROUP BY、STRICT MODE、ゼロ⽇付の先⾏対応を実施 • 認証⽅式変更、照合順序、実⾏計画も考慮すること • 既に保存されているデータにも気をつけるまとめ 33

Slide 34

Slide 34 text

34 ご清聴ありがとうございました戦友になってくれる⽅は @theyoshida3 までご連絡ください！カジュアル⾯談でもお待ちしております。