Cloud SQL for PostgreSQL のトラブルシューティング

このページには次のトピックが含まれています。

バックアップと復元

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
現在のオペレーションのステータスを確認できない。 ユーザー インターフェースには成功または失敗のみが表示されます。 詳細については、これらのデータベース コマンドをご覧ください。
オペレーションの開始元が見つからない。 ユーザー インターフェースにはオペレーションを開始したユーザーは表示されません。 監査ロギングを使用して確認します。
自動バックアップ中のディスク容量が不足する。 インスタンスがハードディスクの容量の上限に達しました。 ファイル システムのサイズと割り当てを確認します
インスタンスの削除後にバックアップを実行できない。 インスタンスが削除されました。 エクスポートから再作成するか、猶予期間内であればカスタマー サポートにお問い合わせください。
自動バックアップが停止している可能性がある。 バックアップ時間はデータベースのサイズと相関しています。 オペレーションをキャンセルする必要がある場合は、カスタマー サポートお問い合わせください
復元に失敗した。 ダンプファイルに、まだ存在していないデータベース ユーザーが含まれている可能性があります。 復元する前にデータベース ユーザーを作成します
このインスタンスに対するオペレーションが無効。 コピー先インスタンスのサイズがコピー元よりも小さくなります。 宛先インスタンスのサイズを増やします
自動バックアップを保持する日数を増やす。 保持される自動バックアップは 7 つのみです。 手動バックアップを管理します
バックアップ失敗時の不明なエラー。 バックアップがタイムアウトした可能性があります。 これらのフラグを確認します。
バックアップの失敗について通知されない。 バックアップ失敗の通知はサポートされていません。 バックアップのステータスを確認するには、REST API または gcloud コマンドを使用します。
インスタンスがエラー状態とバックアップ復元状態の間でループし、停止する トラフィックが多すぎるか、オープン接続が多すぎます。 autovacuum 設定と再試行ロジックを確認します
バックアップにデータがない。 ログに記録されていないテーブルはバックアップに含まれません。 ログに記録されていないテーブルは使用しないでください

現在のオペレーションのステータスを確認できない

Google Cloud Console でオペレーションのステータスを確認することはできません。

次のような問題が考えられます

Google Cloud Console では、完了時に成功または失敗のみが表示され、警告は返されません。

次の方法をお試しください

データベースに接続し、SHOW WARNINGS を実行します。


オペレーションの開始元が見つからない

オンデマンド バックアップ オペレーションを開始したユーザーを確認する場合。

次のような問題が考えられます

Google Cloud Console のインスタンス オペレーション ページには、オペレーションを開始したユーザーは表示されません。

次の方法をお試しください

ログを確認し、テキストでフィルタしてユーザーを見つけます。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。

  • cloudsql.googleapis.com/postgres.log
  • Cloud Audit Logs が有効になっている場合は、cloudaudit.googleapis.com/activity も使用できます。


自動バックアップ中のディスク容量が不足する

