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

MySQL   |  PostgreSQL   |  SQL Server

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

はじめに

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

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

Cloud SQL for PostgreSQL のインプレース アップグレードでは、pg_upgrade ユーティリティを使用します。

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

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

   Cloud SQL でサポートされているバージョンのリストをご覧ください。

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

   • PostgreSQL 15
   • PostgreSQL 14
   • PostgreSQL 13
   • PostgreSQL 12
   • PostgreSQL 11
   • PostgreSQL 10

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

   注: Cloud SQL for PostgreSQL をバージョン 10 からアップグレードする場合は、バージョン 11 をスキップする必要があります。

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

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

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

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

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

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

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

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

1. template データベースと postgres データベースの LC_COLLATE の値を確認します。各データベースの文字セットは en_US.UTF8 にする必要があります。

   template と postgres データベースの LC_COLLATE 値が en_US.UTF8 でない場合、メジャー バージョン アップグレードは失敗します。これを修正するには、いずれかのデータベースに en_US.UTF8 以外の文字セットがある場合、アップグレードを行う前に LC_COLLATE の値を en_US.UTF8 に変更します。

   データベースのエンコードを変更するには:

   1. データベースをダンプします。
   2. データベースを削除します。
   3. 異なるエンコードで新しいデータベースを作成します（この例として: en_US.UTF8）。
   4. データを再読み込みします。

2. リードレプリカを管理します。

   Cloud SQL for PostgreSQL はクロス バージョン レプリケーションをサポートしていません。つまり、インスタンスがリードレプリカに複製している間は、プライマリ インスタンスをアップグレードできません。アップグレードを行う前に、リードレプリカごとにレプリケーションを無効にするか、リードレプリカを削除します。

3. Cloud SQL が論理レプリケーションのソースの場合は、次のように pglogical 拡張レプリケーションを無効にします。これは、アップグレード後に再度有効にできます。Cloud SQL が論理レプリケーションのターゲットの場合、これらの手順を行う必要はありません。
   1. 次のコマンドを使用してサブスクリプションを無効にし、プロバイダからレプリカの接続を解除します。

      SELECT * FROM pglogical.alter_subscription_disable(subscription_name name, immediate bool);

      name は、既存のサブスクリプションの名前に置き換えます。

      サブスクリプションをすぐに無効にする場合は、immediate パラメータの値を true に設定します。デフォルト値は false です。サブスクリプションは、現在のトランザクションが終了した後に無効になります。

      次に例を示します。

      postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub', true);
       alter_subscription_disable
      ----------------------------
       t
      (1 row)

   2. パブリッシャーまたは Cloud SQL プライマリ インスタンスに接続して次のコマンドを実行し、レプリケーション スロットを削除します。

      SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
        WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

      次に例を示します。

      postgres=> SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots
      postgres->    WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
      -[ RECORD 1 ]------------+-
      pg_drop_replication_slot |
      
      postgres=>

4. 残りの PostgreSQL の拡張機能を管理します。

   ほとんどの拡張機能は、アップグレードされたデータベースのメジャー バージョンで動作します。ターゲット バージョンでサポートされなくなった拡張機能がある場合は、それを削除します。たとえば、PostgreSQL 11 以降のバージョンにアップグレードする場合は、chkpass 拡張機能を削除します。

   PostGIS と関連拡張機能をサポートされている最新バージョンに手動でアップグレードできます。 PostGIS バージョンが 3.1 より古い場合は、次のコマンドを使用して PostGIS 拡張機能をアップグレードします。

       ALTER EXTENSION postgis UPDATE TO '3.1.7';

   注: 3.1 より古いバージョンの PostGIS のアップグレードには、次のコマンドを使用しないでください。このコマンドは、PostGIS をバージョン 3.2.3 にアップグレードします。これは Cloud SQL ではサポートされていません。

       SELECT postgis_extensions_upgrade();

   PostGIS バージョン 2.x からアップグレードすると、PostGIS 拡張機能に関連付けられていない残りのデータベース オブジェクトが存在することがあります。これにより、アップグレード オペレーションがブロックされます。この問題を解決する方法については、壊れた PostGIS ラスターのインストールを修正するをご覧ください。
   PostGIS 拡張機能のアップグレードの詳細については、PostGIS のアップグレードをご覧ください。 PostGIS のアップグレードに関連する問題については、PostgreSQL インスタンスのバージョンの確認をご覧ください。
   注: PostGIS 拡張機能を有効にしている場合は、PostgreSQL 15 にアップグレードできません。拡張機能を削除し、アップグレードを実行してから、拡張機能を再インストールしてください。
