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

このページでは、サポートされているデータベース エンジンで発生する Cloud SQL に関する問題のトラブルシューティングを行う際のヒントを紹介します。これらのヒントには特定のデータベース エンジンだけに適用されるものと、データベース エンジン全般に共通なものがあります。

特定のデータベース エンジンのトラブルシューティングのヒントについては、該当する各ページをご覧ください。

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

バックアップと復元

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

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

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

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

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

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

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

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


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

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

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

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

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

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

  • 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 TABLE ...

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

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

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

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


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

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

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

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

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

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


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

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

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

バックアップの作成がタイムアウト時間に達しました。

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

バックアップの作成に影響するフラグは 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 エントリなしでレプリカを作成します。

接続

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

この問題については... 次のような問題が考えられます... 次のことを試します...
Aborted connection パケットの読み取りエラー、または接続が中断された。 次の方法をお試しくださいをご覧ください。
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 ライブラリを使用しているクライアントは、mysql インスタンスの一部の証明書を解析できない場合があります。「cancelled」などの一般的なエラーとしてクライアントに表示される場合があります。 この問題を回避する方法は、サーバー証明書をローテーションして、クライアント証明書を再作成することです。
Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection 割り振り範囲を変更または削除した後に VPC ピアリングが更新されませんでした。 VPC ピアリングの更新の詳細については、次の方法をお試しくださいをご覧ください。
Allocated IP range not found in network 割り振り範囲を変更または削除した後に VPC ピアリングが更新されませんでした。 VPC ピアリングの更新の詳細については、次の方法をお試しくださいをご覧ください。
ERROR: (gcloud.sql.connect) It seems your client does not have ipv6 connectivity and the database instance does not have an ipv4 address. Please request an ipv4 address for this database instance. Cloud Shell を使用してプライベート IP インスタンスに接続しようとしています。 現時点では、Cloud Shell からプライベート IP アドレスのみを持つインスタンスへの接続はサポートされていません。

接続が中断された

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

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

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

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

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

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

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


FATAL: database 'user' does not exist

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 へのネットワーク ピアリングを更新する必要があります。例:

    Cloud SQL Auth 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 ライブラリを使用すると、mysql インスタンスの証明書の解析に失敗する場合があります。「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

Service Networking API が有効になっていない可能性があります。

最近削除されたインスタンスと同じ名前のインスタンスを作成しようとしている可能性があります。

複数のインスタンスを同時に作成しようとしている可能性があります。

IP 範囲に使用可能なアドレスがなくなった場合、サブネットの作成に失敗する可能性があります。

Service Networking API を有効にします。

インスタンスに別の名前を使用するか、インスタンスが削除されてから 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 のようなエラー メッセージが表示されます。

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

  • Service Networking API が有効になっていない可能性があります。
  • 最近削除したインスタンスの名前を再利用しようとしている可能性があります。インスタンス名を削除した後、1 週間は再利用できません。
  • 複数のインスタンスを同時に作成しようとしている可能性があります。この場合、最初のインスタンスのみが作成され、残りは Unknown error で失敗します。一度に 1 つの作成オペレーションしか実行できません。
  • IP 範囲に使用可能なアドレスがなくなった場合、サブネットの作成に失敗する可能性があります。

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

  • Service Networking API を有効にします。
  • インスタンスに別の名前を使用するか、1 週間待ってから、その名前で新しいインスタンスを作成します。
  • 複数のインスタンスを同時に作成するのではなく、連続して作成します。
  • 以下のサブネットワークを作成できないのセクションをご覧ください。

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

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]

外部プライマリ

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