エラー メッセージ [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written. が表示されます。

次のような問題が考えられます

インスタンスが自動バックアップ中にハードリミットに達しました。一時ファイルは、バックアップ中に使用可能なディスク容量を超える可能性があります。

次の方法をお試しください

ディスクに空きがあること、ディスク割り当てが不足していないことを確認します。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。


インスタンスの削除後にバックアップを実行できない

インスタンスを削除した後はバックアップを実行できません。

次のような問題が考えられます

インスタンスが削除されました。

次の方法をお試しください

  • Cloud SQL インスタンスの削除の猶予期間は 4 日間です。この間、カスタマー サポートがインスタンスを再作成できます。インスタンスを削除した後は、データを復元できません。
  • エクスポートを行った場合は、新しいインスタンスを作成してからインポートを実行して、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。

自動バックアップが停止している

自動バックアップが長時間停止していて、キャンセルできません。

次のような問題が考えられます

データベースのサイズによっては、バックアップに時間がかかる可能性があります。

次の方法をお試しください

オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの force restart を依頼できます。


バックアップからの復元が失敗した

SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。

次のような問題が考えられます

SQL ダンプを復元する前に、オブジェクトを所有しているか、またはダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが存在する必要があります。 そうでない場合、復元で、元の所有権や権限でのオブジェクトの再作成に失敗します。

次の方法をお試しください

SQL ダンプから復元する前に、データベース ユーザーを作成します。


このインスタンスに対するオペレーションが無効

instances.restoreBackup に対する API 呼び出しからのエラー メッセージ HTTP Error 400: This operation isn't valid for this instance が表示されます。

次のような問題が考えられます

バックアップ サイズ(XX GB)がストレージ サイズ(YY GB)より小さいインスタンスには、バックアップから復元できません。

次の方法をお試しください

ターゲット インスタンスを編集して、ストレージ サイズを増やします。


インスタンスがエラー状態とバックアップ復元状態の間でループし、停止する

インスタンスがエラー状態とバックアップ復元状態の間でループすることで、インスタンスが繰り返し失敗します。復元後にデータベースに接続して使用しようとすると失敗します。

次のような問題が考えられます

  • オープン接続が多すぎる可能性があります。接続数が多すぎる原因として、切断された接続をクリーンアップする autovacuum 設定が存在しないために接続の途中でエラーが発生していることが考えられます。
  • 数回エラーが起きても停止しない再試行ロジックがカスタムコードに使用されているために、ループが発生している可能性があります。
  • トラフィックが多すぎる可能性があります。接続プーリングなどの接続のベスト プラクティスを使用してください。

次の方法をお試しください

  1. データベースが autovacuum を使用する設定になっていることを確認します。
  2. カスタムコードに接続再試行ロジックが設定されているかを確認します。
  3. データベースが復旧するまでトラフィックを減らしてから、徐々にトラフィックを増やします。

バックアップにデータがない

バックアップ / 復元オペレーションを実行したときにデータの欠落が見つかることがあります。

次のような問題が考えられます

テーブルがログに記録されずに作成されました。次に例を示します。

CREATE UNLOGGED TABLES

これらのテーブルはバックアップには含まれません。

次の方法をお試しください

ログに記録されていないテーブルは使用しないでください。 CREATE TABLE コマンドから UNLOGGED を削除します。


自動バックアップを保持する日数を増やす

自動バックアップを保持できる日数を 7 日から 30 日以上に増やす場合。

次のような問題が考えられます

保持されるバックアップは 7 つのみです。バックアップの保持には費用がかかり、ディスク容量が必要となるため、バックアップは定期的に削除されます。残念ながら、現在表示されているバックアップのみが復元可能な自動バックアップです。

次の方法をお試しください

バックアップを無期限に保持する場合、自動バックアップと同じ方法で削除されないので、オンデマンド バックアップを作成します。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、そのインスタンスが属しているインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。


バックアップ失敗時の不明なエラー

バックアップに失敗すると、Unknown error と表示されます。

次のような問題が考えられます

バックアップの作成の時間が、タイムアウト時間である 10 分に達しています。自動バックアップには 10 分のタイムアウトが設定されており、その時間内にバックアップが終了することになっています。

次の方法をお試しください

バックアップの作成に影響するフラグは checkpoint_timeoutcheckpoint_completion_target の 2 つです。バックアップの開始時に slow チェックポイントが実行されます。このチェックポイントは、checkpoint_completion_targetcheckpoint_timeout を掛けた時間がかかります。

例: 900 sec * 0.9 sec = 810 sec = 13.5 min。このため、タイムアウトが発生します。この場合は、checkpoint_completion_target の値を減らすことにより問題が解決されます。

バックアップの失敗について通知されない

自動バックアップが失敗しましたが、通知を受信しませんでした。

次のような問題が考えられます

バックアップ失敗の通知はサポートされていません。

自動バックアップが失敗すると、Cloud SQL インスタンスの Details ページに Operation error メッセージが表示されます。

次の方法をお試しください

バックアップのステータスは、REST API または gcloud コマンドで確認できます。たとえば、インスタンスのバックアップをリストし、次にそのバックアップを ID で記述します。

gcloud sql --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

クローンの作成

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
constraints/sql.restrictAuthorizedNetworks エラーでクローンの作成に失敗する。 承認済みネットワークの構成によってブロックされています。 こちらのいずれかをお試しください。

constraints/sql.restrictAuthorizedNetworks エラーでクローンの作成に失敗する

constraints/sql.restrictAuthorizedNetworks エラーが表示され、クローンの作成に失敗します。

次のような問題が考えられます

クローン作成のオペレーションが、Authorized Networks 構成によってブロックされている。Authorized Networks は、Google Cloud Console の [接続] セクションでパブリック IP アドレスに構成されており、セキュリティに関する考慮事項により、クローン作成が許可されていません。

次の方法をお試しください

可能であれば、Cloud SQL インスタンスからすべての Authorized Networks エントリを削除します。それができない場合は、Authorized Networks エントリなしでレプリカを作成します。

接続

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
FATAL: database 'user' does not exist gcloud sql connect --user はデフォルトの `postgres` ユーザーでのみ機能します。 デフォルト ユーザーとして接続してから、ユーザーを変更します。
SSL error: invalid padding サーバー証明書エラー。 新しいサーバー証明書を作成して、ローテーションします。
接続されているユーザーを確認する必要があります。 該当なし 次の方法をお試しくださいをご覧ください。
Unauthorized to connect エラー。 多くの根本原因が考えられます。 次の方法をお試しくださいをご覧ください。
ネットワークの関連付けに失敗した。 プロジェクトで Service Networking API が有効になっていません。 プロジェクトで Service Networking API を有効にします
Remaining connection slots are reserved 最大接続数に達しました。 max_connections フラグの値を大きくします
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project サービス ネットワーキングのサービス アカウントは、servicenetworking.serviceAgent ロールにバインドされていません。 サービス ネットワーキングのサービス アカウントを servicenetworking.serviceAgent ロールにバインドします
error x509: certificate is not valid for any names, but wanted to match project-name:db-name 既知の問題: 現時点では、Cloud SQL Proxy Dialer は Go 1.15 と互換性がありません。 修正されるまで、回避策が記載されている GitHub のディスカッションをご覧ください。
一部のオペレーティング システムで証明書を解析できない。 macOS 11.0(Big Sur)の x509 ライブラリを使用しているクライアントでは、postgres インスタンスの一部の証明書を解析できない場合があります。「cancelled」などの一般的なエラーとしてクライアントに表示される場合があります。 この問題を回避する方法は、サーバー証明書をローテーションして、クライアント証明書を再作成することです。
Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection 割り振り範囲を変更または削除した後に VPC ピアリングが更新されませんでした。 VPC ピアリングの更新の詳細については、次の方法をお試しくださいをご覧ください。
Allocated IP range not found in network 割り振り範囲を変更または削除した後に VPC ピアリングが更新されませんでした。 VPC ピアリングの更新の詳細については、次の方法をお試しくださいをご覧ください。

接続が中断された

エラー メッセージ Got an error reading communication packets または Aborted connection xxx to db: DB_NAME が表示されます。

次のような問題が考えられます

  • ネットワークが不安定です。
  • TCP keep-alive コマンドに応答しません(クライアントまたはサーバーのいずれかが応答しないか、過負荷の可能性があります)。
  • データベース エンジン接続の存続期間を超過し、サーバーが接続を終了しています。

次の方法をお試しください

アプリケーションはネットワーク障害に対応し、接続プールや再試行などのベスト プラクティスに沿っている必要があります。通常、可能な場合は、接続プーラーによりこれらのエラーが検出されます。エラーが検出されない場合、アプリケーションは、再試行を行うか安全に失敗する必要があります。

接続の再試行には、次の方法をおすすめします。

  1. 指数バックオフ。再試行の間隔を指数関数的に増やします。
  2. ランダム化されたバックオフも追加します。
これらの方法を組み合わせると、スロットリングが減ります。


FATAL: データベース「user」が存在しません

gcloud sql connect --user で PostgreSQL インスタンスに接続しようとすると、エラー メッセージ FATAL: database 'user' does not exist が表示されます。

次のような問題が考えられます

gcloud sql connect --user コマンドは、デフォルト ユーザー(postgres)でのみ機能します。

次の方法をお試しください

この問題を回避するには、デフォルト ユーザーを使用して接続し、"\c" psql コマンドを使用して別のユーザーとして再接続します。


SSL エラー: 無効なパディング

SSL 経由で PostgreSQL インスタンスに接続しようとすると、エラー メッセージ SSL error: invalid padding が表示されます。

次のような問題が考えられます

サーバー CA 証明書に問題がある可能性があります。

次の方法をお試しください

新しいサーバー CA 証明書を作成し、サーバー証明書をローテーションします。


接続されているユーザーを確認する必要がある

接続しているユーザーとその接続期間を確認する必要があります。

次のような問題が考えられます

なし

次の方法をお試しください

データベースにログインし、次のコマンドを実行します。SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - state_change as last_activity_age FROM pg_stat_activity WHERE backend_type = 'client backend' ORDER BY 6 DESC LIMIT 20</code>


接続失敗

エラー メッセージ Unauthorized to connect が表示されます。

次のような問題が考えられます

承認はさまざまなレベルで行われるため、多くの原因が考えられます。

  • データベース レベルでは、データベース ユーザーが存在し、パスワードが一致する必要があります。
  • プロジェクト レベルでは、ユーザーに適切な IAM 権限がない可能性があります。
  • Cloud SQL レベルでは、根本原因はインスタンスへの接続方法によって異なります。パブリック IP を介してインスタンスに直接接続する場合、接続のソース IP がインスタンスの承認済みネットワーク内に存在している必要があります。

    デフォルトでは、RFC 1918 以外のアドレスから接続する場合を除き、プライベート IP 接続が許可されています。RFC 1918 以外のクライアント アドレスは、承認済みネットワークとして構成する必要があります。

    Cloud SQL は、デフォルトでは VPC から RFC 1918 以外のサブネット ルートを学習しません。RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワーク ピアリングを更新する必要があります。次に例を示します。

    gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    

    Cloud SQL Proxy 経由で接続する場合は、IAM 権限が適切に設定されていることを確認します。

  • ネットワーク レベルでは、Cloud SQL インスタンスでパブリック IP を使用している場合、接続のソース IP が承認済みネットワーク内に存在している必要があります。

次の方法をお試しください

  • ユーザー名とパスワードを確認します。
  • ユーザーの IAM のロールと権限を確認します。
  • パブリック IP を使用する場合は、ソースが承認済みネットワーク内に存在していることを確認します。

ネットワークの関連付けに失敗した

エラー メッセージ Error: Network association failed due to the following error が表示されます。サービス ネットワーキングのサービス アカウントをユーザープロジェクトの servicenetworking.serviceAgent ロールとして設定します。

次のような問題が考えられます

プロジェクトで Service Networking API が有効になっていません。

次の方法をお試しください

プロジェクトで Service Networking API を有効にします。Cloud SQL インスタンスにプライベート IP アドレスの割り当てを試行中で、共有 VPC を使用しているときにこのエラーが表示される場合は、ホスト プロジェクトに対して Service Networking API を有効にする必要もあります。


残りの接続スロットが予約済み

エラー メッセージ FATAL: remaining connection slots are reserved for non-replication superuser connections が表示されます。

次のような問題が考えられます

最大接続数に達しました。

次の方法をお試しください

max_connections フラグの値を編集します。


サービス ネットワーキングのサービス アカウントをユーザー プロジェクトの servicenetworking.serviceAgent ロールとして設定する

エラー メッセージ set Service Networking service account as servicenetworking.serviceAgent role on consumer project. が表示されます。

次のような問題が考えられます

サービス ネットワーキングのサービス アカウントが、servicenetworking.serviceAgent ロールにバインドされていません。

次の方法をお試しください

この問題を回避するには、次の gcloud コマンドを使用して、サービス ネットワーキングのサービス アカウントを servicenetworking.serviceAgent ロールにバインドしてください。

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=project-id
gcloud projects add-iam-policy-binding project-id --member="serviceAccount:service-project-number@service-networking.iam.gserviceaccount.com" --role="roles/servicenetworking.serviceAgent"

エラー x509: いずれの名前に対しても証明書が無効です

エラー メッセージ error x509: certificate is not valid for any names, but wanted to match project-name:db-name が表示されます。

次のような問題が考えられます...

既知の問題: 現時点では、Cloud SQL Proxy Dialer は Go 1.15 と互換性がありません。

次の方法をお試しください

バグが修正されるまで、回避策が記載されている GitHub のディスカッションをご覧ください。


一部のオペレーティング システムで証明書を解析できない

macOS 11.0(Big Sur)の x509 ライブラリを使用すると、postgres インスタンスの証明書の解析に失敗する場合があります。「cancelled」などの一般的なエラーとして表示される場合があります。

次の方法をお試しください

バグは修正されました。新しいインスタンスでこの問題が発生することはありません。古いインスタンスでこの問題が発生した場合は、サーバー証明書をローテーションして、クライアント証明書を再作成します。


CreateConnection で割り振り範囲を変更することはできません。UpdateConnection を使用してください

エラー メッセージ Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection または The operation "operations/1234" resulted in a failure "Allocated IP range 'xyz' not found in network が表示されます。

次のような問題が考えられます...

プライベート サービス接続が変更されました。たとえば、範囲を予約してから削除すると、プライベート接続も削除されます。この最初のエラーは、最初にプライベート接続を再作成せずに、別の予約範囲を使用して接続しようとすると発生します。割り当て範囲が変更されても、vpc-peerings が更新されなかった場合、2 番目のエラーが表示されます。

次の方法をお試しください

プライベート接続を再作成または更新する必要がある。次のコマンドを使用します。--force 引数を必ず使用してください。

gcloud services vpc-peerings update --network=VPC_NETWORK --ranges=ALLOCATED_RANGES --service=servicenetworking.googleapis.com --force

インスタンスの作成

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
Internal error サービス ネットワーキングのサービス アカウントがありません。 Service Networking API を無効にしてから再度有効にします
Terraform インスタンスの作成に失敗した。 Terraform 構成エラー。 Terraform 構成ファイルを調べて修復します。
Terraform スクリプトの HTTP Error 409 別のオペレーションがすでに進行中です。 各オペレーションが完了するまで待機するように Terraform スクリプトを修正します。
Unknown error 最近削除したインスタンスと同じ名前のインスタンスを作成しようとしています。または、使用されている新しいプライベート IP 範囲で同時に複数のインスタンスを作成しようとしています。 インスタンスに別の名前を使用するか、インスタンスが削除されてから 1 週間経過するまで待ちます。異なる名前を使用して、連続的に失敗したインスタンスを再作成します
Failed to create subnetwork IP 範囲にはこれ以上使用可能なアドレスはありません。 新しい範囲を割り振ってください

内部エラー

エラー メッセージ {"ResourceType":"sqladmin.v1beta4.instance", "ResourceErrorCode":"INTERNAL_ERROR","ResourceErrorMessage":null} が表示されます。

次のような問題が考えられます

サービス プロジェクトに、この機能に必要なサービス ネットワーキング サービス アカウントがない可能性があります。

次の方法をお試しください

サービスの権限を修復するには、Service Networking API を無効にして 5 分待ち、再度有効にします。


Terraform インスタンスの作成に失敗した

Terraform インスタンスの作成に失敗しました。

次のような問題が考えられます

これは通常、Terraform スクリプト自体の問題です。

次の方法をお試しください

Terraform 構成ファイルを調べて修復します。


Terraform スクリプトの 409 エラー

Terraform スクリプトにエラー メッセージ HTTP Error 409 が表示されます。

次のような問題が考えられます

Operation failed because another operation was already in progress

次の方法をお試しください

スクリプトを修正して、各インスタンスのオペレーションが完了するまで実行を停止します。スクリプトをポーリングして、前のオペレーション ID の 200 が返されるまで待ってから、次のステップに進みます。


不明なエラー

インスタンスを作成しようとすると、Cloud SQL creation failed, error UNKNOWN のようなエラー メッセージが表示されます。

次のような問題が考えられます

最近削除したインスタンスの名前を再利用しようとしている可能性があります。インスタンス名を削除した後、1 週間は再利用できません。または、最初のインスタンスのみが作成され、他のインスタンスが Unknown error で失敗したときに、新しいプライベート IP 範囲を使用して複数のインスタンスを同時に作成しようとしています。

次の方法をお試しください

インスタンスに別の名前を使用するか、その名前を使用して新しいインスタンスを作成します。複数のインスタンスを同時に作成するのではなく、連続して作成します。


サブネットワークを作成できない

Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider.」というエラー メッセージが表示されます。

次のような問題が考えられます

割り振り済みの IP 範囲にはこれ以上使用可能なアドレスがありません。

プライベート サービス接続を使用する共有 VPC ネットワークに対して、プライベート IP を持つ Cloud SQL インスタンスを作成する際にこのエラーが発生した場合、次の 5 つのシナリオが考えられます。

  • プライベート サービス接続に割り振られた IP 範囲のサイズが /24 より小さい。
  • プライベート サービス接続に割り振られた IP 範囲のサイズが、Cloud SQL インスタンスの数に対して小さすぎる。
  • VPC ホスト プロジェクト内で同じプライベート サービス接続に MySQL インスタンスまたは SQL Server インスタンスと PostgreSQL インスタンスの両方を作成しようとしている。MySQL と SQL Server は同じサービス接続を共有できます。PostgreSQL には独自のサービス接続が必要です。
  • 異なるリージョンにおいて同じプライベート サービス接続でインスタンスを作成しようとしている。これはサポート対象外です。

次の方法をお試しください

上記の各シナリオにおいて、プライベート サービス接続に既存の IP 範囲を拡張するか、追加の IP 範囲を割り振るかを選択できます。

新しい範囲を割り振る場合は、既存の割り振りと重複する割り振りを作成しないように注意してください。

新しい IP 範囲を作成した後、次のコマンドを使用して VPC ピアリングを更新します。

gcloud services vpc-peerings update --service=servicenetworking.googleapis.com
--ranges=[OLD_RESERVED_RANGE_NAME],[NEW_RESERVED_RANGE_NAME] --network=[VPC_NETWORK]
--project=[PROJECT_ID] --force

既存の割り振りを拡張する場合は、割り振り範囲を増やすのみとし、減らさないように注意してください。たとえば、元の割り振りが 10.0.10.0/24 だった場合、新しい割り振りを少なくとも 10.0.10.0/23 に設定します。

一般的に、/24 の割り振りから開始する場合は、各条件(追加のインスタンス タイプのグループ、追加のリージョン)で /mask を 1 つずつ減らすのが基本的なルールです。たとえば、同じ割り振りで両方のインスタンス タイプのグループを作成しようとしている場合も、/24 から /23 にするだけで十分です。

既存の IP 範囲を拡張した後、次のコマンドを使用して VPC ピアリングを更新します。

gcloud services vpc-peerings update --service=servicenetworking.googleapis.com
--ranges=[RESERVED_RANGE_NAME] --network=[VPC_NETWORK] --project=[PROJECT_ID]

フラグ

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
タイムゾーンを設定するフラグがない。 タイムゾーン フラグがサポートされていない。 いくつかの回避策があります。

タイムゾーンを設定するフラグがない

Cloud SQL がサポートする PostgreSQL と SQL Server では、ユーザーの希望に応じてタイムゾーンを調整するためのタイムゾーン フラグを使用できません。

次のような問題が考えられます

タイムゾーン フラグがサポートされていない。

次の方法をお試しください

セッションごとにタイムゾーンを設定できますが、ログアウトすると期限切れになります。データベースに接続し、データベースのタイムゾーンをユーザーごとまたはデータベースごとに希望のタイムゾーンに設定することをおすすめします。

ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

これらの設定は、セッションを終了しても残り、.conf 構成を再現します。

高可用性

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
手動フェイルオーバーの指標が見つからない。 自動フェイルオーバーのみが指標に含まれます なし
CPU と RAM の使用率がほぼ 100% インスタンスのマシンサイズが負荷に対して小さすぎます。 インスタンスのマシンサイズをアップグレードします

手動フェイルオーバーの指標が見つからない

手動フェイルオーバーを実行しましたが、自動フェイルオーバーの指標に対応するエントリが Metrics Explorer で見つかりません。

次のような問題が考えられます

自動フェイルオーバーのみが指標に含まれます。手動で開始されたフェイルオーバーには指標が含まれません。

次の方法をお試しください

なし


CPU と RAM の使用率がほぼ 100%

Cloud SQL インスタンス リソース(CPU と RAM)の使用率が 100% に近いため、高可用性インスタンスが停止します。

次のような問題が考えられます

インスタンスのマシンサイズが負荷に対して小さすぎます。

次の方法をお試しください

インスタンスを編集してより大きなマシンサイズにアップグレードし、CPU とメモリのサイズを大きくします。

インポートとエクスポート

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
オペレーションのステータスを確認できない。 ユーザー インターフェースには成功または失敗のみが表示されます。 詳細については、これらのデータベース コマンドをご覧ください。
エクスポート中の 408 Error (Timeout) データベースのサイズとエクスポート コンテンツによっては、SQL のエクスポートに時間がかかることがあります。 複数の CSV エクスポートを使用して各オペレーションのサイズを減らします
CSV のエクスポートは機能したが、SQL エクスポートに失敗した。 SQL のエクスポートでは、Cloud SQL との互換性の問題が発生する可能性が高くなります。 CSV のエクスポートを使用して必要なものだけをエクスポートします
エクスポートに時間がかかりすぎる。 Cloud SQL では同時実行オペレーションの同期がサポートされません。 エクスポートのオフロードを使用します。詳細については、こちらをご覧ください。
インポートに時間がかかりすぎる。 アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。 未使用の接続を閉じるか、インポート オペレーションを開始する前に Cloud SQL インスタンスを再起動してください。
拡張機能の作成のエラー。 ダンプファイルには、サポートされていない拡張機能への参照が含まれています。 ダンプファイルを編集して参照を削除します
pg_dumpall の使用中にエラーが発生した。 このツールにはスーパーユーザーのロールが必要です。 スーパーユーザーのロールはサポートされていません
エクスポート オペレーションが、エクスポート完了前にタイムアウトする。 クエリで最初の 7 分以内にデータを生成する必要があります。 pg_dump ツールを使用して手動でエクスポートしてみてください
インポートに失敗した。 エクスポートされたファイルに、まだ存在しないデータベース ユーザーが含まれている可能性があります。 インポートを再試行する前に、失敗したデータベースをクリーンアップします。インポートを行う前に、データベース ユーザーを作成します。
エクスポート オペレーション中に接続が切断した。 クエリで最初の 7 分以内にデータを生成する必要があります。 クエリを手動でテストします。詳細については、こちらをご覧ください。
エクスポート中に不明なエラーが発生した。 帯域幅の問題である可能性があります。 インスタンスと Cloud Storage バケットの両方が同じリージョンに存在することを確認します
エクスポートを自動化する場合。 Cloud SQL には、エクスポートを自動化する方法がありません。 この機能を実行する独自のパイプラインを構築します。詳細については、こちらをご覧ください。
ERROR_RDBMS: system error occurred Cloud Storage の権限またはテーブルが存在しません。 権限を確認するか、テーブルが存在することを確認します

オペレーションのステータスを確認できない

進行中のオペレーションのステータスが表示されません。

次のような問題が考えられます

Google Cloud Console では、完了時に成功または失敗のみが表示され、警告は返されません。

次の方法をお試しください

データベースに接続し、SHOW WARNINGS を実行します。


エクスポート中の 408 エラー(タイムアウト)

Cloud SQL でエクスポート ジョブを実行しているときに、エラー メッセージ 408 Error (Timeout) が表示されます。

次のような問題が考えられます

CSV 形式と SQL 形式ではエクスポート方法が異なります。SQL 形式ではデータベース全体がエクスポートされるため、完了までに時間がかかります。CSV 形式ではエクスポートに含めるデータベースの要素を定義できます。

次の方法をお試しください

CSV 形式を使用して複数の小規模なエクスポート ジョブを実行し、各オペレーションのサイズと長さを減らします。


CSV のエクスポートは機能したが、SQL エクスポートに失敗した

CSV のエクスポートは機能したが、SQL エクスポートに失敗した。

次のような問題が考えられます

CSV 形式と SQL 形式ではエクスポート方法が異なります。SQL 形式ではデータベース全体がエクスポートされるため、完了までに時間がかかります。CSV 形式ではエクスポートに含めるデータベースの要素を定義できます。

次の方法をお試しください

CSV エクスポートを使用して必要なものだけをエクスポートします。


エクスポートに時間がかかりすぎる

エクスポートに時間がかかりすぎるため、他のオペレーションをブロックします。

次のような問題が考えられます

Cloud SQL では同時実行オペレーションの同期がサポートされません。

次の方法をお試しください

サイズの小さい多数のデータセットを一度にエクスポートしてみてください。


インポートに時間がかかりすぎる

インポートに時間がかかりすぎるため、他のオペレーションをブロックしています。

次のような問題が考えられます

アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。CPU とメモリが接続のために消費されると、使用可能なリソースが制限されます。

次の方法をお試しください

未使用のオペレーションを終了します。使用可能なリソースが十分にあるかどうか、CPU とメモリ使用量を確認します。インポート オペレーションに使用するリソースを最大限確保するために、オペレーションを開始する前にインスタンスを再起動することをおすすめします。再起動:

  • すべての接続を終了します。
  • リソースを消費している可能性のあるタスクを終了します。


拡張機能の作成のエラー

エラー メッセージ SET SET SET SET SET SET CREATE EXTENSION ERROR: must be owner of extension plpgsql が表示されます。

次のような問題が考えられます

PostgreSQL のダンプをインポートすると、同様のエラー メッセージが表示される場合、ダンプファイルには plpgsql への参照が含まれています。

次の方法をお試しください

ダンプファイルを編集し、plpgsql に関連するすべての行をコメントアウトします。


pg_dumpall の使用中のエラー

外部の pg_dumpall コマンドライン ツールを使用しようとすると、エラーが発生します。

次のような問題が考えられます

このツールにはスーパーユーザーのロールが必要です。

次の方法をお試しください

Cloud SQL はマネージド サービスであり、ユーザーにスーパーユーザーのロールや権限を付与することはありません。


ピアによって接続がリセットされた

エクスポート オペレーションが、エクスポート完了前にタイムアウトします。エラー メッセージ Could not receive data from client: Connection reset by peer. が表示されます。

次のような問題が考えられます

Cloud Storage が特定の期間内にデータを受信しない場合、接続がリセットされる。

次の方法をお試しください

pg_dump ツールを使用して手動でエクスポートします。


インポートに失敗した

エクスポートされた SQL ダンプファイルで参照されているユーザーが存在しない場合、インポートは失敗します。

次のような問題が考えられます

SQL ダンプをインポートする前に、オブジェクトを所有しているか、またはダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが存在する必要があります。 そうでない場合、復元で、元の所有権や権限でのオブジェクトの再作成に失敗します。

次の方法をお試しください

インポートを再試行する前に、失敗したデータベースをクリーンアップします。SQL ダンプをインポートする前に、データベース ユーザーを作成します。


エクスポート オペレーション中に接続が切断された

エクスポート オペレーション中に接続が切断しました。

次のような問題が考えられます

エクスポートが開始されてから最初の 7 分以内に、エクスポートで実行されているクエリでデータが生成されないため、Cloud Storage への接続がタイムアウトする可能性があります。

次の方法をお試しください

次のコマンドを使用して任意のクライアントから接続し、クエリの出力を標準出力に送信して、クエリを手動でテストします。

COPY (INSERT_YOUR_QUERY_HERE) TO STDOUT WITH ( FORMAT csv, DELIMITER ',', ENCODING 'UTF8', QUOTE '"', ESCAPE '"' )

これは、エクスポートが開始されるとすぐにクライアントからデータの送信が開始されるためです。データが送信されていない接続を維持すると、最終的に接続が切断されてエクスポートが失敗し、操作が不確定な状態になります。また、gcloud からのエラー メッセージは次のように表示されます。

operation is taking longer than expected


エクスポート中に不明なエラーが発生した

データベースを Cloud Storage バケットにエクスポートしようとすると、エラー メッセージ Unknown error が表示されます。

次のような問題が考えられます

帯域幅の問題が原因で転送が失敗する可能性があります。

次の方法をお試しください

Cloud SQL インスタンスが Cloud Storage バケットとは異なるリージョンに存在している可能性があります。ある大陸から別の大陸へのデータの読み取りと書き込みではネットワークの使用量が多く、このような断続的な問題を引き起こす可能性があります。インスタンスとバケットのリージョンを確認します。


エクスポートを自動化する

エクスポートを自動化する場合。

次のような問題が考えられます

Cloud SQL には、エクスポートを自動化する方法がありません。

次の方法をお試しください

Google Cloud プロダクト(Cloud Scheduler、Pub/Sub、Cloud Functions)を使用して、独自の自動エクスポート システムを構築できます。


ERROR_RDBMS システムエラーが発生した

エラー メッセージ [ERROR_RDBMS] system error occurred が表示されます。

次のような問題が考えられます

  • ユーザーが必要なすべての Cloud Storage 権限を持っていない可能性があります。
  • データベース テーブルが存在しない可能性があります。

次の方法をお試しください

  1. バケットに対して少なくとも WRITER 権限があり、エクスポート ファイルに対して READER 権限があることを確認してください。Cloud Storage のアクセス制御の構成について詳しくは、アクセス制御リストの作成と管理をご覧ください。
  2. テーブルが存在していることを確認します。存在している場合は、バケットに対して正しい権限があることを確認します。


ロギング

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
ロギングで大量の CPU とメモリを使用している。 ロギングを調整する必要があります。 ロギング リソースの使用量を調整してみてください。
監査ログが見つからない。 ユーザー認証。 ユーザーロールと権限を確認します
ログにオペレーション情報が見つからない。 監査ログは有効になっていません。 監査ロギングを有効にします
ログファイルが読みにくい。 ログを json またはテキストで表示しています。 gcloud logging コマンドを使用します
PostgreSQL ログでクエリログが見つからない。 pgaudit フラグを有効にする必要があります。 gcloud sql コマンドを使用します

ロギングで大量の CPU とメモリを使用している

ロギングで大量の CPU とメモリを使用しています。

次のような問題が考えられます

ロギングの使用量を調整する必要があります。

次の方法をお試しください

log_statement フラグを「なし」、logging_collector フラグを「オフ」に設定できます。ロギングがまだ行われている場合は、他のログ関連のフラグを調整できます。インスタンスを編集して、これらのフラグを変更できます。


監査ロギング

Cloud SQL の監査ロギングを有効にしたが、Cloud Logging で監査ログが見つからない

次のような問題が考えられます

オペレーションが、ユーザー作成データを作成、変更、または読み取る認証済みのユーザー ドリブン API 呼び出しの場合、またはリソースの構成ファイルまたはメタデータにアクセスした場合にのみ、データアクセス ログに書き込まれます。

次の方法をお試しください

オペレーションを実行するユーザーのロールと権限を確認します。


オペレーションの情報がログに見つからない

オペレーションの詳細を確認する場合。たとえば、ユーザーが削除されたものの、誰が行ったかを確認できない場合。ログには開始されたオペレーションが表示されますが、それ以上の情報は提供されません。

次のような問題が考えられます

このような詳細な個人情報(PII)を記録するには、監査ロギングを有効にする必要があります。

次の方法をお試しください

プロジェクトで監査ロギングを有効にします。


ログファイルが読みにくい

Logs Explorer でログを読み取れません。

次のような問題が考えられます

ログが JSON 形式またはテキスト形式でローカルにダウンロードされています。

次の方法をお試しください。

ログは、Linux 後処理コマンドとともに gcloud logging read コマンドを使用してダウンロードできます。

JSON でダウンロードするには:

gcloud logging read "resource.type=cloudsql_database AND logName=projects/PROJECT-ID/logs/cloudsql.googleapis.com%2FLOGFILE-NAME" --format json --project=PROJECT-ID--freshness="1d" > downloaded-log.json

テキストでダウンロードするには:

gcloud logging read "resource.type=cloudsql_database AND logName=projects/PROJECT-ID/logs/cloudsql.googleapis.com%2FLOGFILE-NAME" --format json --project=PROJECT-ID--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) | .textPayload' > downloaded-log.txt


