データベースのメジャー バージョンをインプレースでアップグレードする

MySQL   |  PostgreSQL   |  SQL Server

このページでは、データを移行するのではなく、Cloud SQL インスタンスをインプレース アップグレードでデータベースのメジャー バージョンのアップグレードを行う方法について説明します。

はじめに

データベース ソフトウェア プロバイダは、新機能、パフォーマンス改善、セキュリティ強化を含む新しいメジャー バージョンを定期的にリリースしています。Cloud SQL では、新しいバージョンがリリース後に取り込まれます。Cloud SQL で新しいメジャー バージョンのサポートが提供された後、インスタンスをアップグレードして、データベースを最新の状態に保つことができます。

インスタンスのデータベース バージョンをアップグレードするには、インプレース アップグレードまたはデータの移行を行います。インプレース アップグレードは、インスタンスのメジャー バージョンをアップグレードするためのより簡単な方法です。データの移行や、アプリケーション接続文字列の変更は必要ありません。インプレース アップグレードを使用すると、アップグレード後も、現在のインスタンスの名前、IP アドレス、その他の設定を維持できます。インプレース アップグレードは、データファイルを移動する必要がないため、より短時間で完了できます。場合によっては、データの移行よりもダウンタイムが短くなります。

MySQL 8.0.15 以前の場合、MySQL のインプレース アップグレード オペレーションは mysql_upgrade ユーティリティを使用します。MySQL 8.0.16 以降では、MySQL のインプレース アップグレード オペレーションは MySQL server プロセスによって処理されます。インプレース アップグレード オペレーションの詳細については、MySQL アップグレード プロセスでアップグレードされる内容をご覧ください。

メジャー バージョン アップグレードの計画

1. 対象のメジャー バージョンを選択します。

   gcloud

   gcloud CLI のインストールと開始については、gcloud CLI をインストールするをご覧ください。Cloud Shell の起動については、Cloud Shell を使用するをご覧ください。

   インスタンスでインプレース アップグレードのターゲットに指定できるデータベース バージョンを確認するには、次の操作を行います。

   1. 次のコマンドを実行します。

   gcloud sql instances describe INSTANCE_NAME
      

   INSTANCE_NAME は、インスタンス名で置き換えます。

   2. コマンドの出力で、upgradableDatabaseVersions というラベルが付いたセクションを見つけます。
   3. 各サブセクションは、アップグレードに使用できるデータベース バージョンを返します。各サブセクションで、次のフィールドを確認します。
   • majorVersion: インプレース アップグレードのターゲットに指定できるメジャー バージョン。
   • name: メジャー バージョンを含むデータベース バージョン文字列。Cloud SQL for MySQL の場合、このフィールドにはデータベースのマイナー バージョンも含まれます。
   • displayName: データベース バージョンの表示名。

   REST v1

   メジャー バージョンのインプレース アップグレードに使用できるターゲット データベース バージョンを確認するには、Cloud SQL Admin API の instances.get メソッドを使用します。

   リクエストのデータを使用する前に、次のように置き換えます。

   • INSTANCE_NAME: インスタンス名。

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

   リクエストを送信するには、次のいずれかのオプションを展開します。

   curl（Linux、macOS、Cloud Shell）

   注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ユーザー アカウントで gcloud CLI にログインしているか、Cloud Shell を使用して自動的に gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

   次のコマンドを実行します。

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell（Windows）

   注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ご自分のユーザー アカウントで gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

   次のコマンドを実行します。

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   次のような JSON レスポンスが返されます。

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   REST v1beta4

   インスタンスのメジャー バージョンのインプレース アップグレードに使用できるターゲット データベース バージョンを確認するには、Cloud SQL Admin API の instances.get メソッドを使用します。

   リクエストのデータを使用する前に、次のように置き換えます。

   • INSTANCE_NAME: インスタンス名。

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

   リクエストを送信するには、次のいずれかのオプションを展開します。

   curl（Linux、macOS、Cloud Shell）

   注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ユーザー アカウントで gcloud CLI にログインしているか、Cloud Shell を使用して自動的に gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

   次のコマンドを実行します。

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

   PowerShell（Windows）

   注: 次のコマンドは、gcloud init または gcloud auth login を実行して、ご自分のユーザー アカウントで gcloud CLI にログインしていることを前提としています。gcloud auth list を実行すると、現在アクティブなアカウントを確認できます。

   次のコマンドを実行します。

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

   次のような JSON レスポンスが返されます。

   
   upgradableDatabaseVersions:
   
   {
     major_version: "MYSQL_8_0"
     name: "MYSQL_8_0_36"
     display_name: "MySQL 8.0.36"
   }
   
   

   Cloud SQL がサポートしているデータベース バージョンの一覧については、データベースのバージョンとバージョン ポリシーをご覧ください。

