Cloud SQL インスタンスでの問題を診断する

このページでは、Cloud SQL インスタンスの使用中に特に頻繁に発生する可能性のある問題と、その問題に対処するための手順について説明します。既知の問題ページも確認してください。ここの情報で問題が解決しない場合は、サポートの概要を参照してください。

ログの表示

最近のオペレーションに関する情報は、Cloud SQL インスタンス オペレーション ログまたは PostgreSQL エラーログで確認できます。

接続の問題

アプリケーションが実行中であることを確認する

Aborted connection nnnn to db:」というエラーが表示された場合は、通常、アプリケーションの接続が正しく終了されていないことを示します。ネットワークの問題が原因である可能性もあります。このエラーは、Cloud SQL インスタンスに問題があることを意味するものではありません。

接続を管理する際のおすすめの方法の例については、接続の管理をご覧ください。

証明書が期限切れではないことを確認する

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

接続を許可されていることを確認する

接続が失敗する場合は、接続を許可されていることを確認します。

  • IP アドレスで接続できない場合(たとえば、PSQL クライアントを使用してオンプレミス環境から接続している場合)、接続元の IP アドレスに Cloud SQL インスタンスへの接続が許可されていることを確認します。こちらが現在の IP アドレスです。
  • gcloud sql connect でインスタンスに接続してみます。このコマンドは現在の IP アドレスを短時間だけ承認します この方法は、Cloud SDK と PSQL クライアントがインストールされている環境で実行できます。このコマンドは Cloud Shell でも実行できます。Google Cloud Platform Console で使用できる Cloud Shell には、Cloud SDK と PSQL クライアントがプリインストールされています。Cloud Shell で提供される Compute Engine インスタンスを使用して、Cloud SQL に接続できます。
  • 0.0.0.0/0 を承認し、インスタンスに対するアクセスをすべての IP アドレスに一時的に許可します。これにより、クライアントが接続可能であることを確認できます。

接続の開始状態を確認する

現在の接続に関する情報を表示するには、次のコマンドを実行します。

SELECT * from pg_stat_activity ;

接続に 1.2.3.4 のような IP アドレスが示されている場合、その接続では IP が使用されています。cloudsqlproxy~1.2.3.4 が示されている接続の場合は、Cloud SQL Proxy が使用されているか、App Engine から発信されています。localhost からの接続は、通常、App Engine から第 1 世代インスタンスに接続されますが、このパスは、一部の内部 Cloud SQL プロセスによっても使用されます。

接続制限を確認する

Cloud SQL インスタンスに QPS の制限はありません。ただし、接続数やサイズの制限および App Engine 固有の制限はあります。割り当てと制限をご覧ください。

データベース接続は、サーバーと接続元アプリケーションのリソースを消費します。アプリケーションのフットプリントを最小限に抑え、Cloud SQL の接続制限を超える可能性を少なくするには、常に適切な接続管理方法を使用してください。詳細については、データベース接続の管理をご覧ください。

接続数とスレッド数を表示する

データベース上で実行されているプロセスを確認するには、pg_stat_activity テーブルを使用します。

select * from pg_stat_activity;

Compute Engine からの接続

Compute Engine インスタンスと Cloud SQL インスタンスの間の接続に長期間使用されない接続が含まれると予想される場合は、Compute Engine インスタンスとの接続はアクティブでない状態が 10 分間続くとタイムアウトすることに注意する必要があります。詳細については、Compute Engine のドキュメントのネットワークとファイアウォールをご覧ください。

長時間使用されない接続がタイムアウトしないようにするには、TCP キープアライブを設定できます。次のコマンドを TCP キープアライブの値を 1 分に設定し、インスタンスが再起動しても構成が変わらないようにします。

# Display the current tcp_keepalive_time value.
cat /proc/sys/net/ipv4/tcp_keepalive_time

# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

# Apply the change.
sudo /sbin/sysctl --load=/etc/sysctl.conf

# Display the tcp_keepalive_time value to verify the change was applied.
cat /proc/sys/net/ipv4/tcp_keepalive_time

接続のタイムアウト