この問題については... 次のような問題が考えられます... 次のことを試します...
Specified key was too long; max key length is 767 bytes 外部プライマリ インスタンスに innodb_large_prefix 変数が設定されている可能性があります。 レプリカを作成するときに、innodb_large_prefix フラグON に設定します。あるいは、フラグを使用して、既存のレプリカを更新します。
Table definition has changed ダンプ処理中にデータ定義言語(DDL)が変更されました。 ダンププロセス中の DDL の変更を回避します
エラー メッセージ: Access denied; you need (at least one of) the SUPER privilege(s) for this operation ソース データベースのビュー、関数、またはプロシージャが、Cloud SQL でサポートされていない方法で DEFINER を参照している可能性があります。 Cloud SQL での DEFINER の使用状況に関する詳細をご覧ください。
エラー メッセージ: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost レプリカに存在しない DEFINER がソース データベースにあります。 Cloud SQL での DEFINER の使用状況に関する詳細をご覧ください。
Lost connection to MySQL server during query when dumping table ソースが使用不能か、ダンプに含まれているパケットが大きすぎる可能性があります。 外部プライマリが接続可能な状態にします。または、max_allowed_packet オプションを指定して mysqldump を使用します。
Got packet bigger than 'max_allowed_packet' bytes when dumping table パケットが、設定された許容量を超えました。 max_allowed_packet オプションを指定して mysqldump を使用します。
最初のデータの移行は成功しましたが、データが複製されていません。 レプリケーション フラグが競合している可能性があります。 こちらのフラグ設定をご確認ください。
最初のデータ移行は成功しましたが、しばらくするとデータ レプリケーションが機能しなくなります。 さまざまな原因が考えられます。 次の手順を試してください。
mysqld check failed: data disk is full レプリカ インスタンスのデータディスクに空き容量がありません。 レプリカ インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。

指定された鍵が長すぎる(キーの最大長は 767 バイト)

Specified key was too long; max key length is 767 bytes. というエラーが表示されます。

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

外部プライマリ インスタンスに innodb_large_prefix 変数が設定されている可能性があります。この場合、インデックス キーの接頭辞を 767 バイトより長くすることができます。MySQL 5.6 のデフォルト値は OFF です。

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

レプリカを作成するときに、innodb_large_prefix フラグを ON に設定します。あるいは、フラグを使用して、既存のレプリカを更新します。


表の定義が変更された

Table definition has changed というエラーが表示されます。

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

ダンプ処理中に DDL が変更されました。

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

ダンプ処理中のテーブルの変更や、その他の DDL の変更を行わないでください。


アクセスが拒否された(この操作を行うには、SUPER の権限の少なくとも 1 つが必要)

Access denied; you need (at least one of) the SUPER privilege(s) for this operation というエラーが表示されます。

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

根本原因としては、DEFINER に super user@localhost(root@localhost など)が指定された VIEW/FUNCTION/PROCEDURE を使用している可能性があります。これは Cloud SQL ではサポートされていません。

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

これを回避するには、外部データベースで DEFINER 句を更新します。たとえば、root@localhostroot@% または non superuser に更新します。詳細については、保存オブジェクトのアクセス制御をご覧ください。


ERROR 1045 (28000) at line xxx: Access denied for user 'cloudsqlimport'@'localhost

ERROR 1045 (28000) at line xxx: Access denied for user 'cloudsqlimport'@'localhost というエラーが表示されます。

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

レプリカ データベースに、ソース データベース内で DEFINER 句を持つユーザーが存在しません。このユーザーはソース データベースのオブジェクト定義で相互参照されています。

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

ユーザーが移行されていません。レプリケーションを開始する前に、レプリカ データベースにソース データベースのユーザーを作成します。


テーブルをダンプする際にクエリ中に MySQL サーバーとの接続が切断された

Lost connection to MySQL server during query when dumping table というエラーが表示されます。

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

  • レプリカからソースに接続できなくなった可能性があります。

  • ソース データベースに大規模な blob または長い文字列を含むテーブルが存在している可能性があります。この場合、ソース データベースで max_allowed_packet にさらに大きい数値に設定する必要があります。

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

  • 再起動して、外部プライマリが接続できることを確認します。

  • max_allowed_packet オプションを指定して mysqldump を使用し、データをダンプして、そのダンプファイルを使用して移行を行います。


テーブルをダンプする際に max_allowed_packet バイトを超えるパケットを取得した

Got packet bigger than 'max_allowed_packet' bytes when dumping table というエラーが表示されます。

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

パケットが、設定された許容量を超えました。

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

max_allowed_packet オプションを指定して mysqldump を使用し、データをダンプして、そのダンプファイルを使用して移行を行います。