2. データベースの各メジャー バージョンで提供される機能を検討し、非互換性の問題を解決します。

   • MySQL 8.4
   • MySQL 8.0
   • MySQL 5.7

   新しいメジャー バージョンで互換性のない変更が導入され、アプリケーション コード、スキーマ、データベース設定の変更が必要になる場合があります。データベース インスタンスをアップグレードする前に、対象となるメジャー バージョンのリリースノートで、対処する必要がある互換性の問題を確認してください。

   新しいバージョンにアップグレードすると、一部のシステム変数のデフォルト値が変更される場合があります。たとえば、character_set_server MySQL 5.6 と MySQL 5.7 のデフォルト値は、utf8 です。MySQL 8.0 にアップグレードすると、デフォルト値の character_set_server が utf8mb4 に変更されます。utf8 に戻すには、データベース フラグの値を手動で古い値に変更する必要があります。詳細については、データベース フラグを構成するをご覧ください。デフォルト値の変更のほとんどは、MySQL コミュニティによって行われます（詳しくは、サーバーのデフォルトをアップグレードするをご覧ください）。

   注: 現在のメジャー バージョンの次のメジャー バージョンにのみアップグレードできます。MySQL ではメジャー バージョンのスキップはサポートされていません。MySQL 5.6 から MySQL 8.0 に直接アップグレードすることはできません。また、MySQL 5.7 から MySQL 8.4 に直接アップグレードすることもできません。

3. MySQL 8.0 から 8.4 にアップグレードする場合は、まずインスタンスを MySQL 8.0.37 以降にアップグレードしてから、MySQL 8.4 にアップグレードする必要があります。マイナー バージョンのアップグレードを実行するには、データベースのマイナー バージョンをアップグレードするをご覧ください。

4. アップグレードに関する事前チェックを実施します。

   • MySQL 5.7 から 8.0 にアップグレードする場合は、MySQL 5.7 から 8.0 へのアップグレードに関する事前チェックを行います。MySQL シェルで Upgrade Checker Utility を使用できます。

   • MySQL 8.0 から 8.4 にアップグレードする場合は、MySQL 8.0 から 8.4 へのアップグレードに関する事前チェックを行います。MySQL シェルで Upgrade Checker Utility を使用できます。

     事前チェックで問題が見つかった場合は、アップグレードに進む前に問題を修正します。Cloud SQL では、メジャー バージョンのアップグレード中に事前チェックを行うことはできません。事前チェックで問題が見つかったインスタンスをアップグレードしようとしても、失敗する可能性があります。

     重要: MySQL シェルから MySQL 8.4 の Upgrade Checker Utility を実行している場合は、sysvarAllowedValues と removedSysVars の事前チェック警告を安全に無視できます。

5. ディスク容量とインスタンスのマシンタイプを確認します。

   メジャー バージョンのアップグレードでは、アップグレードされたテーブルを格納するために、追加のリソース（ディスク容量など）が必要になります。ディスク容量が十分でない場合、アップグレードに失敗してロールバックされます。MySQL 5.7 から 8.0 にアップグレードする場合は、古いメタデータを新しいデータ ディクショナリに変換するため、追加のメモリが必要になります。メジャー バージョン アップグレードを実行する前に、テーブルあたり 100K より多くのメモリが使用可能であることを確認してください。マシンタイプを変更することで、一時的にメモリを増やすことができます。