クエリログが見つからない

PostgreSQL をサポートする Cloud Logging でクエリログが見つかりません。

次のような問題が考えられます

pgaudit フラグを有効にする必要があります。

次の方法をお試しください

  1. ターミナルからデータベースに接続します。

    gcloud sql connect $INSTANCE_NAME
    

  2. データベース内で次のコマンドを実行して、拡張機能を作成します。

    CREATE EXTENSION pgaudit;
    

  3. データベースを終了し、ターミナルから次のコマンドを実行します。

    gcloud sql instances patch $INSTANCE_NAME --database-flags cloudsql.enable_pgaudit=on,pgaudit.log=all
    

  4. 最後に、Cloud SQL インスタンスを再起動します。

インスタンスの管理

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
実行中のクエリを調べる必要がある。 該当なし こちらのデータベース クエリをお試しください。
特定のフィールドで使用されているユニットを確認する必要がある。 該当なし こちらのデータベース クエリをお試しください。
データベース設定の現在の値を確認する必要がある。 該当なし こちらのデータベース クエリをお試しください。
ブロックされたバックグラウンド プロセスを停止する必要がある。 ユーザーには pg_signal_backend のロールが必要です。 ロールを付与し、これらのコマンドを発行します。
一時ストレージにより、自動ストレージが増加した。 自動ストレージが有効になっています。 再起動すると一時ファイルは削除されますが、保存容量は減りません。インスタンスのサイズをリセットできるのはカスタマー サポートのみです。詳細については、こちらをご覧ください。
データが自動的に削除される。 どこかでこれを行うスクリプトが実行されています。 スクリプトの検索を試してください。
インスタンスを削除できない。 複数の根本原因が存在している可能性があります。 複数のソリューションが存在している可能性があります。
一時的なデータサイズが大きいためにインスタンスが停止する。 一度に作成された一時テーブルが多すぎます。 インスタンスを再起動し、この緩和策オプションをお試しください。
アップグレード中の致命的なエラー。 さまざまな原因が考えられます。 ログに詳細情報が表示される場合があります。強制的に再起動するには、カスタマー サポートにお問い合わせください。
ディスク容量が不足した後、再起動時にインスタンスが停止する。 自動ストレージ増加機能が有効になっていません。 ストレージの自動増量を有効にします
オンプレミスのプライマリ インスタンスが停止する。 該当なし Cloud SQL のカスタマー サポートは、Cloud SQL に含まれていないインスタンスをサポートできません
再起動時のシャットダウンが遅い。 60 秒後に終了してない未処理の接続によって、クリーンでないシャットダウンが発生する可能性があります。 接続時間が 60 秒未満の場合のみ
Access denied for user ユーザー認証、または期限切れの SSL / TLS 証明書。 ユーザーと証明書のステータスを確認します。
ユーザーを削除できない。 ユーザーがデータベース内のオブジェクトを所有している可能性があります。 オブジェクトの削除または再割り当てが必要となる可能性があります。
共有 VPC の既存のインスタンスにプライベート IP アドレスを割り当てることができない。 インスタンスのアドレスは、作成時にプロジェクトに関連付けられます。 新しい Cloud SQL インスタンスを作成して、既存のインスタンスを置き換えます。
特定のクエリの実行が遅い。 データベースに固有の問題またはネットワーク レイテンシ。 おすすめの方法をご覧ください。
メモリ不足が示されているが、モニタリング グラフに表示されない。 一部の RAM が内部オーバーヘッド プロセスで使用されている可能性があります。 インスタンスに、ワークロードの十分なオーバーヘッドがあることを確認してください。
削除したインスタンスを復元する。 インスタンスを削除すると、バックアップを含め、そのインスタンスのすべてのデータが完全に失われます。 Cloud Storage にエクスポートして、データ損失を防ぎます。


