問題の診断

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

ログを表示

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

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

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

接続の問題

接続の問題については、接続の問題のデバッグページまたはトラブルシューティング ページの接続セクションをご覧ください。

インスタンスの問題

バックアップ

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

その他のバックアップの問題については、トラブルシューティング ページのバックアップ セクションをご覧ください。

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

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

処理対象のデータのサイズによっては、Cloud SQL へのインポートと Cloud SQL からのエクスポートに長時間を要する可能性があります。その結果、以下の影響が生じることが考えられます。

• 長時間実行されている 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 ストレージ エンジンを使用してテーブルが作成されます。

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

mysql.user や mysql.db など mysql データベースのすべてのテーブルを含め、MySQL のシステム テーブルには、MyISAM ストレージ エンジンが使用されます。これらのテーブルは、クリーンではないシャットダウンに対して脆弱です。これらのテーブルを変更した後は、FLUSH CHANGES コマンドを発行します。MyISAM の破損が発生した場合は、CHECK TABLE と REPAIR 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 Platform Console の [お支払い] ページでプロジェクトを選択し、プロジェクトに使用されている請求先アカウント情報を表示します。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻ります。

• Cloud Key Management Service での鍵の問題

  たとえば、Cloud SQL インスタンスのユーザーデータを暗号化するために使用された Cloud KMS の鍵バージョンが存在しない場合、鍵へのアクセスが取り消された場合、鍵が無効化または削除された場合などです。詳細については、顧客管理の暗号鍵（CMEK）の使用をご覧ください。

• 法的な問題

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

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

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

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

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

パフォーマンス

概要

Cloud SQL は、高いパフォーマンスが要求されるワークロードをサポートします。最大 IOPS は 60,000 で、I/O に追加料金はかかりません。IOPS とスループット パフォーマンスは、ディスクサイズ、インスタンスの vCPU 数、I/O ブロックサイズなどの要因によって異なります。

インスタンスのパフォーマンスは、ストレージの種類とワークロードによっても変化します。

以下について学習します。

• 永続ディスクとパフォーマンス。
• パフォーマンスとスロットリングの指標。
• ディスク パフォーマンスの最適化。
• パフォーマンスに影響するその他の要因。

クエリログを有効にする

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

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

Cloud Logging と Monitoring を使用して Cloud SQL for MySQL の低速なクエリのロギングとモニタリングを行う手順については、こちらのチュートリアルをご覧ください。

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

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

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

SHOW ENGINE INNODB STATUS\G

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

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

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

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

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

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

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

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

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

• 読み取りのパフォーマンスにはキャッシュが重要です。データセットのサイズと、インスタンスの RAM のサイズを比較してください。データセット全体がインスタンスの RAM の 70% に収まるのが理想的です。この状態であれば、クエリが IO パフォーマンスに制約されることはありません。そうでない場合は、インスタンスの RAM のサイズを増やすことを検討してください。
• ワークロードが CPU を大量に使用するクエリ（並べ替え、正規表現、その他の複雑な関数）で構成されている場合、インスタンスが制限される可能性があります。その場合には、vCPU を追加します。

クエリ実行のパフォーマンスが低い場合は、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 の使用量を減らします。

トラブルシューティング

Cloud SQL に関するほかの問題については、トラブルシューティング ページをご覧ください。

エラー メッセージ

特定の API エラー メッセージについては、エラー メッセージのリファレンス ページをご覧ください。

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

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

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

再暗号化のトラブルシューティングの表