6. MySQL 5.7 から MySQL 8.0 にアップグレードする場合は、MySQL 8.0 でユーザー権限の変更を確認します。

   Cloud SQL for MySQL バージョン 8.0 では partial_revokes というフラグを使用します。このフラグは、デフォルトで ON に設定されています。MySQL 5.7 とは異なり、このフラグを使用すると、データベースの GRANT コマンドでワイルドカード文字を使用できなくなります。データベース ユーザーが正しいデータベース スキーマにアクセスできるようにするには、MySQL 8.0 にアップグレードする前にデータベース ユーザーの権限を変更します。ワイルドカード文字を使用する代わりに、必要なデータベース スキーマの完全な名前を使用するためにユーザーの権限を更新します。

   MySQL 8.0 のこのフラグの機能の詳細については、MySQL 8.0 の partial_revokes をご覧ください。

7. ドライランでアップグレードをテストします。

   本番環境データベースをアップグレードする前に、テスト環境でエンドツーエンドのアップグレード プロセスのドライランを実行します。インスタンスのクローンを作成して、アップグレード プロセスのテストに使用するデータをコピーします。

   アップグレードが正常に完了することを検証するだけでなく、アップグレードされたデータベースでアプリケーションが期待どおりに動作することを確認するためのテストを実行します。

   注: メジャー バージョンのアップグレードを実行する前に、十分なディスク容量があることを確認してください。ストレージの自動増量を有効にしていない場合は、アップグレードしたドライラン インスタンスが使用するディスク ストレージをメモしておきます。これにより、アップグレード前に本番環境インスタンスのストレージ容量を増やす必要があるかどうかを判断できます。

8. アップグレードのタイミングを決定します。

   アップグレード中は、インスタンスが一定期間使用できなくなります。データベース アクティビティが低い時間帯にアップグレードを行うように計画してください。

メジャー バージョン アップグレードを準備する

アップグレードを行う前に、次の手順を行います。

1. MySQL 5.7 から 8.0 へのアップグレードのみ: 事前チェック プロセスで見つかった互換性のない問題を確認して修正します。一般的な問題には、次のようなものがあります。

   1. ストアド プロシージャ、トリガー、その他のデータベース オブジェクトで、RANKS、GROUPS、FUNCTION などの新しい予約済みキーワードを追加。詳細については、キーワードと予約語をご覧ください。
   2. テーブル定義内の無効な UTF 文字。
   3. XA COMMIT ステートメントを使用して commit、または XA ROLLBACK ステートメントを使用してロールバックする必要がある commit されていない XA の遷移。
   4. 64 文字を超える名前での外部キー制約。
   5. 列の混合インデックス内の空間データ型。詳細については、空間データ型をご覧ください。

   詳細については、アップグレードのためのインストールの準備と MySQL 8.0 へのアップグレードをご覧ください。

   MySQL 8.0 から MySQL 8.4 へのアップグレードのみ: 事前チェック プロセスで見つかった互換性のない問題を確認して修正します。一般的な問題としては、次のようなものがあります。

   • 古いレプリケーション用語。MASTER と SLAVE という用語は MySQL 8.4 から完全に削除されました。これらの用語を含むコマンドや構成を引き続き使用している場合は、それらを置き換えるか削除する必要があります。これらの用語の削除と置換の詳細については、MySQL 8.0 以降の MySQL 8.4 の新機能をご覧ください。
   • 非推奨の mysql_native_password プラグインの代わりに caching_sha2_password 認証プラグインを使用するように、既存のユーザー アカウントの認証プラグインを更新します。
     
     既存のデータベース ユーザー アカウントを変更して caching_sha2_password 認証プラグインを使用するようにするには、次のコマンドを使用します。

          ALTER USER 'username'@'%'
          IDENTIFIED WITH caching_sha2_password BY 'user_password';
          

     username と user_password は、更新するユーザー アカウントの値に置き換えます。

2. ディスク容量とインスタンスのマシンタイプを確認します。

   メジャー バージョンのアップグレードでは、アップグレードされたテーブルと新しいデータ ディクショナリを保存するために追加のディスク容量とメモリが必要になります。必要なディスク容量が不足すると、アップグレードが失敗し、元のバージョンにロールバックされます。Cloud SQL では、テーブルごとに少なくとも 100k のメモリを用意することをおすすめします。

   注: メジャー バージョンのアップグレードを実行する前にマシンタイプを変更することで、一時的にメモリを増やすことができます。詳細については、マシンタイプの変更をご覧ください。