複製中のデータがない

最初のデータの移行は成功しましたが、データが複製されていません。

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

根本原因の 1 つとして、ソース データベースでレプリケーション フラグが定義されている可能性があります。これにより、データベースの一部またはすべての変更が複製されていない可能性があります。

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

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

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


最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる

最初のデータ移行は成功しましたが、しばらくするとデータ レプリケーションが機能しなくなります。

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

この問題には、多数の根本原因が考えられます。

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

  • Cloud Monitoring UI でレプリカ インスタンスのレプリケーション指標を確認します。

  • MySQL IO スレッドまたは SQL スレッドでのエラーは、mysql.err ログファイルの Cloud Logging で確認できます。

  • このエラーは、レプリカ インスタンスに接続するときにも発生する場合があります。SHOW SLAVE STATUS コマンドを実行して、出力で次のフィールドを確認します。

    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

mysqld チェックエラー: データディスクに空きがない

mysqld check failed: data disk is full というエラーが表示されます。

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

DRAIN オペレーション中にこのエラーが表示された場合は、レプリカ インスタンスのデータディスクに空き容量が存在しません。

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

レプリカ インスタンスのディスクサイズを増やします。

外部レプリカ

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

この問題については... 次のような問題が考えられます... 次のことを試します...
エラー メッセージ: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires レプリカがログ読み取りの開始場所を認識できません。 正しいフラグを設定して新しいダンプファイルを作成し、そのファイルを使用して外部レプリカを構成します。

GTID を含むバイナリログが消去されている

MySQL に「The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires」というエラー メッセージが表示されます。

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

プライマリ Cloud SQL インスタンスでは、自動バックアップ、バイナリログ、ポイントインタイム リカバリが有効になっているので、レプリカが追いつくのに十分なログを保持する必要があります。しかし、この場合、バイナリログは存在しますが、読み取りを開始する行がレプリカで認識されません。

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

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

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

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

    詳細

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

フラグ

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

この問題については... 次のような問題が考えられます... 次のことを試します...
フラグを有効にするとインスタンスがクラッシュする。 max_connections フラグの値が高すぎる可能性があります。 カスタマー サポートに連絡してフラグの削除をリクエストします
タイムゾーンが自動的に変更されない。 タイムゾーンの自動変更はサポートされていません。 時刻を手動で変更する必要があります。詳細
Bad syntax for dict arg 複雑なパラメータ値の場合は特別な処理が必要です。 詳細については、こちらをご覧ください。
タイムゾーンを設定するフラグがない。 タイムゾーン フラグがサポートされていない。 いくつかの回避策があります。

フラグを有効にするとインスタンスがクラッシュする

フラグを有効にすると、インスタンスがパニックとクラッシュの間でループします。

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

max_connections フラグの値が高すぎると、このエラーが発生します。

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

カスタマー サポートに連絡して、フラグの削除をリクエストしてから hard drain を送信します。これにより、不必要なフラグや設定を使用せずに、新しい構成を使用して別のホストでインスタンスが再起動します。


タイムゾーンが自動的に変更されない

夏時間に合わせてタイムゾーンが自動的に変更されなかった。

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

Cloud SQL では自動でのタイムゾーンの変更はサポートされていないため、文字列ではなくタイムゾーンのオフセット値を使用して手動で行う必要があります。

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

インスタンスを編集して default_time_zone フラグを変更します。名前付きエリアはサポートされていません。たとえば、Europe/London ロンドンは UTC タイムゾーンにあり、default_time_zone フラグでサポートされる値は +00:00 です。


dict 引数の構文が正しくない

フラグを設定しようとすると、エラー メッセージ Bad syntax for dict arg が表示されます。

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

カンマ区切りのリストなど複雑なパラメータ値は、gcloud コマンドで使用するには特別な処理が必要です。

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

gcloud の --flags-file パラメータを使用します。このパラメータは、複雑なフラグ値に役立つ --flag:value 辞書を含む YAML ファイルまたは JSON ファイルを指定します。

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

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 とメモリのサイズを大きくします。

インポート

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

