MySQL インスタンスのオペレーション ガイドライン

Cloud SQL SLA 契約では、「Google の合理的な制御が及ばない要因によって発生する」停止は除外されます。このページでは、除外される第 2 世代の Cloud SQL for MySQL インスタンスの停止を引き起こす可能性のある、いくつかのユーザー制御構成について説明します。

Cloud SQL for PostgreSQL インスタンス、SQLServer インスタンスのオペレーション ガイドラインはまだ提供されていませんが、同様の原則が適用されます。

はじめに

Cloud SQL は、インスタンスの構成を可能な限り詳細に制御できるようにしています。これには、負荷やその他の構成パラメータに応じて、インスタンスのダウンタイムのリスクを高めるいくつかの構成も含まれます。インスタンスが停止し、Cloud SQL が、このページで説明されているオペレーション制限に準拠していないと判断した場合、ダウンタイム期間が Cloud SQL SLA 契約の対象外になります(または SLA の対象としてカウントされません)。

このオペレーション制限のリストは、どのような構成にこうしたリスクがあるのか、これらの構成のいずれかに誤って移行することを避ける方法、およびビジネス環境でそのような構成が必要な場合にリスクを軽減する方法をお知らせするために掲載しています。

除外される構成

除外される構成は、次のカテゴリに分類されます。

  • 一般的な構成要件
  • データベース フラグ値
  • リソースの制約

一般的な構成要件

少なくとも 1 つの専用 CPU によって高可用性を実現するように構成された Cloud SQL インスタンスのみが SLA の対象となります。共有コア インスタンスとシングルゾーン インスタンスは、SLA の対象外です。

データベース フラグ値

Cloud SQL では、データベース フラグを使用してインスタンスを構成できます。これらのフラグのいくつかは、安定性やインスタンスまたはそのデータの耐久性を損なうおそれのある方法で設定されることがあります。

次の表に、SLA から除外される値を持つフラグを示します。

フラグ 説明 除外される設定 発生する可能性のある影響 緩和策
general_log MySQL 一般ログを有効にします。 オン、log_output フラグが TABLE に設定されている 再起動が遅くなる。 log_output フラグを FILE に設定します
slow_query_log MySQL 低速クエリログを有効にします。 オン、log_output フラグが TABLE に設定されている 再起動が遅くなる。 log_output フラグを FILE に設定します
max_heap_table_size メモリテーブルのサイズを決定します。 デフォルト値より大きい。 メモリ不足(OOM)エラーによるインスタンスの停止。 デフォルト設定のままにします。
tmp_table_size 一時テーブルのサイズを決定します。 デフォルト値より大きい。 メモリ不足(OOM)エラーによるインスタンスの停止。 デフォルト設定のままにするか、インスタンスの容量を超えないように、ワークロードを慎重に計画します。
query_cache_size query_cache_type これらのフラグの組み合わせにより、クエリ キャッシュのサイズが決まります。 デフォルト値より大きい。 メモリ不足(OOM)エラーによるインスタンスの停止。 デフォルト設定のままにするか、インスタンスの容量を超えないように、ワークロードを慎重に計画します。

リソースの制約

SLA が適用されるようにするには、次のリソース制約を回避する必要があります。

制約 説明 検出 対処方法 予防策
ストレージがいっぱいである インスタンスのストレージが不足していてストレージの自動増量機能が有効になっていない場合、インスタンスはオフラインになります。この停止は SLA の対象となりません。 インスタンスが使用しているストレージの量は、Cloud Console のインスタンスの詳細ページで確認できます。詳細については、こちらをご覧ください。

ストレージの使用状況をモニタリングし、指定されたしきい値でアラートを受信するために、Stackdriver アラートを設定します。詳細については、こちらをご覧ください。

インスタンスのストレージ サイズを増やします。ストレージのサイズは増やすことができますが、減らすことはできません。 インスタンスのストレージの自動増量を有効にします。詳細については、こちらをご覧ください。
CPU オーバーロード 6 時間にわたって CPU 使用率が 98% を超える場合、インスタンスはワークロードに適切なサイズではなく、SLA の対象となりません。 使用可能な CPU のうち、インスタンスが使用している割合は、Cloud Console のインスタンスの詳細ページで確認できます。詳細については、こちらをご覧ください。

CPU の使用率をモニタリングし、指定されたしきい値でアラートを受信するために、Stackdriver アラートを設定します。詳細については、こちらをご覧ください。

インスタンスの CPU 数を増やしてください。階層を変更するには、インスタンスを再起動する必要があります。

インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングします。

CPU 使用率をモニタリングし、必要に応じて増やします。インスタンス階層を変更するには、再起動が必要です。
データベース テーブルが多すぎる 1 つのインスタンスに 10,000 以上のデータベース テーブルがあると、インスタンスが応答不能になったり、メンテナンス オペレーションを実行できなくなったりして、インスタンスが SLA の対象外になる可能性があります。 インスタンスに存在するテーブルの数を確認する: SELECT COUNT(*) FROM information_schema.tables; 各データベースにあるテーブルの数を確認する: SELECT TABLE_SCHEMA,COUNT(*) FROM information_schema.tables group by TABLE_SCHEMA; テーブルの数を 10,000 未満に減らします。

すぐに表の数を減らすことができない場合は、innodb_file_per_table フラグを OFF に設定して、テーブルの数が多い場合にインスタンスが影響を受ける可能性を削減できます。ただし、この設定によってインスタンスが SLA 準拠に戻ることはありません。

データ アーキテクチャで多数のテーブルが必要な場合は、データを複数のインスタンスに分割します。