3. リードレプリカをアップグレードします。

   リードレプリカを使用する場合は、プライマリ インスタンスをアップグレードする前に、すべてのリードレプリカをアップグレードする必要があります。レプリカがアップグレードされてもプライマリ インスタンスがアップグレードされない場合、レプリカが使用する MySQL の新しいバージョンでサポートされなくなったステートメントや関数をプライマリが使用すると、レプリケーションが中断する可能性があります。このような問題を回避するために、Cloud SQL では次のことをおすすめします。

   1. レプリカをアップグレードした直後にプライマリをアップグレードします。
   2. アップグレードが正常に完了するまで、プライマリ インスタンスで新しいバージョンと互換性のないクエリを実行しないでください。
   3. 省略可: アップグレードが正常に完了するまで、プライマリ インスタンスに対するすべての WRITE ステートメントを一時停止します。
   4. 省略可: プライマリをアップグレードする前にすべてのレプリカを削除し、アップグレードが完了したらレプリカを再作成します。

   レプリケーションが中断された場合、レプリカはプライマリ インスタンスのバージョンにロールバックされます。レプリカを再度アップグレードできますが、問題が解決しない場合は、よくある質問をご覧ください。

データベースのメジャー バージョンをインプレースでアップグレードする

アップグレード操作を開始すると、Cloud SQL は、最初にインスタンスの構成をチェックしてアップグレードの互換性を確認します。構成を確認すると、Cloud SQL は、インスタンスを利用不可にして、アップグレード前のバックアップを作成します。その後、アップグレードを実行し、インスタンスを使用可能にして、アップグレード後のバックアップを作成します。

MySQL 8.0 にアップグレードすると、インスタンスがデフォルトのマイナー バージョンに自動的にプロビジョニングされます。

注: リードレプリカは、プライマリ インスタンスよりも前にアップグレードしてください。レプリカまたはレプリカを持つインスタンスをアップグレードする場合は、gcloud、API、または Terraform を使用します。

コンソール

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
3. [編集] をクリックします。
4. [インスタンスの情報] セクションで [アップグレード] ボタンをクリックし、アップグレード ページに移動します。
5. [データベースのバージョンを選択] ページで [アップグレード後のデータベース バージョン] リストをクリックし、使用可能なデータベースのメジャー バージョンの 1 つを選択します。
6. [次へ] をクリックします。
7. [インスタンス ID] ボックスにインスタンスの名前を入力し、[アップグレードを開始] ボタンをクリックします。

クエリが完了するまでに数分かかります。

アップグレード後のデータベースのメジャー バージョンが、インスタンスの概要ページのインスタンス名の下に表示されていることを確認します。

gcloud

1. アップグレードを開始する

   gcloud sql instances patch コマンドに --database-version フラグを指定します。

   コマンドを実行する前に、次の変数を置き換えます。

   • INSTANCE_NAME: インスタンスの名前。
   • DATABASE_VERSION: データベースのメジャー バージョンの列挙型。これは、現在のバージョンより大きくする必要があります。インスタンスのアップグレード ターゲットとして使用できるメジャー バージョンのデータベース バージョンを指定します。この列挙型は、アップグレードの計画の最初のステップとして取得できます。データベース バージョンの列挙型の完全なリストが必要な場合は、SqlDatabaseEnums をご覧ください。

   gcloud sql instances patch INSTANCE_NAME \
   --database-version=DATABASE_VERSION

   メジャー バージョンのアップグレードが完了するまで数分かかります。オペレーションに予想より時間がかかっていることを示すメッセージが表示される場合があります。このメッセージは無視するか、gcloud sql operations wait コマンドを実行してメッセージを閉じます。

2. アップグレード オペレーション名を取得します。

   gcloud sql operations list コマンドを使用して、--instance フラグを指定します。

   コマンドを実行する前に、INSTANCE_NAME 変数をインスタンス名に置き換えます。

   gcloud sql operations list --instance=INSTANCE_NAME

