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

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

Cloud SQL for PostgreSQL インスタンスのオペレーション ガイドラインはまだ使用できませんが、同じ原則が PostgreSQL インスタンスに適用されます。

はじめに

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)エラーによるインスタンスの停止。 デフォルト設定のままにします。
temp_table_size 一時テーブルのサイズを決定します。 デフォルト値より大きい。 メモリ不足(OOM)エラーによるインスタンスの停止。 デフォルト設定のままにするか、インスタンスの容量を超えないように、ワークロードを慎重に計画します。
query_cache_sizequery_cache_type これらのフラグの組み合わせにより、クエリ キャッシュのサイズが決まります。 デフォルト値より大きい。 メモリ不足(OOM)エラーによるインスタンスの停止。 デフォルト設定のままにするか、インスタンスの容量を超えないように、ワークロードを慎重に計画します。

リソースの制約

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

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

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

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

CPU の使用率をモニタリングし、指定されたしきい値でアラートを受信するために、Stackdriver アラートを設定します。 詳細

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

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

CPU 使用率をモニタリングし、必要に応じて増やします。インスタンス階層を変更するには、再起動が必要です。
レプリケーション ラグが大きすぎる 1,200 秒を超えるレプリケーション ラグによって発生するフェイルオーバー ダウンタイムは、インスタンスの SLA に対してカウントされません。 フェイルオーバー レプリカの Seconds Behind Master 指標を使用してレプリケーション ラグをモニタリングできます。 マスターへの受信負荷を調整するか、データベースをシャーディングします。 レプリケーション ラグのアラートを作成し、必要に応じて是正措置を取ります。 詳細
データベース テーブルが多すぎる 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 準拠に戻ることはありません。

データ アーキテクチャで多数のテーブルが必要な場合は、データを複数のインスタンスに分割します。
このページは役立ちましたか?評価をお願いいたします。

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