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

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

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

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

特定のエラー メッセージに関する情報については、 エラー メッセージのページをご覧ください。

バックアップと復元

問題 トラブルシューティング
現在のオペレーションのステータスを確認できない。 Google Cloud Console では、オペレーションの完了時に成功または失敗のみが表示されます。警告やその他の情報を表示するように設計されていません。

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

オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 オペレーションを開始したユーザーはユーザー インターフェースに表示されません。

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

  • Cloud Audit Logs が有効で、表示に必要な権限がある場合は、cloudaudit.googleapis.com/activity を使用できる場合があります。
インスタンスの削除後にバックアップを実行できない。 Cloud SQL インスタンスの削除の猶予期間は 4 日間です。この間であれば、カスタマー サポートがインスタンスを再作成できます。インスタンスの削除後にデータを復元することはできません。

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

自動バックアップが長時間停止していて、キャンセルできない。 データベースのサイズによっては、バックアップに時間がかかる可能性があります。

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

SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。

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

自動バックアップの保持日数を 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 backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    
インスタンスがエラー状態とバックアップ復元状態の間でループしているため、インスタンスが繰り返し失敗する。復元後にデータベースに接続して使用しようとすると失敗する。
  • オープン接続が多すぎる可能性があります。接続数が多すぎる原因として、切断された接続をクリーンアップする autovacuum 設定が存在しないために接続の途中でエラーが発生していることが考えられます。
  • カスタムコードで数回エラーが起きても停止しない再試行ロジックが使用されているため、ループが発生している可能性があります。
  • トラフィックが多すぎる可能性があります。接続プーリングなどの接続のベスト プラクティスを使用します。

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

  1. データベースが autovacuum を使用する設定になっていることを確認します。
  2. カスタムコードに接続再試行ロジックが設定されているかを確認します。
  3. データベースが復旧するまでトラフィックを減らし、復旧後に徐々にトラフィックを増やします。
バックアップ / 復元オペレーションを実行したときにデータの欠落が見つかることがあります。 テーブルがログに記録されずに作成されました。次に例を示します。

CREATE UNLOGGED TABLE ...

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

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

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

クローンの作成

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

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

接続

問題 トラブルシューティング
Aborted connection. 次のような問題が考えられます。
  • ネットワークが不安定。
  • TCP keep-alive コマンドに応答しない(クライアントまたはサーバーのいずれかが応答しないか、過負荷の可能性があります)。
  • データベース エンジン接続の存続期間を超えたため、サーバーが接続を終了している。

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

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

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

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

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 範囲のサイズが /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
    

エクスポート

問題 トラブルシューティング
CSV のエクスポートは機能したが、SQL エクスポートに失敗した。 CSV 形式と SQL 形式ではエクスポート方法が異なります。SQL 形式ではデータベース全体がエクスポートされるため、完了までに時間がかかります。CSV 形式ではエクスポートに含めるデータベースの要素を定義できます。

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

エクスポートに時間がかかりすぎる。 Cloud SQL では同時実行オペレーションの同期がサポートされません。

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

拡張機能の作成のエラー。 ダンプファイルに、サポートされていない拡張機能への参照が含まれています。

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

pg_dumpall の使用中にエラーが発生した。 このツールにはスーパーユーザーのロールが必要ですが、スーパーユーザーのロールは Cloud SQL でサポートされていません。
エクスポートが完了する前にオペレーションがタイムアウトすると、Could not receive data from client: Connection reset by peer. というエラー メッセージが表示されます。 Cloud Storage が所定の時間(通常は約 7 分)内にデータを受信しないと、接続はリセットされます。最初のエクスポート クエリは、非常に時間がかかる可能性があります。

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

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

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

外部プライマリ

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

問題 トラブルシューティング
Lost connection to MySQL server during query when dumping table. ソースが使用不能か、ダンプに含まれているパケットが大きすぎる可能性があります。

外部プライマリが接続可能な状態にします。または、max_allowed_packet オプションを指定して mysqldump を使用します。

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

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

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

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

