既知の問題

このページには、Cloud SQL for PostgreSQL の既知の問題と、これらの問題を回避したり、これらの問題から復旧したりする方法が記載されています。

インスタンスに関する問題が発生している場合は、問題の診断の情報もご覧ください。

インスタンス接続の問題

  • 期限切れの SSL / TLS 証明書

    SSL を使用するようにインスタンスを構成している場合は、Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動して、インスタンスを開きます。[接続] ページを開き、[セキュリティ] タブを選択して、サーバー証明書が有効であることを確認します。期限切れの場合は、新しい証明書を追加してローテーションする必要があります。

  • Cloud SQL Auth Proxy のバージョン

    Cloud SQL Auth Proxy を使用して接続する場合は、最新のバージョンを使用していることを確認してください。詳細については、Cloud SQL Auth Proxy の最新状態の維持をご覧ください。

  • 接続する権限がない

    接続しようとしているインスタンスがそのプロジェクトに存在しない場合、そのインスタンスにアクセスする権限がないというエラー メッセージが表示されます。

  • Cloud SQL のインスタンスを作成できない

    Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID] エラーのメッセージが表示された場合は、Cloud SQL インスタンスをもう一度作成してみてください。

  • 以下は、デフォルト ユーザー（「postgres」）でのみ機能します。gcloud sql connect --user

    他のユーザーでこのコマンドを使用して接続しようとすると、FATAL: database 'user' does not exist というエラー メッセージが表示されます。この問題を回避するには、デフォルト ユーザー（「postgres」）で接続してから、"\c" psql コマンドを使用して別のユーザーとして再接続します。

  • IAM DB プロキシ認証を有効になっていると、PostgreSQL 接続がハングします。

    -enable_iam_login フラグを指定し、TCP ソケットを使用して Cloud SQL Auth Proxy を起動する場合、TCP 接続中に PostgreSQL クライアントがハングします。回避策の 1 つは、PostgreSQL 接続文字列で sslmode=disable を使用することです。次に例を示します。

    psql "host=127.0.0.1 dbname=postgres user=me@google.com sslmode=disable"

    もう 1 つの回避策は、Unix ソケットを使用して Cloud SQL Auth Proxy を起動することです。これにより、PostgreSQL SSL 暗号化がオフになり、代わりに Cloud SQL Auth Proxy が SSL 暗号化を行います。

管理に関する問題

  • Cloud SQL のインポートまたはエクスポートを長時間実行する場合は、1 インスタンスに対して一度に 1 つのオペレーションしか実行できません。オペレーションを開始するときは、インスタンスに対して他のオペレーションを行う必要がないことを確認してください。また、オペレーションの開始時にキャンセルすることもできます。

    PostgreSQL は 1 回のトランザクションでデータをインポートします。したがって、インポート オペレーションをキャンセルした場合、Cloud SQL はインポートのデータを保持しません。

    データのインポートとエクスポートに関する問題

    • PostgreSQL バージョン 15 以降では、ターゲット データベースが template0 から作成されている場合、データのインポートが失敗し、permission denied for schema public エラー メッセージが表示されることがあります。この問題を解決するには、GRANT ALL ON SCHEMA public TO cloudsqlsuperuser SQL コマンドを実行して、cloudsqlsuperuser ユーザーに公開スキーマ権限を付与します。

    • サイズの大きい多数のオブジェクトをエクスポートすると、インスタンスが応答しなくなる

      データベースにサイズの大きい多数のオブジェクト（blob）が含まれていると、データベースをエクスポートする際に大量のメモリが消費され、インスタンスが応答しなくなる可能性があります。これは、blob が空であっても発生する場合があります。

    • Cloud SQL はカスタマイズされたテーブルスペースをサポートしていませんが、カスタマイズされたテーブルスペースから宛先インスタンスのデフォルトのテーブルスペース pg_default へのデータ移行はサポートしています。たとえば、/home/data に dbspace という名前のテーブルスペースを所有している場合、移行後 dbspace 内のすべてのデータは pg_default に移行されます。ただし Cloud SQL では、ディスク上に「dbspace」という名前のテーブルスペースは作成されません。

    • 大規模なデータベース（たとえば、500 GB 以上のデータを持つデータベース）からデータのインポートとエクスポートをしようとすると、インポートとエクスポートのオペレーションが完了するまでに長い時間がかかることがあります。さらに、インポートやエクスポートの実行中は、他のオペレーション（バックアップ オペレーションなど）を実行できません。gcloud または API を使用して以前のバックアップを復元すると、インポートとエクスポートのプロセスのパフォーマンスを向上できます。

    • Cloud Storage は、最大 5 テラバイトの単一オブジェクト サイズをサポートしています。5 TB を超えるデータベースの場合、Cloud Storage へのエクスポート オペレーションは失敗します。その場合は、エクスポート ファイルを小さなセグメントに分割する必要があります。

    トランザクション ログとディスクの増大

    ログは継続的ではなく、1 日 1 回削除されます。ログの保持日数とバックアップ数が同じ値で構成されていると、バックアップが発生するタイミングによっては、1 日分のロギングが失われる可能性があります。たとえば、ログ保持期間を 7 日に設定し、保持するバックアップの数を 7 に設定すると、6～7 日分のログが保持されます。

    バックアップの数は、保持するログの日数より 1 以上大きい数に設定することをおすすめします。

    次のリージョン名のインスタンスは、次のように、特定の状況では正しく表示されません。

    • us-central1 は us-central と表示されます。
    • europe-west1 は europe と表示されます。
    • asia-east1 は asia と表示されます。

    この問題は、次の状況で発生します。

    • Cloud Monitoring のアラート
    • Metrics Explorer
    • Cloud Logging

    リソース メタデータ ラベルを使用して、Cloud Monitoring のアラートと Metrics Explorer の問題を軽減できます。cloudsql_database のモニタリング対象リソースラベル region ではなく、システム メタデータ ラベル region を使用します。