この問題については... 次のような問題が考えられます... 次のことを試します...
インポートに時間がかかりすぎる。 アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。 未使用の接続を閉じるか、インポート オペレーションを開始する前に Cloud SQL インスタンスを再起動してください。
インポートに失敗した。 エクスポートされたファイルに、まだ存在しないデータベース ユーザーが含まれている可能性があります。 インポートを再試行する前に、失敗したデータベースをクリーンアップします。インポートを行う前に、データベース ユーザーを作成します。
インポート中のエラー: テーブルが存在しません。 現時点では、必要なテーブルが存在しません。 インポート開始時に FOREIGN_KEY_CHECKS を無効にします
エラー メッセージ: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost' ダンプファイルに、データベースに存在しない DEFINER があります。 Cloud SQL での DEFINER の使用方法と考えられる回避策の詳細をご覧ください。
エラー メッセージ: Unknown table 'COLUMN_STATISTICS' in information_schema これは、MySQL 8.0 の mysqldump バイナリを使用して MySQL 5.7 データベースからデータをダンプし、それを MySQL 8.0 データベースにインポートする場合に発生します。 MySQL 5.7 データベースからデータをダンプし、MySQL 8.0 データベースにインポートする場合は、必ず MySQL 5.7 の mysqldump バイナリを使用してください。MySQL 8.0 の mysqldump バイナリを使用する場合は、--column-statistics=0 フラグを追加する必要があります。

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

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

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

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

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

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

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


インポートに失敗した

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

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

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

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

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


インポート中のエラー: テーブルが存在しません

インポート オペレーションが失敗し、テーブルが存在しないというエラーが表示されます。

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

テーブルには他のテーブルとの外部キーの依存関係がある場合があり、オペレーションの順序によっては、インポート オペレーション中に 1 つ以上のテーブルがまだ存在しない可能性があります。

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

次の行をダンプファイルの先頭に追加します。

  SET FOREIGN_KEY_CHECKS=0;

また、次の行をダンプファイルの末尾に追加します。

  SET FOREIGN_KEY_CHECKS=1;

これらの設定により、インポート オペレーション中のデータの整合性チェックが無効になり、データの読み込み後に再び有効になります。ダンプファイルの作成時にデータがすでに検証されているため、この設定はデータベース上のデータの整合性には影響しません。


エラー メッセージ: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'

ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost' というエラーが表示されます。

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

根本的な原因は、ダンプファイルに DEFINER 句のあるユーザーがあり、そのユーザーがデータベースに存在しないことと、そのユーザーがデータベースのオブジェクト定義で相互参照されていることです。

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

ダンプファイルで DEFINER 句を使用してデータベースをインポートする方法については、こちらのドキュメントをご覧ください。データベースに 1 人以上のユーザーを作成する必要があります。


エラー メッセージ: Unknown table 'COLUMN_STATISTICS' in information_schema

エラー メッセージ Unknown table 'COLUMN_STATISTICS' in information_schema が表示されます。

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

これは、MySQL 8.0 の mysqldump バイナリを使用して MySQL 5.7 データベースからデータをダンプし、それを MySQL 8.0 データベースにインポートする場合に発生します。

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

MySQL 5.7 データベースからデータをダンプし、MySQL 8.0 データベースにインポートする場合は、必ず MySQL 5.7 の mysqldump バイナリを使用してください。MySQL 8.0 の mysqldump バイナリを使用する場合は、--column-statistics=0 フラグを追加する必要があります。

エクスポート

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

