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

このページでは、Cloud SQL インスタンスの使用中に特に頻繁に発生する可能性のある問題と、その問題に対処するための手順について説明します。既知の問題ページ、トラブルシューティングサポートページもご覧ください。

ログの表示

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

インスタンスが応答しない

インスタンスが接続への応答を停止したか、パフォーマンスが低下した場合は、オペレーション ガイドラインを遵守していることを確認してください。オペレーション ガイドラインを遵守していない場合は、Cloud SQL SLA の対象外です。

接続の問題

アプリケーションが接続を正しく終了していることを確認する

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

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

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

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

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

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

  • IP アドレスで接続できない場合(たとえば、MySQL クライアントを使用してオンプレミス環境から接続している場合)、接続元の IP アドレスに Cloud SQL インスタンスへの接続が承認されていることを確認します。

    プライベート IP アドレスを使用して Cloud SQL インスタンスへ接続すると、RFC 1918 アドレス範囲が自動的に承認されます。これにより、すべてのプライベート クライアントがプロキシを経由せずにデータベースにアクセスできます。RFC 1918 以外のアドレス範囲は、承認済みネットワークとして構成する必要があります。

    Cloud SQL は、デフォルトでは VPC から RFC 1918 以外のサブネット ルートを学習しません。RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワーク ピアリングを更新する必要があります。次に例を示します。

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

  • こちらが現在の IP アドレスです。

  • gcloud sql connect コマンドでインスタンスに接続してみます。このコマンドは現在の IP アドレスを短時間だけ認可します。このコマンドは、Cloud SDK と MySQL クライアントがインストールされている環境で実行できます。このコマンドは Cloud Shell でも実行できます。Google Cloud Console で使用できる Cloud Shell には、Cloud SDK と MySQL クライアントがプリインストールされています。Cloud Shell で提供される Compute Engine インスタンスを使用して、Cloud SQL に接続できます。
  • 一時的に、すべての IP アドレスにインスタンスへの接続を許可します。IPv4 については、0.0.0.0/0 を認可します(IPv6 については、::/0 を認可します)。

接続方法を確認する

接続時に次のようなエラー メッセージが表示される場合:

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)

パスワードを提供していることを確認します。

接続時に次のようなエラー メッセージが表示される場合:

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)

正しいパスワードを使用していること、およびインスタンスで要求されている場合は SSL で接続していることを確認します。

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

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

SHOW PROCESSLIST;

接続に 1.2.3.4 のような IP アドレスが示されている場合、その接続では IP が使用されています。cloudsqlproxy~1.2.3.4 が示されている接続の場合は、Cloud SQL Proxy が使用されているか、App Engine から発信されています。localhost からの接続は、一部の内部 Cloud SQL プロセスで使用できます。

接続制限を確認する

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

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

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

「接続が多すぎる」というエラー メッセージが表示される場合、またはインスタンスで起きていることを確認する必要がある場合は、SHOW PROCESSLIST を使用して接続数とスレッド数を表示できます。

MySQL クライアントから、次のように実行します。

mysql> SHOW PROCESSLIST;

出力は次のようになります。

+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| Id | User      | Host         | db        | Command | Time | State | Info                 |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
|  3 | user-name | client-IP    | NULL      | Query   |    0 | NULL  | SHOW processlist     |
|  5 | user-name | client-IP    | guestbook | Sleep   |    1 |       | SELECT * from titles |
| 17 | user-name | client-IP    | employees | Query   |    0 | NULL  | SHOW processlist     |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
3 rows in set (0.09 sec)

PROCESSLIST から返される列の解釈方法については、MySQL リファレンスをご覧ください。

スレッド数を取得するには、次のコマンドを使用します。

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';

出力は次のようになります。

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Compute Engine からの接続

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

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

現在の tcp_keepalive_time の値を表示します。

cat /proc/sys/net/ipv4/tcp_keepalive_time

tcp_keepalive_time を 60 秒に設定し、再起動しても変わらないようにします。

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

変更を適用します。

sudo /sbin/sysctl --load=/etc/sysctl.conf

tcp_keepalive_time の値を表示して、変更が適用されたことを確認します。

cat /proc/sys/net/ipv4/tcp_keepalive_time

IPv6 との接続

接続時に次のようなエラー メッセージが表示される場合があります。

Can't connect to MySQL server on '2001:1234::4321' (10051)
Can't connect to MySQL server on '2001:1234::4321' (101)

このような場合は、インスタンスの IPv6 アドレスに接続を試みているのに、ワークステーションでは IPv6 を使用できない可能性があります。ワークステーションで IPv6 を使用できるかどうかを確認するには、ipv6.google.com にアクセスします。このサイトを読み込めない場合は、IPv6 を使用できません。この場合は IPv4 アドレスまたは Cloud SQL インスタンスに接続します。先に、IPv4 アドレスをインスタンスに追加することが必要な場合があります。