実行中のクエリを調べる必要がある

PostgreSQL で実行中のクエリを調べる必要があります。

次のような問題が考えられます

なし

次の方法をお試しください

データベースに接続し、次のクエリを実行します。SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;


フィールドで使用されているユニットを確認する必要がある

特定のフィールドで使用されているユニットを確認する必要があります。

次のような問題が考えられます

なし

次の方法をお試しください

データベースに接続し、次のクエリを実行します(自分の FIELD_NAME を使用)。SELECT name, setting, unit FROM pg_settings WHERE name = '[FIELD_NAME]'


設定の現在の値を確認する必要がある

特定の設定の現在の値を確認する必要があります。

次のような問題が考えられます

なし

次の方法をお試しください

データベースに接続してこのクエリを実行する(自分の SETTING_NAME を使用): SHOW SETTING_NAME; または SHOW ALL; ですべての設定を表示します。

ブロックされたバックグラウンド プロセスを停止する必要がある

たとえば、ブロックされたまたは停滞しているバックグラウンド プロセス(自動バキュームなど)を停止する必要があります。

次のような問題が考えられます

ユーザーに適切なロールがありません。pg_signal_backend のロールが必要です。

次の方法をお試しください

  1. データベースに接続し、次のコマンドを実行します。
      GRANT pg_signal_backend TO USERNAME;
      
  2. ブロックされたプロセスまたは停滞しているプロセスのプロセス ID を確認します。
      SELECT pid, usename, state, query FROM pg_stat_activity;
      
  3. 次のコマンドを使用して、実行中のプロセスまたはアイドル プロセスを停止します。
      SELECT pg_cancel_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      
      SELECT pg_terminate_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      