この問題については... 次のような問題が考えられます... 次のことを試します...
オペレーションのステータスを確認できない。 ユーザー インターフェースには成功または失敗のみが表示されます。 詳細については、これらのデータベース コマンドをご覧ください。
エクスポート中の 408 Error (Timeout) データベースのサイズとエクスポート コンテンツによっては、SQL のエクスポートに時間がかかることがあります。 複数の CSV エクスポートを使用して各オペレーションのサイズを減らします
CSV のエクスポートは機能したが、SQL エクスポートに失敗した。 SQL のエクスポートでは、Cloud SQL との互換性の問題が発生する可能性が高くなります。 CSV のエクスポートを使用して必要なものだけをエクスポートします
エクスポートに時間がかかりすぎる。 Cloud SQL では同時実行オペレーションの同期がサポートされません。 エクスポートのオフロードを使用します。詳細については、こちらをご覧ください。
Error 1412: Table definition has changed エクスポート中にテーブルが変更されました。 ダンプ オペレーションからテーブル変更ステートメントを削除します
拡張機能の作成のエラー。 ダンプファイルには、サポートされていない拡張機能への参照が含まれています。 ダンプファイルを編集して参照を削除します
pg_dumpall の使用中にエラーが発生した。 このツールにはスーパーユーザーのロールが必要です。 スーパーユーザーのロールはサポートされていません
エクスポート オペレーションが、エクスポート完了前にタイムアウトする。 クエリで最初の 7 分以内にデータを生成する必要があります。 pg_dump ツールを使用して手動でエクスポートしてみてください
エクスポート オペレーション中に接続が切断しました。 クエリで最初の 7 分以内にデータを生成する必要があります。 クエリを手動でテストします。詳細については、こちらをご覧ください。
エクスポート中に不明なエラーが発生した。 帯域幅の問題である可能性があります。 インスタンスと Cloud Storage バケットの両方が同じリージョンに存在することを確認します
エクスポートを自動化する場合。 Cloud SQL には、エクスポートを自動化する方法がありません。 この機能を実行する独自のパイプラインを構築します。詳細については、こちらをご覧ください。
エラー メッセージ: Access denied; you need (at least one of) the SUPER privilege(s) for this operation super user@localhost(root@localhost など)を使用するダンプファイルには、イベント、ビュー、関数、またはプロシージャが含まれる場合があります。これは Cloud SQL ではサポートされていません。 Cloud SQL での DEFINER の使用方法と考えられる回避策の詳細をご確認ください。

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

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

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

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 では同時実行オペレーションの同期がサポートされません。

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

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


mysqldump: エラー 1412: テーブル定義が変更されました

エラー メッセージ mysqldump: Error 1412: Table definition has changed, retry transaction when dumping the table が表示されます。

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

エクスポート処理中にテーブル内で変更がありました。

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

エクスポート オペレーション中に次のステートメントを使用すると、ダンプ トランザクションが失敗する可能性があります。

  • ALTER TABLE
  • CREATE TABLE
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
これらのステートメントのいずれかをダンプ オペレーションから削除します。



pg_dumpall の使用中のエラー

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

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

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

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

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


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

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

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

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

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

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


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

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

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

エクスポートが開始されてから最初の 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 Storage バケットを Cloud SQL インスタンスの近くに移動します。アクティビティが減少したときに操作を実行します。

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

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

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

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. テーブルが存在していることを確認します。存在している場合は、バケットに対して正しい権限があることを確認します。

アクセスが拒否された(この操作を行うには、SUPER の権限の少なくとも 1 つが必要)

Access denied; you need (at least one of) the SUPER privilege(s) for this operation というエラーが表示されます。

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

super user@localhost(root@localhost など)を使用するダンプファイルには、イベント、ビュー、関数、またはプロシージャが含まれる場合があります。これは Cloud SQL ではサポートされていません。

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

DEFINER 句を使用したデータベースのインポートについては、こちらのドキュメントをご覧ください。

ロギング

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

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

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

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

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

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

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

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


監査ロギング

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

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

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

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

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


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

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

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

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

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

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


ロギングで大量のディスク容量を使用している

MySQL のログファイルが使用しているディスク容量を調べる必要があります。

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

ディスク容量を使用するログファイルには、REDO ログ、一般ログ、バイナリログの 3 種類があります。

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

各タイプのログファイルの詳細については、次のコマンドを実行します。

SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2) AS GB from mysql.general_log;

SHOW BINARY LOGS;

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

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


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

Cloud Logging for PostgreSQL でクエリログが見つかりません。

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

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 インスタンスを再起動します。

インスタンスの管理

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