3. アップグレードのステータスをモニタリングします。

   gcloud sql operations describe コマンドを使用します。

   コマンドを実行する前に、OPERATION 変数を前の手順で取得したアップグレード オペレーション名に置き換えます。

   gcloud sql operations describe OPERATION

REST v1

1. インプレース アップグレードを開始します。

   instances:patch メソッドでの PATCH リクエストを使用します。

   リクエスト データを使用する前に、次の変数を置き換えます。

   • PROJECT_ID: プロジェクトの ID。
   • INSTANCE_NAME: インスタンスの名前。

   HTTP メソッドと URL:

   PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

   リクエストの本文（JSON）:

   {
     "databaseVersion": DATABASE_VERSION
   }

   DATABASE_VERSION は、データベースのメジャー バージョンの列挙型に置き換えます。これは、現在のバージョン移行のものにする必要があります。インスタンスのアップグレード ターゲットとして使用できるメジャー バージョンのデータベース バージョンを指定します。この列挙型は、アップグレードの計画の最初のステップとして取得できます。データベース バージョンの列挙型の一覧については、SqlDatabaseVersion をご覧ください。

2. アップグレード オペレーション名を取得します。

   PROJECT_ID をプロジェクトの ID に置き換えて、operations.list メソッドでの GET リクエストを使用します。

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

3. アップグレードのステータスをモニタリングします。

   次の変数を置き換えて、operations.get メソッドでの GET リクエストを使用します。

   • PROJECT_ID: プロジェクトの ID。
   • OPERATION_NAME: 前の手順で取得したアップグレード オペレーション名。

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

データベースのバージョンを更新するには、Terraform リソースと Google Cloud の Terraform プロバイダのバージョン 4.34.0 以降を使用します。

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

変更を適用する

Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。

Cloud Shell を準備する

1. Cloud Shell を起動します。

2. Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。

   このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。

   export GOOGLE_CLOUD_PROJECT=PROJECT_ID

   Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。

ディレクトリを準備する

Terraform 構成ファイルには独自のディレクトリ（ルート モジュールとも呼ばれます）が必要です。

1. Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は .tf にする必要があります（例: main.tf）。このチュートリアルでは、このファイルを main.tf とします。

   mkdir DIRECTORY && cd DIRECTORY && touch main.tf

2. チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。

   新しく作成した main.tf にサンプルコードをコピーします。

   必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。

3. 環境に適用するサンプル パラメータを確認し、変更します。
4. 変更を保存します。
5. Terraform を初期化します。これは、ディレクトリごとに 1 回だけ行う必要があります。

   terraform init

   必要に応じて、最新バージョンの Google プロバイダを使用する場合は、-upgrade オプションを使用します。

   terraform init -upgrade

変更を適用する

1. 構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。

   terraform plan

   必要に応じて構成を修正します。

2. 次のコマンドを実行し、プロンプトで「yes」と入力して、Terraform 構成を適用します。

   terraform apply

   Terraform に「Apply complete!」のメッセージが表示されるまで待ちます。

3. Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。

注: Terraform のサンプルでは通常、必要な API が Google Cloud プロジェクトで有効になっていることを前提としています。

変更を削除する

変更を削除するには、次の手順を行います。

1. 削除の保護を無効にするには、Terraform 構成ファイルで deletion_protection 引数を false に設定します。

   deletion_protection =  "false"

2. 次のコマンドを実行し、プロンプトで「yes」と入力して、更新された Terraform 構成を適用します。

   terraform apply

3. 次のコマンドを実行しています。プロンプトで「yes」と入力して、以前に Terraform 構成で適用されたリソースを削除します。

   terraform destroy

インプレース アップグレード リクエストを行うと、Cloud SQL はまずアップグレード前のチェックを行います。Cloud SQL でインスタンスのアップグレードの準備ができていないと判断された場合、アップグレード リクエストは失敗し、問題に対処する方法を提案するメッセージが表示されます。メジャー バージョン アップグレードのトラブルシューティングもご覧ください。

注: Cloud SQL では、インスタンスがデフォルトのマイナー バージョンに自動的にプロビジョニングされます。

自動アップグレードのバックアップ

メジャー バージョン アップグレードを実行すると、Cloud SQL は 2 つのオンデマンド バックアップ（アップグレード バックアップと呼ばれます）を自動的に作成します。