一時ストレージにより、自動ストレージが増加した

一時テーブルのストレージ使用量が増えたため、自動ストレージが増えました。

次のような問題が考えられます

自動ストレージが有効になっています。

次の方法をお試しください

一時テーブルを削除するために再起動しても、自動的に増加するストレージ サイズは減少しません。


データが自動的に削除される

データが一定の間隔で自動的に削除されます。

次のような問題が考えられます

ほとんどの場合、スクリプトが環境内のどこかで実行されています。

次の方法をお試しください

削除時刻の前後のログで、ダッシュボードや別の自動プロセスから不正なスクリプトが実行されていないかどうかを確認します。


インスタンスを削除できない

エラー メッセージ ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request が表示されるか、インスタンスのステータスが INSTANCE_RISKY_FLAG_CONFIG である可能性があります。

次のような問題が考えられます

  1. 別のオペレーションが進行中です。
  2. INSTANCE_RISKY_FLAG_CONFIG 警告は、少なくとも 1 つの beta フラグが使用されるたびにトリガーされます。

次の方法をお試しください

  1. Cloud SQL オペレーションは同時には実行されません。他のオペレーションが完了するのをお待ちください。
  2. 危険なフラグ設定を削除して、インスタンスを再起動します。

一時的なデータサイズが大きいためにシステムが停止する

