• トップ
  • ブログ一覧
  • Cloud SQLでMySQLをアップグレード
  • Cloud SQLでMySQLをアップグレード

    みや(エンジニア)みや(エンジニア)
    2025.02.07

    IT技術

    はじめに

    入社2年目のみやです。
    最近、所属しているプロジェクトでGoogle CloudのCloud SQLインスタンスのMySQLメジャーバージョンのアップグレードを実施しました。
    その際の流れをご紹介したいと思います。

    やったこと

    Webアプリケーションで使っているCloud SQLのMySQLのバージョンを MySQL 5.7.44 から MySQL 8.0.40 にインプレースでアップグレード。

    アップグレードの必要性

    MySQLはバージョンがリリースされてから、新規機能の追加やセキュリティの向上などが提供されています。
    しかし、サポート期限が切れてしまったバージョンに関しては、新規機能の追加やセキュリティの向上が行われなくなってしまいます。
    サポート期限が切れたバージョンを使い続けることは可能ですが、セキュリティパッチに関して脆弱性が発見されてもセキュリティパッチがないなどさまざまな問題が生じてしまいます。

    また、Google Cloud のCloud SQLに関しては、通常のサポート期間中において、データベースエンジンのマイナーバージョンとメンテナンスアップデートを提供してくれます。また、インスタンスにセキュリティ修正も適用されます。
    しかし、通常のサポート期間が終わり、拡張サポートになると引き続きサポートはしてくれるのですが、通常のインスタンス料金に加えて料金がかかってしまいます。(参照
    このように拡張サポートは有料サービスなので、拡張サポート開始日になる前にアップグレードする方がコストの面で良いです。

    所属しているプロジェクトでは、Cloud SQLのMySQL 5.7.44を使っていたのですが、
    以下の表の通り、2025年1月末でMySQL 5.7の通常サポートが終了し、2025年2月1日に拡張サポートに突入してしまいます。
    ですので、2025年2月1日に入る前にアップグレードを実施する必要がありました。

    Cloud SQLのサポートバージョン
    メジャーバージョン通常サポートの開始日拡張サポートの開始日サポートの終了日
    MySQL 8.42024 年 10 月 1 日--
    MySQL 8.02020 年 8 月 30 日2026 年 7 月 1 日2029 年 7 月 1 日
    MySQL 5.72016 年 8 月 1 日2025 年 2 月 1 日2028 年 2 月 1 日
    MySQL 5.62016 年 8 月 1 日2025 年 2 月 1 日2028 年 2 月 1 日

    アップグレードの方法

    Cloud SQLのMySQLのアップグレード方法は2種類あります。

    • データベースのメジャーバージョンをインプレースでアップグレードする(公式
    • データを移行してデータベースのメジャーバージョンをアップグレードする(公式

    インプレースの方が簡単な方法です。既存のインスタンスを直接アップグレードするのでデータの移行が不要で、現在のインスタンスの名前、IPアドレス、その他の設定を維持できます。データの移行より短時間で完了でき、ダウンタイムが短くなります。
    一方、データ移行の方は、新しいバージョンの新しいインスタンスを作成して、データを移行する方法です。こちらは新規インスタンスの設定が必要であり、ダウンタイムもインプレースより長くなります。ロールバックはインプレースより簡単になると思います。

    ダウンタイムの短さ・実行の簡単さから私のブロジェクトでは「インプレース」でアップグレードする方法を選択しました。

    アップグレードの計画

    まず、アップグレードするインスタンスでアップデータ可能なバージョンを確認します。
    Google Cloud CLIを導入し、プロジェクトが正しく設定されていることを確認してから以下のコマンドを実行します。
    インスタンス名はインプレースアップグレード対象のSQLインスタンスを指定します。

    1gcloud sql instances describe $インスタンス名

    すると、upgradableDatabaseVersionsの部分にアップグレード可能なバージョンが表示されるので、そこからアップグレードしたいバージョンを選びます。
    今回は、メジャーバージョン8.0の最新のアップグレード可能バージョン MySQL 8.0.40 を選択しました。

    次にMySQL8.0の機能を確認し(確認先)、非互換性の問題を解決します。
    例えば、character_set_server のMySQL 5.7 のデフォルト値は、utf8 ですが、MySQL 8.0 にアップグレードすると、デフォルト値の character_set_server が utf8mb4 に変更されます。

    私のプロジェクトで対応した部分の一例を挙げると以下の部分です。

    Incompatible change:
    As of MySQL 8.0.13, the deprecated ASC or DESC qualifiers for GROUP BY clauses have been removed. Queries that previously relied on GROUP BY sorting may produce results that differ from previous MySQL versions. To produce a given sort order, provide an ORDER BY clause.

    引用元: MySQL 8.0 Reference Manual / Upgrading MySQL / Changes in MySQL 8.0

    これはMySQL 8.0とMySQL 5.7で GROUP BYのソートロジックが異なるということです。
    MySQL 5.7ではGROUP BYで取得する際にソートをしてくれていたのですが、MySQL 8.0ではされなくなったので、ORDER BYで明示的にソートしなくてはならなくなりました。

    他にも、予約済みテーブル名が使われていないかなどを確認しました。詳細はこちらをご確認ください。

    次にディスク容量とインスタンスのマシンタイプを確認しました。
    メジャー バージョンのアップグレードでは、アップグレードされたテーブルを格納するために、追加のリソース(ディスク容量など)が必要になります。ディスク容量が十分でない場合、アップグレードに失敗してロールバックされます。
    公式によると、テーブルあたり100Kより多くのメモリが使用可能であることを確認した方が良いとのことなので、コンソールからインスタンスのメモリの容量をみて問題ないことを確認しました。

    アップグレードの影響範囲の調査

    アップグレード時はダウンタイムが発生するので、アップグレード中にアプリケーションで操作をするとどのような挙動をするかを調査します。
    ほとんどの操作でDBのコネクションエラーが発生してしまうので、アップグレード中はメンテナンス画面を表示することになりました。
    また、今回のアプリケーションは外部に提供しているAPIがあるので、提供先にアップグレード実施について連携し、そちらの影響範囲についても考慮する必要がありました。

    開発環境でのアップグレードの実施

    開発環境も本番環境と同様の設計なので、まず開発環境でアップグレードを実施します。

    コンソール上で実施しました。
    手順としては以下です。

      1. Google Cloud コンソールにアクセスする
      2. プロジェクトを選択する
      3. 左のサイドメニューからSQLを選択する(もしくは、検索バーからSQLと検索し選択)
      4. アップグレードを実施するSQLインスタンスを選択する
      5. 画面上部にある編集ボタンをクリックする

      1. インスタンスの情報の部分にある、「アップグレード」を押下する

      1. 以下のような画面が表示されるので、「アップグレードページに移動」を押下する

      1. アップグレードするバージョンを選択し、「続行」を押下する

      1. インスタンスIDを入力し、「アップグレードを開始」を押下する

    上記手順によりインプレースアップグレードが自動で実施されます。アップグレードが終わると終了した通知が画面右下に表示されます。公式には10分もかからないと記載がありましたが、私のプロジェクトでは開発環境・検証環境では約20分、本番環境では約10分かかりました(本番の方がメモリが大きいのでその違いかもしれません)。

    アップグレード後、アプリケーションが期待通りに動くかを確認し、問題なくアップグレードが行えました。

    また、Cloud SQLではアップグレードを実施すると、自動でバックアップを作成してくれます。

    それぞれのバックアップの役割は以下です。もしもの時はこちらから以前のバージョンに復元します。

      • Pre-upgrade backup

    アップグレード前のバックアップで、アップグレードの直前に作成される。データベースインスタンスを以前のバージョンの状態に復元するために使用できます。

      • Post-upgrade backup

    アップグレード後のバックアップで、アップグレードされたデータベース インスタンスへの新しい書き込みが許可された直後に作成される。

    アップグレードの時間帯の決定

    アップグレードの時間帯の決定時には以下を気をつけました。

    • 利用者が少ない時間帯に実施する
    • バッチ処理が実行されない時間帯に実施する

    時間帯を決定後、アプリケーション提供先のクライアントに周知しました。

    本番環境でのアップグレードの実施

    今回のプロジェクトはCloud Runでデプロイしているアプリケーションです。
    アップグレードを行う前に、アップグレードによる互換性がない部分の修正対応をリリースしました。
    アップグレード実施時刻になったら、メンテナンス画面を表示するリビジョンに切り替えます。
    その後、開発環境でのアップグレード手順と同様の手順でアップグレードを実施しました。
    アップグレード完了後、動作確認を行い、問題ないことを確認しました。
    メンテナンス画面の表示を解除し、アップグレード対応の完了です。

    まとめ

    今回はCloud SQLのMySQLバージョンアップを実施した際の流れをご紹介しました。
    私自身、初めての経験でしたのでとても勉強になりました。本番環境で実施するのはやはり緊張します。
    実施手順自体はかなり簡単でしたが、アップグレードの計画や準備、検証には時間がかかるので、計画的にアップグレードは行いたいですね。

    ライトコードでは、エンジニアを積極採用中!

    ライトコードでは、エンジニアを積極採用しています!社長と一杯しながらお話しする機会もご用意しております。そのほかカジュアル面談等もございますので、くわしくは採用情報をご確認ください。

    採用情報へ

    みや(エンジニア)
    みや(エンジニア)
    Show more...

    おすすめ記事

    エンジニア大募集中!

    ライトコードでは、エンジニアを積極採用中です。

    特に、WEBエンジニアとモバイルエンジニアは是非ご応募お待ちしております!

    また、フリーランスエンジニア様も大募集中です。

    background