最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。 次の方法をお試しください。

  • Google Cloud Console の [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
mysqld check failed: data disk is full. レプリカ インスタンスのデータディスクに空き容量がありません。

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

外部レプリカ

問題 トラブルシューティング
エラー メッセージ: 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 バケットにアップロードし、ダンプファイルを使用してレプリカを構成します。

フラグ

問題 トラブルシューティング
フラグを有効にすると、インスタンスがパッキングとクラッシュの間でループする。 カスタマー サポートに連絡して、フラグの削除をリクエストしてから hard drain を送信します。これにより、不必要なフラグや設定を使用せずに、新しい構成を使用して別のホストでインスタンスが再起動します。
フラグを設定しようとすると、エラー メッセージ Bad syntax for dict arg が表示されます。カンマ区切りリストなどの複雑なパラメータ値を gcloud コマンドで使用する場合は、特別な処理が必要です。
タイムゾーンを設定するフラグがない。 Cloud SQL がサポートする PostgreSQL と SQL Server では、ユーザーが必要に応じてタイムゾーンを調整できるタイムゾーン フラグがありません。

いくつかの回避策があります。

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


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

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

高可用性

問題 トラブルシューティング
手動フェイルオーバーの指標が表示されない。 自動フェイルオーバーの指標のみが表示されます。
Cloud SQL インスタンス リソース(CPU と RAM)の使用率が 100% に近いため、高可用性インスタンスが停止する。 インスタンスのマシンサイズが負荷に対して小さすぎます。

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

インポート

問題 トラブルシューティング
インポート オペレーションに時間がかかりすぎる。 アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。

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

再起動により、次の処理が行われます。

  • すべての接続を終了します。
  • リソースを消費している可能性のあるタスクをすべて終了します。
ダンプファイルで参照しているユーザーが存在しない場合、インポート オペレーションが失敗することがある。 ダンプファイルをインポートする前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーがターゲット データベース内に存在している必要があります。そうでない場合、インポート オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。

インポートする前に、データベース ユーザーを作成します。

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

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

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


SET FOREIGN_KEY_CHECKS=0;
  

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


SET FOREIGN_KEY_CHECKS=1;
  

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

ロギング

問題 トラブルシューティング
ロギングで Cloud SQL インスタンスの CPU とメモリが大量に使用されている。 ロギングを調整する必要があります。

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

監査ログが見つからない。 オペレーションが、ユーザー作成データを作成、変更、または読み取る認証済みのユーザー ドリブン API 呼び出しの場合、またはリソースの構成ファイルまたはメタデータにアクセスした場合にのみ、データアクセス ログに書き込まれます。
ログにオペレーション情報が見つからない。 オペレーションの詳細を確認したい場合があります。

たとえば、ユーザーが削除され、誰がその操作を行ったのかを確認できない場合があります。ログでは、オペレーションが開始したことは確認できますが、それ以上の情報は記録されません。このような詳細な個人情報(PII)を記録するには、監査ログを有効にする必要があります。

ロギングで大量のディスク容量を使用している。 ディスク容量を使用するログファイルには、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;
    
ログファイルが読みにくい。 ログを 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 text \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
> downloaded-log.txt
   
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
         

インスタンスの管理

問題 トラブルシューティング
MySQL 再起動後のパフォーマンスが低下する。 Cloud SQL では、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 データベースをロックして、後続のすべてのクエリでブロック / タイムアウトが発生する可能性があります。

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

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 を受け取った。 クエリが作成する接続が多すぎるため、インスタンスがクラッシュした可能性があります。

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

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

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

実行中のクエリを調べたい。 データベースに接続して次のクエリを実行します。

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 である可能性があります。

たとえば、次のような原因が考えられます。

  • 別のオペレーションが進行中です。Cloud SQL オペレーションは同時には実行されません。他のオペレーションが完了するのをお待ちください。
  • INSTANCE_RISKY_FLAG_CONFIG 警告は、少なくとも 1 つの beta フラグが使用されるたびにトリガーされます。危険なフラグ設定を削除して、インスタンスを再起動します。
一時的なデータサイズが大きいためにインスタンスが停止する。 クエリと負荷に応じて、一度に多くの一時テーブルが作成される場合があります。

サービスを再起動する以外の方法で ibtmp1 ファイルのサイズを小さくすることはできません。

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

アップグレード中の致命的なエラー。 ログに詳細が表示される場合がありますが、インスタンスを強制的に再作成するにはカスタマー サポートが必要になる場合があります。
ディスク容量が不足した後、再起動時にインスタンスが停止する。 自動ストレージ増加機能が有効になっていません。

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

オンプレミスのプライマリ インスタンスが停止する。 Google Cloud では、Cloud SQL に含まれていないインスタンスはサポートされません。
再起動時のシャットダウンが遅い。 インスタンスをシャットダウンしたときに、60 秒以内に終了しない未処理の接続があると、不完全なシャットダウンが発生します。

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

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

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

特定のクエリの実行が遅い。 クエリが遅くなる理由はさまざまですが、その多くはデータベース側の問題です。Cloud SQL でネットワーク レイテンシが問題になるのは、ソース(ライターまたはリーダー)リソースと宛先(Cloud SQL)リソースが異なるリージョンに存在している場合です。

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

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

  • 書き込みとデータベースの場所を確認します。データの送信距離が長いと、レイテンシが発生します。
  • 読み取りとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスより読み取りパフォーマンスに大きく影響します。

レイテンシを低減するために、ソースリソースと宛先リソースの両方を同じリージョンに配置することをおすすめします。

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

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

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

削除したインスタンスを復元する。 インスタンスを削除すると、バックアップを含め、そのインスタンスのすべてのデータが完全に失われます。

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

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

既存の Cloud SQL インスタンスの名前を変更したい。 既存のインスタンス名の変更はサポートされていません。

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

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

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

レプリケーション

問題 トラブルシューティング
リードレプリカの作成時にレプリケーションが開始されなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。
リードレプリカを作成できない - invalidFlagValue エラー。 リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

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

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

リードレプリカを作成できない - 不明なエラー。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。

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

ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

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

レプリケーションが停止した。 ストレージの上限に達しており、ストレージの自動増量が有効になっていません。

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

レプリケーション ラグが常に大きい。 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

考えられる解決策は次のとおりです。

  • インスタンスを編集してレプリカのサイズを増やします。
  • データベースの負荷を軽減します。
  • テーブルをインデックスに登録します。
  • 遅いクエリを特定して修正します。
  • レプリカを再作成します。
レプリカの作成がタイムアウトで失敗する。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

実行中のクエリをすべて停止してからレプリカを再作成します。