5. カスタム データベース フラグを管理します。PostgreSQL インスタンスに構成したカスタム データベース フラグの名前を確認します。これらのフラグに関連する問題については、PostgreSQL インスタンスのカスタムフラグを確認するをご覧ください。
6. あるメジャー バージョンから別のメジャー バージョンへのアップグレードを行う場合は、各データベースに接続して、互換性の問題があるかどうかを確認します。データベースが互いに接続できることを確認します。各データベースの datallowconn フィールドで接続が許可されていることを確認します。t 値は許可されていることを示し、f 値は接続を確立できないことを示します。

既知の制限事項

Cloud SQL for PostgreSQL のインプレース メジャー バージョン アップグレードには、次の制限が影響します。

• 1,000 を超えるデータベースを持つインスタンスをあるバージョンから別のバージョンにアップグレードするには、長い時間がかかり、タイム・アウトする可能性があります。
• select * from pg_largeobject_metadata; ステートメントを使用して、Cloud SQL インスタンスの各 PostgreSQL データベースに含まれる大規模オブジェクトの数を取得します。すべてのデータベースの結果が 1, 000 万件を超える大規模なオブジェクトである場合、アップグレードは失敗します。Cloud SQL はデータベースを以前のバージョンにロールバックします。

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

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

注: レプリカまたはレプリカを持つインスタンスをアップグレードする場合は、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: データベースのメジャー バージョンの列挙型。これは、現在のバージョンより大きくする必要があります。利用可能なデータベース バージョンの列挙型をご覧ください。

   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. インプレース アップグレードを開始します。

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

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

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

   HTTP メソッドと URL:

   POST https://sqladmin.googleapis.com/sql/v1/projects/project-id/instances/instance_name

   JSON 本文のリクエスト

   {
     "databaseVersion": enum DATABASE_VERSION
   }

   DATABASE_VERSION は、データベースのメジャー バージョンの列挙型に置き換えます。これは、現在のバージョンよりも大きいものにする必要があります。利用可能なデータベース バージョンの列挙型をご覧ください。

   curl または PowerShell を使用してリクエストを送信します。インスタンスの編集をご覧ください。

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

   project_id をプロジェクトの ID に置き換えて、operations.list メソッドを含む GET リクエストを送信します。

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/sql/v1/projects/project-id/operations

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

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

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

   HTTP メソッドと URL:

   GET https://sqladmin.googleapis.com/sql/v1/projects/project-id/operation/operation_name

Terraform

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

cloud_sql/postgres_database_instance/main.tf

GitHub で表示 フィードバック

resource "google_sql_database_instance" "instance" {
  name             = "postgres-instance"
  region           = "us-central1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
  }
  # 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 タイプでアップグレード バックアップが一覧表示されます。アップグレード バックアップには、簡単に識別できるようにラベルが付いています。たとえば、PostgreSQL 9.6 から PostgreSQL 13 にアップグレードする場合、アップグレード前のバックアップには Pre-upgrade backup, POSTGRES_9_6 to POSTGRES_13. というラベルが付き、アップグレード後のバックアップには Post-upgrade backup, POSTGRES_13 from POSTGRES_9_6. が付いています。

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

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

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