• 最初のアップグレード バックアップは、アップグレード前のバックアップで、アップグレードの直前に作成されます。このバックアップは、データベース インスタンスを以前のバージョンの状態に復元するために使用できます。
• 2 番目のアップグレード バックアップは、アップグレード後のバックアップで、アップグレードされたデータベース インスタンスへの新しい書き込みが許可された直後に作成されます。

バックアップのリストを表示すると、On-demand タイプでアップグレード バックアップが一覧表示されます。アップグレード バックアップには、簡単に識別できるようにラベルが付いています。たとえば、MySQL 5.7 から MySQL 8.0 にアップグレードする場合、アップグレード前のバックアップには Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. ラベルが付き、アップグレード後のバックアップには Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7. が付きます。MySQL 8.0 から MySQL 8.4 にアップグレードする場合、アップグレード前のバックアップには Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. ラベルが付き、アップグレード後のバックアップには Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0. が付きます。

他のオンデマンド バックアップと同様に、アップグレード バックアップは、それを削除するかインスタンスを削除するまで残ります。PITR が有効になっていると、保持期間中のアップグレード バックアップは削除できません。アップグレード バックアップを削除する必要がある場合は、PITR を無効にするか、アップグレード バックアップの保持期間が終了するまで待つ必要があります。

メジャー バージョン アップグレードを実行する

プライマリ インスタンスのアップグレードが終了したら、次の手順でアップグレードを実行します。

1. 承認テストを実行します。

   テストを実行して、アップグレードしたシステムが期待どおりに動作することを確認します。

2. 省略可: ユーザーの権限を更新します。

   MySQL 8.0 にアップグレードした場合、MySQL によってセキュリティとアカウント管理のシステムが変更されている点に注意してください。詳細については、MySQL 8.0 の新機能をご覧ください。

   これにより、MySQL 5.7 バージョンのインスタンスで作成されたユーザーが、MySQL 8.0 で直接作成されたユーザーと同じ権限を持たないことがあります。たとえば、MySQL 5.7 からアップグレードされたユーザーには、CREATE ROLE 権限と DROP ROLE 権限がない可能性があります。MySQL 5.7 にはこれらの権限が存在しなかったためです。Cloud SQL では、バージョンをアップグレードした後にユーザー権限をリセットして、ユーザー権限に関連する問題を修正することをおすすめします。

   MySQL 8.0 から MySQL 8.4 にアップグレードした場合、MySQL 8.4 で導入された権限の追加や、MySQL 8.0 に存在した権限の削除など、ユーザー権限に追加の変更があります。詳細については、MySQL 8.4 のユーザー権限（cloudsqlsuperuser）をご覧ください。

   MySQL 8.0 または MySQL 8.4 でユーザー権限を更新するには、次の操作を行います。

   1. cloudsqlsuperuser ロールが付与されたユーザーを作成します。

   2. 作成したユーザーを使用して、以下を以て、アップグレードされたユーザーの以前のすべての権限を取り消します。

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

   3. アップグレードしたユーザーに適切な権限を付与します。

3. 省略可: バックアップを作成します。

   Cloud SQL では、プライマリ インスタンスをアップグレードすると、自動的にバックアップが作成されますが、必要に応じてデータベースを復元できるように、自分でバックアップを作成することをおすすめします。

4. 省略可: Cloud SQL for MySQL 8.4 にアップグレードした場合は、すべてのコネクタ、クライアント、MySQL シェルを MySQL 8.4 に更新します。

メジャー バージョン アップグレードのトラブルシューティング

無効なアップグレード コマンド（インスタンスに新しいバージョンの無効なデータベース フラグが含まれている場合など）を試行すると、Cloud SQL はエラー メッセージを返します。

アップグレード リクエストが失敗した場合は、アップグレード リクエストの構文を確認してください。リクエストに有効な構造がある場合は、次の推奨事項を確認してください。

アップグレード ログを表示する

有効なアップグレード リクエストでエラーが発生した場合、Cloud SQL はエラーログを projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err に公開します。各ログエントリには、インスタンス ID のラベルが付いているため、アップグレード エラーが発生したインスタンスを識別できます。このようなアップグレード エラーを見つけて解決します。