この問題については... 次のような問題が考えられます... 次のことを試します...
MySQL 再起動後のパフォーマンスが低下する。 再起動後に InnoDB キャッシュが空になるため、すべての読み取りでデータを取得するためにバックエンドへのラウンド トリップが必要になります すべてのデータが追いつくまで待ちます。
クラッシュの復旧が遅い。 大量の general_log が蓄積している可能性があります。 一般的なロギングを管理します。詳細については、こちらをご覧ください。
ストレージの使用状況を確認する必要がある。 ほとんどの使用は、データベース テーブル、バイナリログ、または一時ファイルです。 確認方法については、こちらのヒントをご覧ください。
クエリがブロックされる。 1 つのプロセスが他のすべてをブロックしています。 ブロック プロセスを見つけて停止します。詳細
バイナリログを手動で削除することができない。 バイナリログは手動で削除できません。 関連する自動バックアップによって、バイナリログは、自動的に削除されます。これは通常、約 7 日後に発生します。
一時ファイルに関する情報を確認する必要がある。 一時ファイル名は ibtmp1 です。 詳しくは、こちらのデータベース クエリをご覧ください。
テーブルサイズについて確認する必要がある。 この情報はデータベースから入手できます。 詳しくは、こちらのデータベース クエリをご覧ください。
mysqld が signal 11 を受け取った。 クエリが作成する接続が多すぎるため、インスタンスがクラッシュしました。 これを回避するには、クエリをリファクタリングします
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. ページ クリーナーがインスタンスの変化率に追いつきません。 インスタンスのシャーディングで解決する可能性があります。
実行中のクエリを調べる必要がある。 該当なし こちらのデータベース クエリをお試しください。
特定のフィールドで使用されているユニットを確認する必要がある。 該当なし こちらのデータベース クエリをお試しください。
データベース設定の現在の値を確認する必要がある。 該当なし こちらのデータベース クエリをお試しください。
ブロックされたバックグラウンド プロセスを停止する必要がある。 ユーザーには pg_signal_backend のロールが必要です。 ロールを付与し、これらのコマンドを発行します。
インスタンスによるトランザクション ID の消費量が 100% に近づいている。 autovacuum ジョブがブロックされるか、ワークロードの速度に対応できる速さでトランザクション ID が再利用されていない可能性があります。 セルフサービスのヒントをご覧ください。
一時ストレージにより、自動ストレージが増加した。 自動ストレージが有効になっています。 再起動すると一時ファイルは削除されますが、保存容量は減りません。インスタンスのサイズをリセットできるのはカスタマー サポートのみです。詳細については、こちらをご覧ください。
データが自動的に削除される。 どこかでこれを行うスクリプトが実行されています。 スクリプトの検索を試してください。
インスタンスを削除できない。 複数の根本原因が存在している可能性があります。 複数のソリューションが存在している可能性があります。
一時的なデータサイズが大きいためにインスタンスが停止する。 一度に作成された一時テーブルが多すぎます。 インスタンスを再起動し、この緩和策オプションをお試しください。
アップグレード中の致命的なエラー。 さまざまな原因が考えられます。 ログに詳細情報が表示される場合があります。強制的に再起動するには、カスタマー サポートにお問い合わせください。
ディスク容量が不足した後、再起動時にインスタンスが停止する。 自動ストレージ増加機能が有効になっていません。 ストレージの自動増量を有効にします
オンプレミスのプライマリ インスタンスが停止する。 該当なし Cloud SQL のカスタマー サポートは、Cloud SQL に含まれていないインスタンスをサポートできません
再起動時のシャットダウンが遅い。 60 秒後に終了してない未処理の接続によって、クリーンでないシャットダウンが発生する可能性があります。 接続時間が 60 秒未満の場合のみ
Access denied for user ユーザー認証、または期限切れの SSL / TLS 証明書。 ユーザーと証明書のステータスを確認します。
ユーザーを削除できない。 ユーザーがデータベース内のオブジェクトを所有している可能性があります。 オブジェクトの削除または再割り当てが必要となる可能性があります。
共有 VPC の既存のインスタンスにプライベート IP アドレスを割り当てることができない。 インスタンスのアドレスは、作成時にプロジェクトに関連付けられます。 新しい Cloud SQL インスタンスを作成して、既存のインスタンスを置き換えます。
特定のクエリの実行が遅い。 データベースに固有の問題またはネットワーク レイテンシ。 おすすめの方法をご覧ください。
メモリ不足が示されているが、モニタリング グラフに表示されない。 一部の RAM が内部オーバーヘッド プロセスで使用されている可能性があります。 インスタンスに、ワークロードの十分なオーバーヘッドがあることを確認してください。
削除したインスタンスを復元する。 インスタンスを削除すると、バックアップを含め、そのインスタンスのすべてのデータが完全に失われます。 Cloud Storage にエクスポートして、データ損失を防ぎます。
ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ... ユーザーは、この操作に必要なすべての権限を持っていません。 ログインと実行するコマンドの詳細については、こちらをご覧ください。
既存の Cloud SQL インスタンスの名前を変更したい場合。 既存のインスタンス名の変更はサポートされていません。 新しいインスタンスを作成して既存のインスタンス名を変更する方法がいくつかあります。
Metadata table locked 別のクエリ、プロセス、またはトランザクションがクエリをブロックし、テーブルをロックしています。 ブロック プロセスを見つけて強制終了し、インスタンスを再起動します。