接続のタイムアウト

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

ときどき発生する接続障害

メンテナンス イベントによって Cloud SQL でインスタンスが再起動されると、接続はフェイルオーバー レプリカにルーティングされる可能性があります。フェイルオーバー レプリカに接続すると、次のようになります。

  • 暗号化されていない接続を使用したクライアントからの読み取りリクエストは、通常どおり成功します。ただし、書き込みリクエストは失敗し、「Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement」(エラー 1290: MySQL サーバーは読み取り専用オプションで実行しているので、このステートメントを実行できません)などのエラー メッセージが返されます。

  • 暗号化された接続を使用したクライアントからの読み取りと書き込みのリクエストは失敗し、「x509: certificate is valid for master-instance, not failover-instance」(x509: 証明書はフェイルオーバー インスタンスではなく、マスター インスタンスに対して有効です)などのエラー メッセージが返されます。

イベントが終了すると、Cloud SQL によって接続はリセットされます。接続を再試行します。アプリケーションを設計するとき、ときどき発生する接続障害を処理するために指数バックオフのようなエラー処理方法を実装することをおすすめします。詳細については、アプリケーションの実装をご覧ください。

インスタンスの問題

バックアップ

バックアップのパフォーマンスを最適化するには、テーブル数を合理的な数に維持します。

インポートとエクスポート

Cloud SQL でのインポートとエクスポートmysqldump ユーティリティを使用する場合と同じですが、Cloud SQL のインポート / エクスポート機能では Cloud Storage バケットを使用してデータを転送する点だけが異なります。

インポート機能(Cloud Storage バケット経由)を使用した Cloud SQL へのインポートとエクスポートは、データベースのサイズによっては、完了するまでに時間がかかる場合があります。その結果、次の影響があります。

  • 長時間実行オペレーションを停止することはできません。
  • 各インスタンスに対して実行できるインポートまたはエクスポート オペレーションは、一度に 1 つのみです。

Cloud SQL のインポートまたはエクスポート機能をバッチサイズのより小さいデータで使用して、各オペレーションの完了に要する時間を短縮できます。

エクスポートの場合、サーバーレス エクスポートを使用すると、データベースのパフォーマンスへの影響を最小限に抑え、エクスポートの実行中にインスタンスで他のオペレーションを実行できます。

インポート時に留意する必要があるその他のポイント:

  • インポートがクラッシュした場合は、メモリ不足(OOM)エラーが原因の可能性があります。その場合は、MySQL コマンドを直接使用して --extended-insert=FALSE --complete-insert パラメータを追加してみてください。これらのパラメータによってインポートの速度は低下しますが、インポートに必要なメモリ量も削減されます。

ディスク容量

インスタンスが許される最大ストレージ容量に達すると、データベースへの書き込みは失敗します。テーブルの削除などの方法でデータを削除した場合、解放された領域はインスタンスのストレージの使用量のレポートに反映されません。この動作についての説明は、破棄したテーブルから容量を回復する方法に関するよくある質問をご覧ください。

最大ストレージ容量の上限に達すると、インスタンスが再起動時に停止する場合があります。

データの破損を回避する

生成列を回避する

生成された列を使用すると、MySQL の問題によりデータが破損する場合があります。詳しくは、MySQL バグ #82736 をご覧ください。

クリーン シャットダウン

Cloud SQL がインスタンスをシャットダウンするとき(メンテナンスの場合など)、新しい接続はインスタンスに送信されず、既存の接続は終了します。mysqld がシャットダウンにかける時間は、1 分に制限されています。シャットダウンがこの時間内に完了しない場合、mysqld プロセスは強制的に停止されます。また、これに伴ってディスクの書き込みが中断されることがあります。

データベース エンジン

InnoDB は、MySQL インスタンス用としてサポートされている唯一のストレージ エンジンで、MyISAM などその他の MySQL ストレージ エンジンに比べてテーブルが破損しにくいのが特長です。

デフォルトでは、Cloud SQL データベース テーブルは、InnoDB ストレージ エンジンを使用して作成されます。CREATE TABLE 構文内の ENGINE オプションで InnoDB 以外のストレージ エンジンを指定すると(ENGINE = MyISAM など)、テーブルは作成されず、以下のようなエラー メッセージが表示されます。

ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).

このエラーは、CREATE TABLE コマンドで ENGINE = MyISAM オプションを削除すれば回避できます。またその場合には、InnoDB ストレージ エンジンを使用してテーブルが作成されます。

InnoDB はデータの整合性を確保する機能に優れているため、第 1 世代のインスタンスに対しては推奨されます。

システム テーブルに対する変更