エラーログを表示するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。

3. インスタンスの [概要] ページの [オペレーションとログ] ペインで、[MySQL のエラーログを表示] リンクをクリックします。

   [ログ エクスプローラ] ページが開きます。

4. 次のようにログを表示します。

   • プロジェクト内のエラーログすべてを一覧表示するには、ログ名を選択して、[ログ名] でフィルタリングします。

   クエリフィルタの詳細については、高度なクエリをご覧ください。

   • 単一のインスタンスのアップグレード エラーログをフィルタリングするには、DATABASE_ID を次のように置き換えてから、[すべてのフィールドを検索] ボックスに次のクエリを入力します。

   プロジェクト ID に置き換え、その後に project_id:instance_name という形式のインスタンス名を続けます。

   resource.type="cloudsql_database"
   resource.labels.database_id="DATABASE_ID"
   logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

   たとえば、プロジェクト buylots で実行されている shopping-db という名前のインスタンスでアップグレード エラーログをフィルタリングするには、次のクエリフィルタを使用します。

    resource.type="cloudsql_database"
    resource.labels.database_id="buylots:shopping-db"
    logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

以前のメジャー バージョンに戻す

アップグレードしたデータベース システムが期待どおりに機能しない場合は、インスタンスを以前のバージョンに復元しなければならないことがあります。その場合は、アップグレード前のバックアップを Cloud SQL のリカバリ インスタンスに復元します。これは、アップグレード前のバージョンを実行する新しいインスタンスです。

以前のバージョンに復元する手順は、次のとおりです。

1. アップグレード前のバックアップを特定します。

   自動アップグレード バックアップをご覧ください。

2. 復元インスタンスを作成します。

   アップグレード前のバックアップの作成時に Cloud SQL で実行されていたメジャー バージョンを使用して、新しい Cloud SQL インスタンスを作成します。元のインスタンスと同じフラグとインスタンスの設定を使用します。

3. アップグレード前のバックアップを復元します。

   アップグレード前のバックアップをリカバリ インスタンスに復元します。完了には数分かかる場合があります。

4. リードレプリカを追加します。

   リードレプリカを使用していた場合は、それらを個別に追加します。

5. アプリケーションを接続します。

   データベース システムをリカバリしたら、リカバリ インスタンスとそのリードレプリカの詳細でアプリケーションを更新します。アップグレード前のバージョンのデータベースでトラフィックの処理を再開できます。

制限事項

このセクションでは、メジャー バージョンのインプレース アップグレードの制限事項について説明します。

• 外部レプリカでは、メジャー バージョンのインプレース アップグレードを実行できません。
• MySQL 5.7 から 8.0 へのインスタンスのアップグレードで、512,000 個を超えるテーブルがあると長い時間がかかりタイムアウトする可能性がある。
• MySQL 8.0 から 8.4 へのインスタンスのアップグレードで、512,000 個を超えるテーブルがあると長い時間がかかりタイムアウトする可能性があります。

• MySQL 8.0 から 8.4 にアップグレードするときに、レプリカを MySQL 8.4 にアップグレードしてもプライマリ インスタンスをアップグレードしなかった場合、非アップグレードされたプライマリ インスタンスに、非推奨の mysql_native_password 認証プラグインを使用して新しいユーザー アカウントを作成できます。この状況を回避するには、レプリカをアップグレードした直後にプライマリ インスタンスをアップグレードするか、次のコマンドを使用してプライマリ インスタンスにのみ新しいユーザー アカウントを作成します。

  CREATE USER USERNAME'@'% IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

  USERNAME と PASSWORD は適切な値に置き換えてください。

よくある質問

データベースのメジャー バージョンをアップグレードするときは、次のような疑問が生じることがあります。

アップグレード中はインスタンスを使用できませんか？

はい。Cloud SQL がアップグレードを実行する間、インスタンスは一定期間使用できません。

アップグレードにはどれくらい時間がかかりますか？

通常、1 つのインスタンスのアップグレードには 10 分もかかりません。インスタンス構成で使用されている vCPU またはメモリが少ない場合、アップグレードに時間がかかることがあります。

