このページでは、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 コンソールの請求ページでプロジェクトを選択した後、プロジェクトに使用されている請求先アカウント情報を表示することによって確認できます。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻ります。
KMS 鍵に関する問題
たとえば、Cloud SQL インスタンスのユーザーデータを暗号化するために使用される 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 インスタンスと別のリージョンにあるなどがあります。一般的な問題を診断して解決するには、次のトラブルシューティングの表を使用しください。
顧客管理の暗号鍵のトラブルシューティングの表
| エラー: | 次のような問題が考えられます... | 次のことを試します... |
|---|---|---|
| プロダクトごと、プロジェクトごとのサービス アカウントが見つかりません | サービス アカウント名が正しくありません。 | 正しいユーザー プロジェクトのサービス アカウントが作成されていることを確認します。
|
| サービス アカウントへのアクセスを許可できません | ユーザー アカウントに、この鍵バージョンへのアクセスを許可する権限がありません。 | ユーザー アカウントまたはサービス アカウントで組織管理者のロールを追加してください。
|
| Cloud KMS 鍵バージョンが破棄されています | 鍵バージョンが破棄されています。 | 鍵バージョンが破棄されている場合、データの暗号化や復号に使用できません。 |
| Cloud KMS 鍵バージョンが無効です | 鍵バージョンが無効です。 | Cloud KMS 鍵バージョンを再度有効にします。
|
| Cloud KMS 鍵を使用するための十分な権限がありません | Cloud SQL インスタンスへのオペレーションの実行に使用しているユーザー アカウントまたはサービス アカウントに cloudkms.cryptoKeyEncrypterDecrypter のロールがないか、Cloud KMS 鍵バージョンが存在しません。 |
ユーザー アカウントまたはサービス アカウントに cloudkms.cryptoKeyEncrypterDecrypter のロールを追加します。
アカウントにすでにロールがある場合は、鍵の作成を参照して、新しい鍵バージョンの作成方法を確認してください。注を参照。 |
| Cloud KMS 鍵が見つかりません | 鍵バージョンが存在しません。 | 新しい鍵バージョンを作成します。鍵の作成をご覧ください。 注を参照。 |
| Cloud SQL インスタンスと Cloud KMS 鍵バージョンが異なるリージョンにあります | Cloud KMS 鍵バージョンと Cloud SQL インスタンスは同じリージョン内にある必要があります。Cloud KMS 鍵バージョンがグローバル リージョンまたはマルチリージョンにある場合は機能しません。 | インスタンスを作成するリージョンと同じリージョンに鍵バージョンを作成します。鍵の作成をご覧ください。注を参照。 |
再暗号化のトラブルシューティングの表
| エラー: | 次のような問題が考えられます... | 次のことを試します... |
|---|---|---|
| Cloud KMS 鍵にアクセスできないため、CMEK リソースの再暗号化に失敗しました。主キーのバージョンが有効で、権限が正しく付与されていることを確認してください。 | 鍵バージョンが有効になっていないか、適切な権限がありません。 | Cloud KMS 鍵バージョンを再度有効にします。 適切な権限があることを確認します。 |
| サーバー内部エラーが発生したため、CMEK リソースの再暗号化に失敗しました。しばらくしてからもう一度お試しください | サーバー内部エラーが発生しました。 | 再暗号化を再試行します。詳細については、既存の CMEK 対応インスタンスまたはレプリカを再暗号化するをご覧ください。 |