mysql.usermysql.db など mysql データベースのすべてのテーブルを含め、MySQL のシステム テーブルには、MyISAM ストレージ エンジンが使用されます。これらのテーブルは、クリーンではないシャットダウンに対して脆弱です。これらのテーブルを変更した後は、FLUSH CHANGES コマンドを発行します。MyISAM の破損が発生した場合は、CHECK TABLEREPAIR TABLE を使って正常な状態に戻すことができます(ただし、データは保存されません)。

グローバル トランザクション識別子(GTID)

MySQL インスタンスはいずれも、GTID が自動で有効になります。GTID が有効になると、レプリカの作成中やフェイルオーバー中のデータ消失を防ぐことができるほか、レプリケーションもより強固なものになります。ただし、MySQL のマニュアルで説明されているように、GTID には MySQL に起因する制約がいくつかあります。GTID が有効になっている MySQL サーバーでは、トランザクション中の安全性が確保されない以下のようなオペレーションは実行できません。

  • CREATE TABLE ... SELECT ステートメント
  • トランザクション内の CREATE TEMPORARY TABLE ステートメント
  • トランザクション テーブルにもそれ以外のテーブルにも影響を与えるトランザクションまたはステートメント

トランザクション中の安全性が確保されないトランザクションを実行すると、次のようなエラーメッセージが表示されます。

 Exception: SQLSTATE[HY000]: General error: 1786
 CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.

トリガーとストアド ファンクションの操作

インスタンスでバイナリ ロギングが有効になっていて、トリガーやストアド ファンクションを操作する必要がある場合は、インスタンスの log_bin_trust_function_creators フラグが on に設定されていることを確認してください。

停止状態

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

  • 請求に関する問題

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

  • KMS 鍵に関する問題

    たとえば、Cloud SQL インスタンスのユーザーデータを暗号化するために使用される KMS 鍵バージョンが存在しない場合や、無効化または破棄された場合などです。顧客管理の暗号鍵(CMEK)を使用するをご覧ください。

  • 法的な問題

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

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

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

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

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

パフォーマンス

クエリログを有効にする

クエリのパフォーマンスを調整するには、インスタンスに --log_output='FILE'--slow_query_log=on というデータベース フラグを追加して、処理に時間がかかるクエリをログに記録するように Cloud SQL を構成します。これにより、Google Cloud Console のログビューアを使用してログを出力できます。Google Cloud のオペレーション スイートのロギング料金が適用されます。

log_output を TABLE に設定しないでください。このように設定すると、フラグの使用に関するヒントで説明するような接続の問題が発生する場合があります。

ロックのモニタリングを有効にする

InnoDB モニターは、InnoDB ストレージ エンジンの内部状態に関する情報を提供します。この情報を使用して、パフォーマンスを調整できます。

MySQL クライアントを使用してインスタンスにアクセスし、オンデマンドのモニター出力を取得します。

SHOW ENGINE INNODB STATUS\G

モニター出力のセクションの説明については、InnoDB の標準モニターとロックモニターの出力をご覧ください。

ファイルまたはテーブルに定期的に出力を生成するように InnoDB モニターを設定できますが、パフォーマンスは低下します。詳細については、InnoDB モニターの有効化をご覧ください。

パフォーマンス スキーマを使用する

MySQL パフォーマンス スキーマは、MySQL Server の実行を低レベルでモニタリングする機能です。performance_schema で生成された統計情報を利用する場合、MySQL Workbench パフォーマンス レポート機能を使用するのが最も簡単な方法です。

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

データベース テーブルはシステム リソースを消費します。数が多くなると、インスタンスのパフォーマンスと可用性に影響する可能性があります。また、インスタンスが SLA の対象外になる可能性もあります。詳細

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

  • マシンタイプの規模がワークロードに対して十分大きいことを確認します。

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

  • 書き込みとデータベースの場所を確認します。データの送信距離が長いと、レイテンシが発生します。

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

  • 読み取りのパフォーマンスにはキャッシュが重要です。データセットのサイズと、インスタンスの RAM のサイズを比較してください。データセット全体がインスタンスの RAM の 70% に収まるのが理想的です。この状態であれば、クエリが IO パフォーマンスに制約されることはありません。そうでない場合は、インスタンスの階層のサイズを増やすことを検討してください。
  • ワークロードが CPU を大量に使用するクエリ(並べ替え、正規表現、その他の複雑な関数)で構成されている場合、インスタンスが制限される可能性があります。その場合には、階層を追加します。
  • 読み取りとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスより読み取りパフォーマンスに大きく影響します。
  • 適切なインデックスの追加、スキャンするデータの削減、余分なラウンド トリップの回避など、Cloud SQL に固有ではないパフォーマンス向上手段を調査します。

