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

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

ログの表示

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

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

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

接続の問題

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

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

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

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

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

第 1 世代のインスタンスの場合は、[接続] ページに表示されるクライアント証明書の有効期限も確認する必要があります。期限切れの場合は、SSL を使用してインスタンスに接続する前に、新しいクライアント証明書を作成する必要があります。

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

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

  • App Engine のスタンダード環境から第 1 世代インスタンスに接続する場合、App Engine アプリケーションに Cloud SQL インスタンスへの接続が承認されていることを確認します。
  • IP アドレスで接続できない場合(たとえば、MySQL クライアントを使用してオンプレミス環境から接続している場合)、接続元の IP アドレスに Cloud SQL インスタンスへの接続が承認されていることを確認します。こちらが現在の IP アドレスです。
  • gcloud sql connect を使用してインスタンスに接続してみます。このコマンドは現在の IP アドレスを短時間だけ承認します。この方法は、Cloud SDK と MySQL クライアントがインストールされている環境で実行できます。このコマンドは Cloud Shell でも実行できます。Cloud Shell は Google Cloud Platform Console で使用でき、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 からの接続は、通常、App Engine から第 1 世代インスタンスに接続されますが、このパスは、一部の内部 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 インスタンスと Cloud SQL インスタンスの間の接続に長期間使用されない接続が含まれると予想される場合は、Compute Engine インスタンスとの接続はアクティブでない状態が 10 分間続くとタイムアウトすることに注意する必要があります。詳細については、Compute Engine のドキュメントのネットワークとファイアウォールをご覧ください。

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

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

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

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

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

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 を使用できません。これを解決するには、Cloud SQL インスタンスの IPv4 アドレスに接続する必要があります。先に、IPv4 アドレスをインスタンスに追加することが必要な場合があります。

接続のタイムアウト

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

インスタンスの問題

バックアップ

10,000 個より多くのデータベース テーブルがある場合、第 1 世代インスタンスのバックアップが失敗する可能性があります。最高のパフォーマンスを実現するには、テーブルの数が多くなりすぎないようにしてください。

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

Cloud SQL でのインポートとエクスポートは mysqldump ユーティリティを使用する場合と同じですが、Cloud SQL のインポート / エクスポート機能では Cloud Storage バケットを使用してデータを転送する点だけが異なります。1 つのデータベース、インスタンスのすべてのデータベース、選択したデータ(CSV 形式)を、インポートおよびエクスポートできます。

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

  • 第 1 世代インスタンスでは、オペレーションが 24 時間以内に制限されます。
  • 長時間実行オペレーションを停止することはできません。

さらに、各インスタンスに対して実行できるインポートまたはエクスポート オペレーションは、一度に 1 つのみです。

次のいずれかの方法によって、1 つのオペレーションにかかる時間を短縮できます。

  • データのバッチサイズを小さくして、Cloud SQL のインポートまたはエクスポート機能を使用します。これにより 24 時間以内に完了できるようになります。

  • Cloud SQL のインポート機能やエクスポート機能を使用しないで、代わりにダンプファイルを Cloud SQL に直接リプレイします。たとえば、cloudsql-import を使用すると、mysqldump ファイルを MySQL 接続を介してリプレイすることにより、インポートを実施できます。cloudsql-import は、接続エラーやインスタンスの再起動が発生した場合でも復元可能です。

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

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

ディスク容量

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

データの破損を回避する

生成列を回避する

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

クリーン シャットダウン

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

データベース エンジン

InnoDB は、第 2 世代インスタンス用としてサポートされている唯一のストレージ エンジンで、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)

第 2 世代インスタンスはいずれも、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 Platform Console の [お支払い] ページでプロジェクトを選択し、プロジェクトに使用されている請求先アカウント情報を表示します。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻るはずです。

  • 法的な問題

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

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

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

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

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

パフォーマンス

クエリログを有効にする

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

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

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

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

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

SHOW ENGINE INNODB STATUS\G

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

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

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

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

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

  • 第 1 世代のインスタンスでは、SQL オペレーションで使用される一時領域に 10 GB の制限があります。一部のオペレーション(GROUP BY での大規模な集約など)は、この制限によって影響を受けることがあります。場合によっては、クエリの作成方法を変えたり、異なる SQL 構文を使用することによって、一時領域の制限に達するのを回避できます。第 2 世代のインスタンスにはこの制限はありません。
  • マシンタイプの規模がワークロードに対して十分大きいことを確認します。

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

  • 第 1 世代インスタンスの場合、ファイル システムのレプリケーションの非同期モード(インスタンスの設定)は、同期モードよりはるかに速くなります。同期モードを使用していて、アプリケーションがある程度のデータリスクに耐えられる場合は、非同期モードに切り替える必要があります。
  • 書き込みとデータベースの場所を確認します。データの送信距離が長いと、レイテンシが発生します。

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

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

クエリ実行のパフォーマンスが低い場合は、EXPLAIN を使用して、以下の対処が可能な場所を特定します。

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

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

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

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

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

このページは役立ちましたか?評価をお願いいたします。

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