クライアントがプライベート IP を使用して Cloud SQL インスタンスに接続できない場合は、クライアントが 172.17.0.0/16 の範囲の IP を使用しているかどうかを確認してください。プライベート IP を使用して、172.17.0.0/16 の範囲内の IP から Cloud SQL インスタンスに接続することはできません。また、この範囲内の IP で作成された Cloud SQL インスタンスはすべて到達不能になります。この範囲は Docker ブリッジ ネットワークに予約されています。

インスタンスの問題

ディスク容量

インスタンスが許される最大ストレージ容量に達すると、データベースへの書き込みは失敗します。たとえば、テーブルの破棄などによってデータを削除すると、容量が解放されますが、報告されるインスタンスのストレージ使用量には反映されません。VACUUM FULL コマンドを実行すると、未使用領域を復元できますが、vacuum コマンドが完了するまで書き込みオペレーションは実行できません。詳細についてはこちらをご覧ください。

停止状態

次のようなさまざまな理由で、Cloud SQL はインスタンスを停止する可能性があります。

  • 請求に関する問題

    たとえば、プロジェクトの請求先アカウントのクレジット カードの有効期限が切れた場合、インスタンスが停止されることがあります。プロジェクトのお支払い情報を確認するには、Google Cloud Platform Console の請求ページでプロジェクトを選択し、プロジェクトに使用されている請求先アカウント情報を表示します。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻るはずです。

  • 法的な問題

    たとえば、GCP 利用規定に違反すると、インスタンスが停止されることがあります。詳細については、GCP 利用規約の「停止と削除」に関する条項をご覧ください。

  • オペレーション上の問題

    たとえば、インスタンスが起動中または起動直後にクラッシュ ループに陥ってクラッシュした場合、Cloud SQL はそのインスタンスを停止することがあります。

停止が請求の問題によって引き起こされた場合、インスタンスが停止されている間は、引き続きそのインスタンスに関する情報を表示したり、インスタンスを削除したりすることができます。

プラチナ、ゴールド、シルバーのサポート パッケージをお持ちの Cloud SQL ユーザーは、停止されているインスタンスについてサポートチームに直接問い合わせることができます。すべてのユーザーは、上記のガイダンスと併せて Google Cloud SQL フォーラムを利用できます。

パフォーマンス

データベース スキーマとテーブルを合理的な数に維持する

データベース スキーマとテーブルはシステム リソースを消費します。数が非常に多くなると、インスタンスのパフォーマンスに影響する可能性があります。

一般的なパフォーマンスのヒント

インスタンスがメモリや CPU の制限を受けないようにします。高いパフォーマンスが要求されるワークロードの場合、インスタンスに 60 GB 以上のメモリを割り当ててください。

データベースの挿入、更新、削除が遅い場合は、書き込みとデータベースのロケーションを確認します。データの送信距離が長いと、レイテンシが発生します。

データベースの選択が遅い場合は、次のことを考慮します。

  • 読み取りのパフォーマンスにはキャッシュが極めて重要です。PostgreSQL Statistics Collector でさまざまな blks_hit / (blks_hit + blks_read) の比率を確認します。99% 以上になっているのが理想的です。そうでない場合は、インスタンスの RAM のサイズを増やすことを検討します。
  • ワークロードが CPU を大量に使用するクエリ(並べ替え、正規表現、その他の複雑な関数)で構成されている場合、インスタンスが制限される可能性があります。その場合には、vCPU を追加します。
  • 書き込みとデータベースのロケーションを確認します。レイテンシは、書き込みパフォーマンスより読み取りパフォーマンスに大きく影響します。
  • 適切なインデックスの追加、スキャンするデータの削減、余分なラウンド トリップの回避など、Cloud SQL に固有ではないパフォーマンス向上手段を調査します。
クエリ実行のパフォーマンスが低い場合は、EXPLAIN を使用して、クエリ パフォーマンスを改善するために、テーブルのどこにインデックスを追加すべきか特定します。たとえば、JOIN キーとして使用するすべてのフィールドについて、両方のテーブルにインデックスを作成します。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...