1. アップグレード前にインスタンスで pglogical レプリケーションを使用していた場合は、これを有効にします。これにより、必要なレプリケーション スロットが自動的に作成されます。
   1. 次のコマンドを使用して、宛先レプリカの pglogical サブスクリプションを削除します。

      select pglogical.drop_subscription(subscription_name name);

      name は、既存のサブスクリプションの名前に置き換えます。

      次に例を示します。

      postgres=> select pglogical.drop_subscription(subscription_name := 'test_sub');
      -[ RECORD 1 ]-----+--
      drop_subscription | 1

   2. Cloud SQL プライマリ インスタンスに次のように接続の詳細を提供し、移行先（レプリカ）で pglogical サブスクリプションを再作成します。

      SELECT pglogical.create_subscription(
          subscription_name := 'test_sub',
          provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
      ); 

      次に例を示します。

      postgres=> SELECT pglogical.create_subscription(
      postgres(>     subscription_name := 'test_sub',
      postgres(>     provider_dsn := 'host=10.58.64.90 port=5432 dbname=postgres user=postgres password=postgres'
      postgres(> );
      -[ RECORD 1 ]-------+-----------
      create_subscription | 2769129391

   3. 次のコマンドを使用して、サブスクリプションのステータスを確認します。

      SELECT * FROM pglogical.show_subscription_status('test_sub');

   4. レプリケーションをテストします。書き込みトランザクションを実行して、変更が宛先に反映されていることを確認します。

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

   リードレプリカのレプリケーションを停止した場合は、これらを個別にアップグレードします。プライマリ インスタンスのアップグレードに使用した任意の方法を使用できます。レプリカをアップグレードすると、Cloud SQL は IP アドレスを保持したままレプリカを再作成します。プライマリの最新のデータで更新し、レプリカを再起動します。

   注: プライマリ インスタンスをアップグレードするまで、リードレプリカはアップグレードできません。

   プライマリ インスタンスをアップグレードする前にリードレプリカを削除した場合は、新しいリードレプリカを作成できます。これは、アップグレードされたデータベース バージョンに自動的にプロビジョニングされます。

3. データベースの統計情報を更新します。

   アップグレード後に、プライマリ インスタンスで ANALYZE を実行し、システム統計情報を更新します。正確な統計情報があれば、PostgreSQL クエリ プランナーが最適なクエリ処理を行うことができます。統計情報がないと、クエリプランが低品質になり、パフォーマンスが低下してメモリが過剰に消費される可能性があります。

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

   アップグレード後のシステムが想定どおり動作することを確認するために、テストを実施する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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%2Fpostgres-upgrade.log"

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

    resource.type="cloudsql_database"
    resource.labels.database_id="buylots:shopping-db"
    logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"
    ```
   

接頭辞が pg_upgrade_dump のログエントリはアップグレード エラーが発生したことを示します。次に例を示します。

pg_upgrade_dump: error: query failed: ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

また、.txt セカンダリ ファイル名でラベル付けされたログエントリには、アップグレードを再試行する前に解決できるその他のエラーが含まれている場合もあります。

すべてのファイル名が postgres-upgrade.log ファイルにあります。ファイル名を確認するには、labels.FILE_NAME フィールドを確認します。

解決するエラーがあるファイル名には次が含まれます。

• tables_with_oids.txt: このファイルには、オブジェクト ID（OID）で一覧表示されたテーブルが含まれます。テーブルを削除するか、OID を使用しないようにテーブルを変更します。
• tables_using_composite.txt: このファイルには、システム定義の複合タイプを使用して一覧表示されたテーブルが含まれます。テーブルを削除するか、これらの複合タイプを使用しないようにテーブルを変更します。
• tables_using_unknown.txt:: このファイルには、UNKNOWN データ型を使用してリストされるテーブルが含まれます。テーブルを削除するか、テーブルでこのデータ型が使用されないように変更します。
• tables_using_sql_identifier.txt:: このファイルには、SQL_IDENTIFIER データ型を使用してリストされるテーブルが含まれます。テーブルを削除するか、テーブルでこのデータ型が使用されないように変更します。
• tables_using_reg.txt: このファイルには、REG* データ型（REGCOLLATION や REGNAMESPACE など）を使用して一覧表示されたテーブルが含まれます。テーブルを削除するか、テーブルでこのデータ型が使用されないように変更します。
• postfix_ops.txt: このファイルには、postfix（右単項）演算子を使用してリストされたテーブルが含まれます。テーブルを削除するか、テーブルでこれらの演算子が使用されないように変更します。

メモリを確認する

インスタンスの共有メモリが不足している場合、「ERROR: out of shared memory.」というエラー メッセージが表示されることがあります。このエラーは、テーブル数が 10,000 個を超えると発生する可能性が高くなります。

アップグレードを行う前に、max_locks_per_transaction フラグの値をインスタンス内のテーブルの約 2 倍に設定します。このフラグの値を変更すると、インスタンスは再起動されます。

接続容量を確認する

インスタンスの接続容量が不足している場合は、「ERROR: Insufficient connections.」というエラー メッセージが表示されることがあります。

Cloud SQL では、max_connections フラグの値をインスタンス内のデータベース数だけ増やすことをおすすめします。このフラグの値を変更すると、インスタンスは再起動されます。

PostgreSQL インスタンスのバージョンを確認する

Cloud SQL for PostgreSQL インスタンスのバージョン 9.6、10、または 11 を使用していて、そのインスタンスで PostGIS 拡張機能を有効にした場合、権限の問題が原因で PostGIS のアップグレードが失敗することがあります。この問題を解決するには、セルフサービス メンテナンスを使用して最新のシステム マネージャー（SSM）イメージをロールアウトします。これにより、PostGIS をアップグレードする権限が付与されます。

PostgreSQL インスタンスのカスタムフラグを確認する

バージョン 14 以降の PostgreSQL インスタンスにアップグレードする場合は、インスタンスに構成したカスタム データベース フラグの名前を確認します。これは、PostgreSQL がカスタム パラメータに使用できる名前に制限を追加したためです。

カスタム データベース フラグの最初の文字は、アルファベット（A～Z または a～z）にする必要があります。後続のすべての文字には、英数字、アンダースコア（_）特殊文字、ドル記号（$）特殊文字を使用できます。

広告表示オプションを削除する

Cloud SQL インスタンスをバージョン 10 からバージョン 14 にアップグレードする場合、「pg_restore: error: could not execute query: ERROR: role "16447" does not exist」というエラー メッセージが表示されることがあります。

この問題を解決する方法は次のとおりです。

1. pg_stat_statements 拡張機能と pgstattuple 拡張機能を削除します。
2. アップグレードを実施します。
3. 拡張機能を再インストールします。

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある質問

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

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

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

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

通常、1 つのインスタンスのアップグレードには 10 分もかかりません。インスタンスで非常に多くのデータベースやテーブルがホストされている場合、データベースが非常に大きい場合、またはインスタンス構成で使用されている vCPU やメモリが少ない場合は、アップグレードにかかる時間が長くなる可能性があります。アップグレードが必要なインスタンスが複数ある場合は、それに比例してアップグレードの合計時間が長くなります。

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

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

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

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

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

インプレースのメジャー バージョン アップグレードを実行すると、Cloud SQL はインスタンス名、IP アドレス、明示的に構成されたフラグ値などのデータベース設定を保持します。ただし、システム変数のデフォルト値は変更されることがあります。たとえば、MySQL 5.7 の character_set_server のデフォルト値は utf8 です。MySQL 8.0 にアップグレードすると、デフォルト値の character_set_server が utf8mb4 に変更されます。utf8 に戻すには、データベース フラグの値を手動で古い値に変更する必要があります。詳細については、データベース フラグを構成するをご覧ください。特定のバージョンやフラグ値が対象のバージョンでサポートされなくなった場合、Cloud SQL はアップグレード中にフラグを自動的に削除します。

次のステップ

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