インスタンスでホストされているデータベースやテーブルが多すぎる場合や、データベースが非常に大きい場合は、アップグレードに数時間がかかったりタイムアウトになることがあります。これは、アップグレード時間がデータベース内のオブジェクト数と対応するためです。アップグレードが必要なインスタンスが複数ある場合は、それに比例してアップグレードの合計時間が長くなります。

アップグレード プロセスの各ステップをモニタリングできますか？

Cloud SQL ではアップグレード オペレーションが進行中かどうかをモニタリングできますが、アップグレードの個々のステップを追跡することはできません。

開始後にアップグレードをキャンセルできますか？

いいえ、アップグレードを開始すると、キャンセルはできません。アップグレードに失敗すると、Cloud SQL は以前のバージョンのインスタンスを自動的に復元します。

アップグレード中に設定はどうなりますか？

インプレースのメジャー バージョン アップグレードを実行すると、Cloud SQL はインスタンス名、IP アドレス、明示的に構成されたフラグ値、ユーザーデータなどのデータベース設定を保持します。ただし、システム変数のデフォルト値は変更されることがあります。たとえば、MySQL 5.7 の character_set_server フラグのデフォルト値は utf8 です。MySQL 8.0 にアップグレードすると、フラグのデフォルト値は utf8mb4 に変更されます。utf8 に戻すには、フラグの値を前の値に設定します。

詳細については、データベース フラグを構成するをご覧ください。特定のフラグまたは値がターゲット バージョンでサポートされなくなった場合、Cloud SQL はアップグレード中にフラグを自動的に削除します。

レプリカをアップグレードした後にレプリケーションが中断された場合、どうすればよいですか？

レプリカのアップグレード後にレプリケーションが中断すると、プライマリ インスタンスの MySQL バージョンにロールバックされます。レプリカは再度アップグレードできますが、問題が解決していないと、レプリケーションが再び中断する可能性があります。

レプリカがロールバックされない場合は、次の 2 つの方法があります。

1. 壊れたレプリカを削除し、新しいレプリカを作成して、その新しいレプリカをアップグレードします。

   アップグレードが再び失敗した場合は、アップグレード時に互換性のない変更がプライマリに追加されたことにより失敗した可能性があります。アップグレードで問題を特定し、プライマリ インスタンスを修正して、レプリカをアップグレードしてみてください。詳細については、トラブルシューティングをご覧ください。

2. プライマリ インスタンスをアップグレードします。

   レプリカ スレッドが機能していない場合、プライマリ インスタンスのアップグレード オペレーションでレプリカが再作成されます。

アップグレードしたレプリカが古いバージョンにロールバックされたのはなぜですか？

アップグレードに失敗すると、レプリカは、プライマリ インスタンスのバージョンにロールバックされます。レプリカを再度アップグレードすることは可能ですが、問題が解決しない場合は、レプリカの mysql.err ログを確認して原因を突き止めることができます。[REPL]... failed executing transaction.... end_log_pos...; Failure Reason などのキーワードを検索してください。

エラー メッセージに Access denied for AuthId.... が含まれている場合は、mysql と sys スキーマで MySQL 5.7 のユーザー権限を使用してクエリが実行されている可能性があり、MySQL 8.0 のセキュリティおよびアカウント管理システムの変更により失敗する可能性があります。この問題を解決するには、プライマリ インスタンスを新しいバージョンにアップグレードする前に、プライマリ インスタンスのクエリを停止し、レプリカのアップグレードを再試行する必要があります。Cloud SQL では、同様の問題を引き起こす可能性があるため、新しいバージョンにアップグレードする前に、プライマリ インスタンスでも、そのようなクエリすべてを一時的に停止することをおすすめします。

MySQL ログに Access denied for AuthID.... などの失敗理由が表示されない場合は、レプリカがアップグレードされた後にプライマリ インスタンスに追加された、互換性のない新しいデータが問題の原因である可能性があります。アップグレードする前に、非互換の問題の修正に関して、メジャー バージョン アップグレードの準備をご覧ください。

次のステップ

• インスタンスへの接続オプションについて学習します。
• データのインポートとエクスポートについて学習する。
• データベース フラグの設定について学ぶ