一時的なデータサイズが大きいためにシステムが停止します。

次のような問題が考えられます

クエリと負荷に応じて、一度に多数の一時テーブルを作成できます。

次の方法をお試しください

残念ながら、サービスの再起動以外の方法で ibtmp1 ファイルを圧縮することはできません。

緩和策の 1 つは、ROW_FORMAT=COMPRESSED を使用して一時テーブルを作成し、一時ファイル ディレクトリ内の file-per-table テーブルスペースに保存することです。ただし、各一時テーブルの file-per-table テーブルスペースの作成と削除によって、パフォーマンスが低下します。


アップグレード中の致命的なエラー

インスタンスのリソースをアップグレードすると、エラー メッセージ ERROR_INTERNAL_FATAL が表示されます。

次のような問題が考えられます

さまざまな原因が考えられます。

次の方法をお試しください

ログに詳細が表示される場合がありますが、インスタンスを強制的に再作成するにはカスタマー サポートが必要になる場合があります。


ディスク容量が不足した後、再起動時にインスタンスが停止する

ディスク容量が不足した後、再起動時にインスタンスが停止します。

次のような問題が考えられます

自動ストレージ増加機能が有効になっていません。

次の方法をお試しください

インスタンスのストレージが不足し、ストレージの自動増加機能が有効になっていない場合、インスタンスはオフラインになります。この問題を回避するには、インスタンスを編集して、ストレージの自動増加を有効にします。


