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

特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、gcloud sql operations list コマンドを実行します。

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

• Cloud Audit Logs が有効で、表示に必要な権限がある場合は、cloudaudit.googleapis.com/activity を使用できる場合があります。

データの最終バックアップを作成せずにインスタンスを削除すると、データを復元できなくなります。ただし、インスタンスを復元すると、Cloud SQL はバックアップも復元します。削除されたインスタンスの復元について詳しくは、インスタンスの削除後もバックアップを保持するをご覧ください。

エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。

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

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

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

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

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

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

CREATE UNLOGGED TABLE ....

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

• ログに記録されていないテーブルの内容は、HA インスタンスのフェイルオーバー後に保持されません。
• ログに記録されていないテーブルは、Postgres のクラッシュ後に保持されません。
• ログに記録されないテーブルはリードレプリカに複製されません。
• ログに記録されていないテーブルは、バックアップの復元中に自動的にワイプされます。

解決策としては、バックアップを使用してテーブルを復元する場合に、ログに記録されていないテーブルを使用しないことです。すでにログに記録されていないテーブルがあるデータベースから復元する場合は、データベースをファイルにダンプし、これらのテーブルのダンプ済みファイルを ALTER TABLE から SET LOGGED に変更した後にデータを再読み込みできます。

• インスタンスの既存のバックアップ構成と一致するように最終バックアップ値を設定します。
• インスタンスを削除するときは、最終バックアップ フィールドを空のままにします。このフィールドを空のままにすると、Cloud SQL はインスタンス設定で設定された最終バックアップ構成を受け取って最終バックアップを取得し、その保持期間を定義します。

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

Google Cloud コンソールを使用して、プライベート IP アドレスを持つインスタンスのクローンを作成しようとしていますが、割り振られた IP 範囲を指定しなかったため、ソース インスタンスが指定した範囲で作成されていません。その結果、クローニングされたインスタンスはランダムな範囲に作成されます。

gcloud を使用してインスタンスのクローンを作成し、
--allocated-ip-range-name パラメータの値を指定します。詳細については、プライベート IP を使用したインスタンスのクローン作成をご覧ください。

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

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

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

1. 指数バックオフ。再試行の間隔を指数関数的に増やします。
2. ランダム化されたバックオフも追加します。

これらの方法を組み合わせると、スロットリングが減ります。

• Microsoft Entra ID ログインの作成オペレーションに時間がかかる
• Microsoft Entra ID ログインを作成できない
• Microsoft Entra ID 認証を使用してインスタンスに接続できない

これらの問題の解決方法について詳しくは、Microsoft Entra ID 統合のトラブルシューティングをご覧ください。

デフォルト ユーザーで接続してから、ユーザーを変更します。

インスタンスの作成をリクエストした時点で、選択したゾーンに、リクエストされたリソースまたは VM タイプに対応できるだけの容量がなかったことを意味します。リクエストを行ったのと同じ時点で、その特定のリージョン ロケーションで運用上の需要が高まっていた可能性があります。

この問題を解決するには、別のゾーンでインスタンスの作成を再試行するか、このエラーが発生したゾーンで別の時間にインスタンスの作成を再試行します。

• Private Service Connect に割り振られた IP 範囲のサイズが /24 より小さい。
• プライベート サービス接続に割り振られた IP 範囲のサイズが、Cloud SQL インスタンスの数に対して小さすぎる。
• インスタンスを複数のリージョンで作成すると、割り振られた IP 範囲のサイズに関する要件が大きくなります。割り振られた範囲のサイズをご覧ください。

この問題を解決するには、既存の割り振られた IP 範囲を拡張するか、プライベート サービス接続に追加の IP 範囲を割り振ります。詳細については、IP アドレス範囲を割り振るをご覧ください。

Cloud SQL インスタンスの作成時に --allocated-ip-range-name フラグを使用した場合は、指定した 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
    

次のコマンドを使用して Service Networking API を有効にし、Cloud SQL インスタンスをもう一度作成してみてください。

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

Cloud SQL インスタンスのサーバー証明書に追加する DNS 名が次の条件を満たしていることを確認します。

• ワイルドカード文字が含まれていない。
• 末尾にピリオドがない。
• RFC 1034 の仕様に適合している。

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

エクスポートをオフロードします。エクスポートをオフロードするときに、Cloud SQL はソース インスタンスでエクスポートを発行するのではなく、オフロード インスタンスを起動してエクスポートを実行します。エクスポート オフロードには、ソース インスタンスでのパフォーマンス向上、エクスポート実行中の管理オペレーションのブロック解除などの利点があります。エクスポート オフロードでは、合計レイテンシがオフロード インスタンスの起動時間まで増加する可能性があります。一般に、適当なサイズのエクスポートでは、レイテンシは重要ではありません。ただし、エクスポートが小さい場合、レイテンシが増加することがあります。

ダンプファイルを編集して参照を削除します。

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

バックアップの自動化に関する記事のように、 Google Cloudプロダクト（Cloud Scheduler、Pub/Sub、Cloud Run functions）を使用して、独自の自動エクスポート システムを構築できます。

外部プライマリが接続できることを確認します。また、ソース インスタンスの net_read_timeout フラグと net_write_timeout フラグの値を変更して、エラーを防ぐこともできます。これらのフラグに使用可能な値の詳細については、データベース フラグを構成するをご覧ください。

マネージド インポート移行の mysqldump フラグの使用方法については、使用可能な初期同期フラグとデフォルトの初期同期フラグをご覧ください。

binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db などのレプリケーション フラグが競合する方法で設定されていないことを確認します。

プライマリ インスタンスで show master status コマンドを実行して、現在の設定を確認します。

• Google Cloud コンソールの [Cloud Monitoring] セクションで、レプリカ インスタンスのレプリケーション指標を確認します。
• MySQL IO スレッドまたは SQL スレッドのエラーは、mysql.err log ファイルの Cloud Logging で確認できます。
• このエラーは、レプリカ インスタンスに接続するときにも発生する場合があります。SHOW SLAVE STATUS コマンドを実行して、出力で次のフィールドを確認します。
  • Slave_IO_Running
  • Slave_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

レプリカ インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。

正しいフラグを設定して新しいダンプファイルを作成し、そのファイルを使用して外部レプリカを構成します。

1. Compute Engine インスタンスを介して mysql クライアントに接続します。
2. mysqldump を実行し、--master-data=1 フラグと --flush-privileges フラグを使用します。

   重要: --set-gtid-purged=OFF フラグを含めないでください。

   詳細。

3. 作成したダンプファイルに SET @@GLOBAL.GTID_PURGED='...' 行が含まれていることを確認します。
4. ダンプファイルを Cloud Storage バケットにアップロードし、ダンプファイルを使用してレプリカを構成します。

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