次のいずれかのページで、質問や問題がすでに解決されていないかを確認してください。
このページには次のトピックが含まれています。
バックアップと復元
| 問題 | トラブルシューティング |
|---|---|
| 現在のオペレーションのステータスを確認できない。 | Google Cloud Console では、オペレーションの完了時に成功または失敗のみが表示されます。警告やその他の情報を表示するように設計されていません。 特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、 |
| オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 | オペレーションを開始したユーザーはユーザー インターフェースに表示されません。 ユーザーを特定するには、ログを表示してテキストでフィルタします。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。
|
| インスタンスを削除すると、その後インスタンスのバックアップは作成できません。 | インスタンスの完全削除後にデータを復元することはできません。ただし、インスタンスが復元されると、バックアップも復元されます。削除したインスタンスの復元について詳しくは、復元バックアップをご覧ください。 エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。 |
| 自動バックアップが長時間停止していて、キャンセルできない。 | データベースのサイズによっては、バックアップに時間がかかる可能性があります。 オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの |
| SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 | SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。 SQL ダンプを復元する前に、データベース ユーザーを作成します。 |
| 自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 | 保持する自動バックアップの数を構成できます（1～365 件の範囲）。自動バックアップは、構成された保持値に基づいて定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。 バックアップを無期限に保持する場合は、オンデマンド バックアップを作成します。オンデマンド バックアップは、自動バックアップと同じ方法では削除されません。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、所属するインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。 |
| 自動バックアップが失敗したときにメール通知を受信できない。 | バックアップの失敗は通知されません。 自動バックアップが失敗すると、Cloud SQL インスタンスの バックアップのステータスは、REST API または gcloud sql backups list \ --project=PROJECT_ID \ --instance=INSTANCE_ID
gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
|
| インスタンスがエラー状態とバックアップ復元状態の間でループしているため、インスタンスが繰り返し失敗する。復元後にデータベースに接続して使用しようとすると失敗する。 |
次の方法をお試しください。
|
| バックアップ / 復元オペレーションを実行したときにデータの欠落が見つかることがあります。 | テーブルがログに記録されずに作成されました。次に例を示します。
これらのテーブルはバックアップからの復元には含まれません。
解決策としては、バックアップを使用してテーブルを復元する場合に、ログに記録されていないテーブルを使用しないことです。すでにログに記録されていないテーブルがあるデータベースから復元する場合は、データベースをファイルにダンプし、これらのテーブルのダンプ済みファイルを |
インポートとエクスポートをキャンセルする
| 問題 | トラブルシューティング |
|---|---|
エラー メッセージ: You can't cancel operation [operation-ID] because
this operation isn't in progress. |
完了した、失敗した、またはキャンセルされたインポートまたはエクスポートのオペレーションをキャンセルしようとしています。実行中のオペレーションはキャンセルできます。 |
エラー メッセージ: You can't cancel operation [operation-ID] because
Cloud SQL doesn't support the cancellation of an [operation-type]
operation. |
Cloud SQL には、 |
エラー メッセージ: The [operation-type] operation isn't cancelled. Wait
and retry in a few seconds. |
現時点では、Cloud SQL はインポート オペレーションとエクスポート オペレーションをキャンセルできません。しばらくしてから、もう一度お試しください。問題が解決しない場合は、Google Cloud サポートまでご連絡ください。 |
クローンを作成
| 問題 | トラブルシューティング |
|---|---|
constraints/sql.restrictAuthorizedNetworks エラーでクローンの作成に失敗する。 |
クローン作成のオペレーションが、Authorized Networks 構成によってブロックされている。Authorized Networks は、Google Cloud Console の [接続] セクションでパブリック IP アドレスに構成されており、セキュリティに関する考慮事項により、クローン作成が許可されていません。可能であれば、Cloud SQL インスタンスからすべての |
エラー メッセージ: Failed to create subnetwork. Couldn't find free
blocks in allocated IP ranges. Please allocate new ranges for this service
provider. Help Token: [help-token-id]. |
Google Cloud コンソールを使用して、プライベート IP アドレスを持つインスタンスのクローンを作成しようとしていますが、割り振られた IP 範囲を指定しなかったため、ソース インスタンスが指定した範囲で作成されていません。その結果、クローニングされたインスタンスはランダムな範囲に作成されます。
|
接続
| 問題 | トラブルシューティング |
|---|---|
Aborted connection. |
次のような問題が考えられます。
アプリケーションは、接続プールや再試行などのベスト プラクティスに従ってネットワーク障害に対応する必要があります。通常、可能であれば、これらのエラーが接続プーラーによって検出されます。エラーが検出されない場合、アプリケーションは、再試行するか安全に失敗する必要があります。 接続の再試行には、次の方法をおすすめします。
これらの方法を組み合わせると、スロットリングが減ります。 |
Certificate verify failed。 |
クライアント証明書の有効期限が切れているか、証明書のパスが正しくありません。 証明書を再作成して再生成します。 |
FATAL: database 'user' does not exist。 |
gcloud sql connect --user はデフォルトの postgres ユーザーでのみ機能します。デフォルト ユーザーで接続してから、ユーザーを変更します。 |
| 接続されているユーザーを確認する必要があります。 | データベースにログインし、次のコマンドを実行します。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 |
インスタンスの作成
| 問題 | トラブルシューティング |
|---|---|
エラー メッセージ: Failed to create subnetwork. Couldn't
find free blocks in allocated IP ranges. Please allocate new ranges for
this service provider |
割り振り済みの IP 範囲にこれ以上使用可能なアドレスがありません。いくつかのシナリオがあります。
この問題を解決するには、既存の割り振られた IP 範囲を拡張するか、プライベート サービス接続に追加の IP 範囲を割り振ります。詳細については、IP アドレス範囲を割り振るをご覧ください。 Cloud SQL インスタンスの作成時に 新しい範囲を割り当てる場合は、割り当てが既存の割り当てと重複しないように注意してください。 新しい 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
|
エラー メッセージ: Failed to create subnetwork. Router status is
temporarily unavailable. Please try again later. Help Token:
[token-ID] |
Cloud SQL インスタンスをもう一度作成してみてください。 |
エクスポート
| 問題 | トラブルシューティング |
|---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。 |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
バケットが存在し、バケットへのエクスポートを許可する Storage Object Creator ロール（roles/storage.objectCreator）が Cloud SQL インスタンス用のサービス アカウント（エクスポートを行っているアカウント）に付与されていることを確認します。Cloud Storage に適用される IAM ロールをご覧ください。 |
| CSV のエクスポートは機能したが、SQL エクスポートに失敗した。 | CSV 形式と SQL 形式ではエクスポート方法が異なります。SQL 形式ではデータベース全体がエクスポートされるため、完了までに時間がかかります。CSV 形式ではエクスポートに含めるデータベースの要素を定義できます。 CSV エクスポートを使用して必要なものだけをエクスポートします。 |
| エクスポートに時間がかかりすぎる。 | Cloud SQL では同時実行オペレーションの同期がサポートされません。 エクスポートをオフロードします。エクスポートをオフロードするときに、Cloud SQL はソース インスタンスでエクスポートを発行するのではなく、オフロード インスタンスを起動してエクスポートを実行します。エクスポート オフロードには、ソース インスタンスでのパフォーマンス向上、エクスポート実行中の管理オペレーションのブロック解除などの利点があります。エクスポート オフロードでは、合計レイテンシがオフロード インスタンスの起動時間まで増加する可能性があります。一般に、適当なサイズのエクスポートでは、レイテンシは重要ではありません。ただし、エクスポートが小さい場合、レイテンシが増加することがあります。 |
| 拡張機能の作成のエラー。 | ダンプファイルに、サポートされていない拡張機能への参照が含まれています。 |
pg_dumpall の使用中にエラーが発生した。 |
--global フラグを指定して pg_dumpall ユーティリティを使用するには、スーパーユーザー ロールが必要ですが、このロールは Cloud SQL for PostgreSQL ではサポートされていません。ユーザー名を含むエクスポート オペレーションの実行中にエラーが発生しないようにするには、--no-role-passwords フラグも使用します。 |
エクスポートが完了する前にオペレーションがタイムアウトすると、Could not receive data from client: Connection reset
by peer. というエラー メッセージが表示されます。 |
Cloud Storage が所定の時間（通常は約 7 分）内にデータを受信しないと、接続はリセットされます。最初のエクスポート クエリは、非常に時間がかかる可能性があります。
|
| エクスポートを自動化したい。 | Cloud SQL には、エクスポートを自動化する方法がありません。 自動バックアップの自動化に関する記事のように、Google Cloud プロダクト（Cloud Scheduler、Pub/Sub、Cloud Functions）を使用して、独自の自動エクスポート システムを構築できます。 |
フラグ
| 問題 | トラブルシューティング |
|---|---|
| セッションのタイムゾーンは設定したが、ログアウトすると期限切れになる。 |
データベースに接続し、データベースのタイムゾーンをユーザーごとまたはデータベースごとに希望するタイムゾーンに設定します。 Cloud SQL for PostgreSQL では、次の項目を指定できます。これらの設定は、セッションを終了しても残り、 ALTER DATABASE dbname SET TIMEZONE TO 'timezone'; ALTER USER username SET TIMEZONE TO 'timezone'; これらの設定は、データベースへの新しい接続にのみ適用されます。タイムゾーンの変更を確認するには、インスタンスから接続解除して再接続します。 |
高可用性
| 問題 | トラブルシューティング |
|---|---|
| 手動フェイルオーバーの指標が表示されない。 | 自動フェイルオーバーの指標のみが表示されます。 |
| Cloud SQL インスタンス リソース（CPU と RAM）の使用率が 100% に近いため、高可用性インスタンスが停止する。 | インスタンスのマシンサイズが負荷に対して小さすぎます。 インスタンスを編集してより大きなマシンサイズにアップグレードし、CPU とメモリのサイズを大きくします。 |
インポート
| 問題 | トラブルシューティング |
|---|---|
エラー メッセージ: permission denied for schema public |
PostgreSQL バージョン 15 以降では、ターゲット データベースが template0 から作成されている場合、データのインポートが失敗することがあります。この問題を解決するには、GRANT ALL ON SCHEMA public TO cloudsqlsuperuser SQL コマンドを実行して、cloudsqlsuperuser ユーザーに公開スキーマ権限を付与します。 |
HTTP Error 409: Operation failed because another operation was already in progress |
保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。 |
| インポート オペレーションに時間がかかりすぎる。 | アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。 未使用のオペレーションを終了します。Cloud SQL インスタンスの CPU とメモリの使用量をチェックして、十分なリソースがあることを確認します。インポートに最大限のリソースを確保するため、オペレーションを開始する前にインスタンスを再起動することをおすすめします。 再起動により、次の処理が行われます。
|
| ダンプファイルで参照しているユーザーが存在しない場合、インポート オペレーションが失敗することがある。 | ダンプファイルをインポートする前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーがターゲット データベース内に存在している必要があります。そうでない場合、インポート オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。 インポートする前に、データベース ユーザーを作成します。 |
| データをインポートした後は、データのディスク使用量が大幅に増大します。 | データをインポートした後、予期しないディスク使用量が発生している可能性があります。この状況では、ポイントインタイム リカバリが使用されている可能性があります。 この問題を解決するには、データをインポートした後、ログを削除してストレージを復元する必要がある場合に、ポイントインタイム リカバリを無効にします。ストレージの使用量が少なくなっても、インスタンスにプロビジョニングされたストレージのサイズは縮小されません。 |
エラー メッセージ: GRANT stderr: ERROR: must be member of role ROLE_NAME |
このエラー メッセージは、Cloud SQL データベースに、Cloud Storage にアップロードされた SQL ダンプファイルをインポートしようとしたとき、そしてインポート ジョブが約 4 日間実行された場合に表示されます。 ROLE_NAME は、移行元の PostgreSQL データベースで定義されたカスタム データベース ロールです。デフォルトの この問題を解決するには、次の操作を行います。
|
ロギング
| 問題 | トラブルシューティング |
|---|---|
| ロギングで Cloud SQL インスタンスの CPU とメモリが大量に使用されている。 | ロギングを調整する必要があります。
|
| 監査ログが見つからない。 | オペレーションが、ユーザー作成データを作成、変更、または読み取る認証済みのユーザー ドリブン API 呼び出しの場合、またはリソースの構成ファイルまたはメタデータにアクセスした場合にのみ、データアクセス ログに書き込まれます。 |
| ログにオペレーション情報が見つからない。 | オペレーションの詳細を確認したい場合があります。 たとえば、ユーザーが削除され、誰がその操作を行ったのかを確認できない場合があります。ログでは、オペレーションが開始したことは確認できますが、それ以上の情報は記録されません。このような詳細な個人情報（PII）を記録するには、監査ログを有効にする必要があります。 |
| ログファイルが読みにくい。 | ログを json またはテキストで表示することもできます。gcloud logging read コマンドを Linux の後処理コマンドと一緒に使用して、ログをダウンロードできます。ログを JSON 形式でダウンロードするには:
gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_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%2FLOG_NAME" \ --format json \ --project=PROJECT_ID \ --freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \ | .textPayload' \ --order=asc > downloaded-log.txt |
| PostgreSQL ログでクエリログが見つからない。 | pgaudit フラグを有効にする必要があります。
|
インスタンスの管理
| 問題 | トラブルシューティング |
|---|---|
| 実行中のクエリを調べたい。 | データベースに接続して次のクエリを実行します。
|
| 特定のフィールドで使用されているユニットを確認したい。 | データベースに接続して次のクエリを実行します（独自の FIELD_NAME を使用します）。
|
| データベース設定の現在の値を確認したい。 | データベースに接続して次のクエリを実行します（独自の SETTING_NAME を使用します）。
すべての設定を表示するには、 |
| ブロックされたバックグラウンド プロセスを停止したい。 | ユーザーに pg_signal_backend のロールが必要です。次のコマンドを実行します。
|
| インスタンスによるトランザクション ID の消費量が 100% に近づいている。 | 内部モニタリングは、インスタンスがトランザクション ID を 100% 近く消費していることを警告します。書き込みがブロックされる可能性があるトランザクションのラップアラウンドは回避したい。 autovacuum ジョブがブロックされるか、ワークロードの速度に対応できる速さでトランザクション ID が再利用されていない可能性があります。 トランザクションのラップアラウンド問題によるサービス停止を回避するために、TXID ラップアラウンドの処理に関するセルフサービスのヒントをご覧ください。 一般的な調整のアドバイスについては、PostgreSQL における VACUUM オペレーションの最適化、モニタリング、トラブルシューティングをご覧ください。 |
| 一時ストレージにより、自動ストレージが増加した。 | 自動ストレージが有効になっています。 再起動すると一時ファイルは削除されますが、保存容量は減りません。インスタンスのサイズをリセットできるのはカスタマー サポートのみです。 |
| データが自動的に削除される。 | ほとんどの場合、環境内のどこかでスクリプトが実行されています。 削除時刻の前後のログで、ダッシュボードや別の自動プロセスから不正なスクリプトが実行されていないかどうかを確認します。 |
| インスタンスを削除できない。 | エラー メッセージ 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 つは、 |
| アップグレード中の致命的なエラー。 | ログに詳細が表示される場合がありますが、インスタンスを強制的に再作成するにはカスタマー サポートが必要になる場合があります。 |
| ディスク容量が不足した後、再起動時にインスタンスが停止する。 | 自動ストレージ増加機能が有効になっていません。 インスタンスのストレージが不足していてストレージの自動増加機能が有効になっていない場合、インスタンスはオフラインになります。この問題を回避するには、インスタンスを編集して、ストレージの自動増加を有効にします。 |
| オンプレミスのプライマリ インスタンスが停止する。 | Google Cloud では、Cloud SQL に含まれていないインスタンスはサポートされません。 |
| 再起動時のシャットダウンが遅い。 | インスタンスをシャットダウンしたときに、60 秒以内に終了しない未処理の接続があると、不完全なシャットダウンが発生します。 接続が 60 秒未満の場合は、データベース コマンドのプロンプトからの接続を含め、ほとんどのクリーンでないシャットダウンを回避できます。これらの接続を数時間または数日間維持すると、不完全なシャットダウンが発生する場合があります。 |
| ユーザーを削除できない。 | データベースに依存しているオブジェクトが存在する可能性があります。これらのオブジェクトを削除するか、別のユーザーに再割り当てする必要があります。 ユーザーに依存しているオブジェクトを特定し、それらのオブジェクトをドロップするか、別のユーザーに再度割り当てます。 ユーザーが所有するオブジェクトを見つける方法については、Stack Exchange に関するスレッドをご覧ください。 |
| 特定のクエリの実行が遅い。 | クエリが遅くなる理由はさまざまですが、その多くはデータベース側の問題です。Cloud SQL でネットワーク レイテンシが問題になるのは、ソース（ライターまたはリーダー）リソースと宛先（Cloud SQL）リソースが異なるリージョンに存在している場合です。 一般的なパフォーマンスのヒントをご覧ください。 データベースの挿入、更新、削除が遅い場合は、次のことを考慮します。
レイテンシを低減するために、ソースリソースと宛先リソースの両方を同じリージョンに配置することをおすすめします。 |
| メモリ不足が示されているが、モニタリング グラフに表示されない。 | インスタンスが失敗し、Out of memory が報告されていても、Google Cloud Console または Cloud Monitoring のグラフにはメモリがまだ残っているように表示される場合があります。ワークロード以外にも、アクティブな接続の数や内部オーバーヘッド プロセスなど、メモリ使用量に影響を与える可能性のある要因があります。こうしたことが常にモニタリング グラフに反映されるとは限りません。 インスタンスに、ワークロードと追加のオーバーヘッドを考慮するのに十分なオーバーヘッドがあることを確認してください。 |
| 削除したインスタンスを復元する。 | インスタンスを削除すると、バックアップを含め、そのインスタンスのすべてのデータが完全に失われます。 データを保持するには、インスタンスを削除する前に Cloud Storage にデータをエクスポートします。 Cloud SQL 管理者のロールには、インスタンスを削除する権限が含まれています。誤って削除されないように、このロールは必要な場合にのみ付与してください。 |
| 既存の Cloud SQL インスタンスの名前を変更したい。 | 既存のインスタンス名の変更はサポートされていません。 新しいインスタンスを作成することにより、既存のインスタンス名を変更できます。
いずれの場合も、オペレーションの完了後に古いインスタンスを削除できます。パフォーマンスには影響がなく、インスタンスの構成設定（フラグ、マシンタイプ、ストレージ サイズ、メモリなど）をやり直す必要がないことから、クローンルートを使用することをおすすめします。 |
| インスタンスの削除中にエラーが発生しました。 | インスタンスに対して削除保護が有効になっている場合は、インスタンスを削除する計画を確認します。次に、インスタンスを削除する前に削除保護を無効にします。 |
レプリケーション
| 問題 | トラブルシューティング |
|---|---|
| 作成時にリードレプリカがレプリケーションを開始しなかった。 | ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。 |
| リードレプリカを作成できない - invalidFlagValue エラー。 | リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。 まず、
|
| リードレプリカを作成できない - 不明なエラー。 | ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。 エラーが |
| ディスクに空きがない。 | レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。 |
| ディスク容量が大幅に増加します。 | データの追跡に使用されていないスロットでは、PostgreSQL が WAL セグメントに無期限に維持するため、ディスク容量は無期限に増加します。Cloud SQL で論理レプリケーションと論理デコーディング機能を使用すると、レプリケーション スロットが自動的に作成、削除されます。pg_replication_slots システムビューにクエリを実行し、active 列でフィルタリングすると、未使用のレプリケーション スロットを検出できます。未使用のスロットを削除することで、pg_drop_replication_slot コマンドで WAL セグメントを削除できます。 |
| レプリカ インスタンスのメモリ使用量が多すぎる。 | レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。 |
| レプリケーションが停止した。 | ストレージの上限に達しており、ストレージの自動増量が有効になっていません。 インスタンスを編集して |
| レプリケーション ラグが常に大きい。 | 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
考えられる解決策は次のとおりです。
|
| PostgreSQL 9.6 でインデックスを再構築する際のエラー。 | 特定のインデックスを再構築する必要があることを示す PostgreSQL のエラーが発生します。これは、プライマリ インスタンスでのみ行うことができます。新しいレプリカ インスタンスを作成すると、すぐに同じエラーが発生します。バージョン 10 より前の PostgreSQL ではハッシュ インデックスはレプリカに伝播されません。 ハッシュ インデックスを使用する必要がある場合は、PostgreSQL 10 以降にアップグレードしてください。レプリカも使用する場合は、PostgreSQL 9.6 でハッシュ インデックスを使用しないでください。 |
| プライマリ インスタンスでのクエリは常に実行中です。 | レプリカの作成後、クエリ SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' はプライマリ インスタンスで継続的に実行されます。 |
| レプリカの作成がタイムアウトで失敗する。 | プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。 実行中のクエリをすべて停止してからレプリカを再作成します。 |