MySQL 再起動後のパフォーマンス低下

再起動後のパフォーマンス低下。

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

Cloud SQL では、InnoDB バッファプールにデータをキャッシュできます。ただし、再起動後に InnoDB キャッシュが空になるため、すべての読み取りでデータを取得するためにバックエンドへのラウンド トリップが必要になります。その結果、キャッシュがいっぱいになるまで、クエリが想定よりも遅くなる可能性があります。

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

なし


クラッシュの復旧が遅い

クラッシュの復旧が遅くなります。

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

大量の general_log が蓄積している可能性があります。

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

大量の general_log が累積しないようにすることで、クラッシュの復旧時間を短縮できます。general_log がオンになっている場合は、テーブルを切り捨てて、general_log を短時間だけ有効にします。

一般ログのサイズを確認するには、データベースに接続して次のクエリを実行します。SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;


ストレージの使用状況を確認する必要がある

ストレージの使用状況を確認する必要があります。たとえば、データベースで使用されているのは 3 GB のみであるが、ストレージでは 14 GB が使用されていると表示される場合があります。

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

テーブルで使用されない領域のほとんどが、バイナリログや一時ファイルで使用されています。

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

  • MySQL コマンドライン インターフェースで次のコマンドを使用して、バイナリログが占めるストレージを確認できます。 SHOW BINARY LOGS;
  • 一時テーブルも、かなり多くのストレージ容量を占有している場合があります。一時領域の使用量を確認するには、次のコマンドを使用します。SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G
  • 次のコマンドを使用すると、REDO ログのサイズを確認できます。SHOW VARIABLES LIKE 'innodb_log_file%';
  • general_log が有効になっている場合は、次のコマンドを使用してサイズを確認できます。SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
  • 必要に応じて、API を使用してログテーブルを切り捨てることができます。詳しくは、instances.truncateLog のリファレンス ページをご覧ください。
  • 遅いクエリのログの設定構成について学習します。

クエリがブロックされる

クエリが MySQL データベースをロックして、後続のすべてのクエリでブロック / タイムアウトが発生する可能性があります。

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

1 つのプロセスが他のすべてをブロックしています。

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

データベースに接続し、クエリ SHOW PROCESSLIST を実行します。リストの最初の項目が、後続の項目が待機しているロックを保持している場合があります。

SHOW INNODB STATUS クエリも役立ちます。


バイナリログを手動で削除できない

バイナリログを手動で削除できません。

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

バイナリログは手動で削除できません。

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

バイナリログは、関連する自動バックアップによって自動的に削除されます。これは通常、約 7 日後に発生します。


一時ファイルに関する情報を確認する必要がある

一時ファイルに関する情報を確認する必要があります。

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

ibtmp1 という名前のファイルが一時データの保存に使用されます。このファイルはデータベースの再起動時にリセットされます。

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

一時ファイルの使用状況に関する情報を確認するには、データベースに接続して次のクエリを実行します。

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G


テーブルサイズについて確認する必要がある

データベース内のテーブルサイズを確認する必要があります。

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

この情報はデータベースから入手できます。

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