オンプレミスのプライマリ インスタンスが停止する

オンプレミスのプライマリ インスタンスが停止した場合に、Cloud SQL のカスタマー サポートが役立つかどうかを確認する必要があります。

次のような問題が考えられます

インスタンスが Cloud SQL にありません。

次の方法をお試しください

Cloud SQL のカスタマー サポートは、Cloud SQL に含まれていないインスタンスをサポートできません。


再起動時のシャットダウンが遅い

再起動時のシャットダウンに時間がかかります。

次のような問題が考えられます

インスタンスをシャットダウンしたときに、60 秒以内に終了しない未処理の接続があると、クリーンでないシャットダウンが発生します。

次の方法をお試しください

接続が 60 秒未満の場合は、データベース コマンドのプロンプトからの接続を含めて、ほとんどのクリーンでないシャットダウンを回避できます。これらの接続を数時間または数日間維持すると、クリーンでないシャットダウンが発生する場合があります。


ユーザーのアクセスが拒否された

エラー メッセージ Access denied for user 'XXX'@'XXX' (using password: XXX) が表示されます。

次のような問題が考えられます

次のようないくつかの原因が考えられます。

  • ユーザー名(またはパスワード)が正しくない。
  • ユーザーが @XXX 以外から接続している。
  • ユーザーが、接続しようとしているデータベースに対する適切な権限を持っていない。