クエリ実行のパフォーマンスが低い場合は、EXPLAIN を使用します。EXPLAIN は、SELECT などの他のステートメントに追加するステートメントであり、MySQL がステートメントを実行する方法に関する情報を返します。SELECT、DELETE、INSERT、REPLACE、UPDATE と連携して機能します。例: EXPLAIN SELECT * FROM myTable;

EXPLAIN を使用して、以下のことができる場所を特定します。

  • テーブルにインデックスを追加してクエリのパフォーマンスを向上させます。たとえば、JOIN キーとして使用するすべてのフィールドについて、両方のテーブルにインデックスを作成します。

  • ORDER BY オペレーションを改良します。EXPLAIN の出力の [Extra] 列に「Using temporary; Using filesort」と示されている場合、これは中間結果がファイルに格納されてから並べ替えられることを意味します。このような動作は、通常、パフォーマンス低下の原因になります。この場合は、次のいずれかを行います。

    • 可能であれば、並べ替えではなくインデックスを使用します。詳しくは、ORDER BY の最適化をご覧ください。

    • クエリ セッションの sort_buffer_size 変数のサイズを増やします。

    • 必要なだけの大きさの列を宣言することによって、行ごとの RAM の使用量を減らします。

顧客管理の暗号鍵(CMEK)

Cloud KMS エラーやロールまたは権限がないために、作成、クローン作成、更新などの Cloud SQL 管理者のオペレーションが失敗する場合があります。失敗の一般的な理由には、Cloud KMS 鍵バージョンがない、Cloud KMS 鍵バージョンが無効かまたは破棄されている、Cloud KMS 鍵バージョンにアクセスするための IAM 権限が不足している、Cloud KMS 鍵バージョンが Cloud SQL インスタンスと別のリージョンにあるなどがあります。一般的な問題を診断して解決するには、次のトラブルシューティングの表を使用しください。

顧客管理の暗号鍵のトラブルシューティングの表

エラー: 次のような問題が考えられます... 次のことを試します...
プロダクトごと、プロジェクトごとのサービス アカウントが見つかりません サービス アカウント名が正しくありません。 正しいユーザー プロジェクトのサービス アカウントが作成されていることを確認します。

[サービス アカウント] ページに移動

サービス アカウントへのアクセスを許可できません ユーザー アカウントに、この鍵バージョンへのアクセスを許可する権限がありません。 ユーザー アカウントまたはサービス アカウントで組織管理者のロールを追加してください。

IAM アカウントのページに移動

Cloud KMS 鍵バージョンが破棄されています 鍵バージョンが破棄されています。 鍵バージョンが破棄されている場合、データの暗号化や復号に使用できません。
Cloud KMS 鍵バージョンが無効です 鍵バージョンが無効です。 Cloud KMS 鍵バージョンを再度有効にします。

暗号鍵のページに移動

Cloud KMS 鍵を使用するための十分な権限がありません Cloud SQL インスタンスへのオペレーションの実行に使用しているユーザー アカウントまたはサービス アカウントに cloudkms.cryptoKeyEncrypterDecrypter のロールがないか、Cloud KMS 鍵バージョンが存在しません。 ユーザー アカウントまたはサービス アカウントに cloudkms.cryptoKeyEncrypterDecrypter のロールを追加します。

IAM アカウントのページに移動


アカウントにすでにロールがある場合は、鍵の作成を参照して、新しい鍵バージョンの作成方法を確認してください。注を参照。
Cloud KMS 鍵が見つかりません 鍵バージョンが存在しません。 新しい鍵バージョンを作成します。鍵の作成をご覧ください。 注を参照。
Cloud SQL インスタンスと Cloud KMS 鍵バージョンが異なるリージョンにあります Cloud KMS 鍵バージョンと Cloud SQL インスタンスは同じリージョン内にある必要があります。Cloud KMS 鍵バージョンがグローバル リージョンまたはマルチリージョンにある場合は機能しません。 インスタンスを作成するリージョンと同じリージョンに鍵バージョンを作成します。鍵の作成をご覧ください。注を参照。

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

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

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

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

再起動後にパフォーマンスが低下します。

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

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;

クエリがブロックされる

クエリが 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 つ使用するより、小さなインスタンスを多数使用することをおすすめします。


一時ストレージにより、自動ストレージが増加した

一時テーブルのストレージ使用量が増えたため、自動ストレージが増えました。

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

自動ストレージが有効になっています。

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

一時テーブルを削除するために再起動しても、自動的に増加するストレージ サイズは減少しません。


データが自動的に削除される

データが一定の間隔で自動的に削除されます。

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

ほとんどの場合、スクリプトが環境内のどこかで実行されています。

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

削除時刻の前後のログで、ダッシュボードや別の自動プロセスから不正なスクリプトが実行されていないかどうかを確認します。


インスタンスを削除できない

エラー メッセージ 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 のグラフにはメモリがまだ残っているように表示されます。

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

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

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

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