データベースに接続して、次のクエリを実行します。

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;


mysqld が signal 11 を受け取った

次のエラーが発生します。

mysqld got signal 11

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

クエリが作成する接続が多すぎるため、インスタンスがクラッシュした可能性があります。

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

クエリをリファクタリングして、多すぎる接続が作成されないようにします。


InnoDB: page_cleaner

サーバーが停止し、次のようなエラーが表示されます。InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal

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

ページ クリーナーがインスタンスの変化率に追いつきません。ページ クリーナーは 1 秒おきにバッファプールをスキャンし、ダーティページをバッファプールからディスクにフラッシュします。表示される警告は、フラッシュするダーティページが多数あり、これらのバッチをディスクにフラッシュするのに 1 秒以上かかっていることを示しています。

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

可能であれば、インスタンスをシャーディングします。大きな Cloud SQL インスタンスを 1 つ使用するより、小さなインスタンスを多数使用することをおすすめします。


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

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';
      
      

インスタンスによるトランザクション 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. 別のオペレーションが進行中です。
  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 以外から接続している。
  • ユーザーが、接続しようとしているデータベースに対する適切な権限を持っていない。

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

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

ユーザーを削除できない

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

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

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

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

ユーザーに依存しているオブジェクトを特定し、それらのオブジェクトをドロップするか、別のユーザーに再度割り当てます。


共有 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 管理者のロールには、インスタンスを削除する権限が含まれています。誤って削除されないように、このロールは必要な場合にのみ付与してください。


エラー 1142(42000): ユーザー 'root'@'%' のコマンドがテーブルで拒否されました

MySQL 5.7 を使用している場合、選択レベルが複数あるビューを作成するときに ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ''" が発生することがあります。

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

ユーザーは、この操作に必要なすべての権限を持っていません。

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

  1. データベースに接続(Cloud Shell などを使用)して root としてログインします。
  2. USE mysql; を実行します。
  3. 次の付与を行います。
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE ON . TO 'root' WITH GRANT OPTION;
    
  4. USE 'Database_Name'; を実行します。ここで、Database_Name はビューを作成するデータベースです。
  5. セッション内のすべての作成ビューを実行して commit します。

既存の Cloud SQL インスタンスの名前を変更したい場合

ビジネス上などの理由で、既存の Cloud SQL インスタンスの名前を変更する必要がある場合。

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

Google Cloud Console で、または API を使用してインスタンス名を変更することはサポートされていません。

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

新しいインスタンスを作成することにより、既存のインスタンス名を変更できます。

  1. 名前を変更するインスタンスのクローンを作成し、クローンを作成したインスタンスに新しい名前を設定できます。これにより、手動でデータをインポートしなくても、新しいインスタンスを作成できます。新しいインスタンスを作成する場合と同様に、クローンを作成したインスタンスにも新しい IP アドレスが割り当てられます。

  2. インスタンスから Cloud Storage バケットにデータをエクスポートし、必要な名前で新しいインスタンスを作成してから、データを新しいインスタンスにインポートできます。

いずれの場合も、オペレーションの完了後に古いインスタンスを削除できます。パフォーマンスには影響がなく、インスタンスの構成設定(フラグ、マシンタイプ、ストレージ サイズ、メモリなど)を再度行う必要がないことから、クローンルートを使用することをおすすめします。


メタデータ テーブルがロックされている

データベースに対してクエリ(例: ALTER TABLE)を実行したところ、メタデータ テーブルがロックされているというエラー メッセージが表示されました。データベースはクエリを完了できず、それ以上のアクティビティに応答しなくなります。

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

別のクエリ、トランザクション、またはプロセスがクエリをブロックし、メタデータ テーブルをロックしています。

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

テーブルをロックしたプロセスを見つけて強制終了します。

  • sql> show processlist; で診断します。リストの最初の項目が、後続の項目が待機しているロックを保持している可能性があります。
  • SHOW INNODB STATUS コマンドも有用です。
  • KILL <PID>;

レプリケーション

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


ディスクに空きがない

UPDATE_DISK_SIZE エラーまたは mysqld: disk is full エラー。

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。

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

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

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