次の方法をお試しください

  • ユーザー名と対応するパスワードを確認します
  • 接続元をチェックして、ユーザーがアクセス権を持っている場所と一致しているかどうかを確認します。
  • データベース内のユーザーの権限をチェックします。

ユーザーを削除できない

データベース ユーザーを削除することはできません。

次のような問題が考えられます

データベースに依存しているオブジェクトがあります。これらのオブジェクトを削除するか、別のユーザーに再度割り当てる必要があります。

次の方法をお試しください

ユーザーに依存しているオブジェクトを特定し、それらのオブジェクトをドロップするか、別のユーザーに再度割り当てます。ユーザーが所有するオブジェクトを見つける方法については、Stack Exchange に関するスレッドをご覧ください。


共有 VPC の既存のインスタンスにプライベート IP アドレスを割り当てることができない

共有 VPC の既存のインスタンスにプライベート IP アドレスを割り当てることができません。

次のような問題が考えられます

その理由は、Cloud SQL インスタンスが作成されると自動でテナント プロジェクトに接続され、同じプロジェクト内のすべての Cloud SQL インスタンスも接続されるためです。ただし、作成されたインスタンスが共有 VPC でプライベート IP を使用している場合は、共有 VPC ホスト プロジェクトに関連付けられたテナント プロジェクトに接続されます。

次の方法をお試しください

新しい Cloud SQL インスタンスを作成して、既存のインスタンスを置き換えることが可能です。


特定のクエリの実行が遅い

CPU 使用率が常に高くなっています。

次のような問題が考えられます

クエリは多くの理由で遅くなることがあります。主に特定のデータベース側による原因です。Cloud SQL がネットワーク レイテンシに関係する理由の 1 つは、ソース(ライターまたはリーダー)リソースと宛先(Cloud SQL)リソースが異なるリージョンに存在していることです。

次の方法をお試しください

特に、一般的なパフォーマンスのヒントをご覧ください。

データベースの挿入、更新、削除が遅い場合は、次のことを考慮します。

  • 書き込みとデータベースの場所を確認します。データの送信距離が長いと、レイテンシが発生します。
  • 読み取りとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスより読み取りパフォーマンスに大きく影響します。
レイテンシを低減するために、ソースリソースと宛先リソースの両方を同じリージョンに配置することをおすすめします。


メモリ不足が示されているが、モニタリング グラフに表示されない

インスタンスが失敗し、Out of memory が報告されていますが、Console または Cloud Monitoring のグラフにはメモリがまだ残っているように表示されます。

次のような問題が考えられます

ワークロード以外にも、アクティブな接続の数や内部オーバーヘッド プロセスなど、メモリ使用量に影響を与える可能性のある要因があります。こうしたことが常にモニタリング グラフに反映されるとは限りません。

次の方法をお試しください

インスタンスに、ワークロードと追加のオーバーヘッドを考慮するのに十分なオーバーヘッドがあることを確認してください。


削除したインスタンスを復元する

誤って削除してしまった場合でも、インスタンスの削除は取り消すことができません。

次のような問題が考えられます

インスタンスが削除されると、そのインスタンスのすべてのデータ(バックアップを含む)が完全に失われます。

次の方法をお試しください

データを保持するには、インスタンスを削除する前に Cloud Storage にデータをエクスポートします。

Cloud SQL 管理者のロールには、インスタンスを削除する権限が含まれています。誤って削除されないように、このロールは必要な場合にのみ付与してください。

レプリケーション

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
リードレプリカの作成時にレプリケーションが開始されなかった。 多くの根本原因が考えられます。 ログで詳細を確認します
リードレプリカを作成できない - invalidFlagValue エラー 明示的に指定されたフラグかデフォルトのフラグのいずれかが無効です。 フラグの値とログを調べて詳細を確認します
リードレプリカを作成できない - 不明なエラー。 多くの根本原因が考えられます。 ログで詳細を確認します
ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。 プライマリ インスタンスをより大きなディスクサイズにアップグレードします
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは、頻繁にリクエストされる読み取りオペレーションをキャッシュに保存できます。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。
レプリケーションが停止しました。 保存容量の上限に達しましたが、保存容量の自動増加が有効になっていません。 ストレージの自動増量を有効にします
レプリケーション ラグが常に大きい。 多くの根本原因が考えられます。 こちらをご確認ください。

リードレプリカの作成時にレプリケーションが開始されなかった

リードレプリカの作成時にレプリケーションが開始されませんでした。

次のような問題が考えられます

ログファイルに、より具体的なエラーが表示される可能性があります。

次の方法をお試しください

Cloud Logging のログを調べて、実際のエラーを確認します。


リードレプリカを作成できない - invalidFlagValue エラー

リードレプリカを作成できません - invalidFlagValue

次のような問題が考えられます

リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

次の方法をお試しください

まず、max_connections フラグの値がプライマリの値以上であることを確認します。

max_connections フラグが適切に設定されている場合、Cloud Logging のログを調べて、実際のエラーを確認します。


リードレプリカを作成できない - 不明なエラー

リードレプリカを作成できません - unknown error

次のような問題が考えられます

ログファイルに、より具体的なエラーが表示される可能性があります。

次の方法をお試しください

Cloud Logging のログを調べて、実際のエラーを確認します。

エラーが set Service Networking service account as servicenetworking.serviceAgent role on consumer project の場合は、Service Networking API を無効にしてから再度有効にします。これにより、プロセスの続行に必要なサービス アカウントが作成されます。


ディスクに空きがない

error: disk is full

次のようなことが考えられます

レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。

次の方法をお試しください

プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。


レプリカ インスタンスのメモリ使用量が多すぎる

レプリカ インスタンスのメモリ使用量が多すぎます。

次のような問題が考えられます

レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュするため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

次の方法をお試しください

レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。


レプリケーションが停止した

レプリケーションが停止しました。

次のような問題が考えられます

保存容量の上限(>automatic storage increase is disabled)に達しました。

次の方法をお試しください

インスタンスを編集して automatic storage increase を有効にします。


レプリケーション ラグが常に大きい

レプリケーション ラグが常に大きい。

次のような問題が考えられます

書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。

  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

次の方法をお試しください

考えられるソリューションは次のとおりです。

  • インスタンスを編集してレプリカのサイズを増やす。
  • データベースの負荷を軽減します。
  • テーブルをインデックスに登録します。
  • 遅いクエリを特定して修正します。
  • レプリカを再作成する。