クラウド SQL SLA 契約では、「Google の合理的な制御が及ばない要因によって発生する」停止は除外されます。このページでは、Cloud SQL インスタンスの停止の原因になる可能性があり、除外されるユーザー制御構成の一部について説明します。
はじめに
Cloud SQL は、インスタンスの構成を可能な限り詳細に制御できるようにしています。これには、負荷やその他の構成パラメータに応じて、インスタンスのダウンタイムのリスクを高めるいくつかの構成も含まれます。インスタンスが停止し、Cloud SQL が、このページで説明されているオペレーション制限に準拠していないと判断した場合、ダウンタイム期間が Cloud SQL SLA 契約の対象外になります（または SLA の対象としてカウントされません）。
このオペレーション制限のリストは、どのような構成にこうしたリスクがあるのか、これらの構成のいずれかに誤って移行することを避ける方法、およびビジネス環境でそのような構成が必要な場合にリスクを軽減する方法をお知らせするために掲載しています。
除外される構成
除外される構成は、次のカテゴリに分類されます。
- 一般的な構成要件
- データベース フラグ値
- リソースの制約
一般的な構成要件
少なくとも 1 つの専用 CPU によって高可用性を実現するように構成された Cloud SQL インスタンスのみが SLA の対象となります。共有コア インスタンスとシングルゾーン インスタンスは、SLA の対象外です。
インスタンスが構成され、ワークロードで過負荷状態になるような方法で使用されている場合、SLA は適用されません。たとえば、次のような場合があります。
work_mem、特定のワークロード クエリ、アクティブな並列接続数の組み合わせによっては、システムがメモリ不足になり、PostgreSQL ワーカー バックエンドがクラッシュし、結果として postgreSQL によって復旧オペレーションが実行される場合があります。- 処理能力の低い VM サイズでは、
checkpoint_timeout、max_wal_size、高いワークロードの組み合わせによっては復旧（WA リプレイ）に時間がかかる場合があります。 - 非常に多くのトランザクションが、多数の一時ファイルを作成するワークロードと一緒に実行されるため、
autovacuumが間に合わず、テーブルが肥大化してパフォーマンスが低下する可能性があります。
PostgreSQL データベースが過負荷状態になる条件は数多く存在します。このリストはすべての条件を網羅したものではありません。Cloud Monitoring でアラートとモニタリングを設定することを強くおすすめします。
データベース フラグ値
Cloud SQL では、データベース フラグを使用してインスタンスを構成できます。これらのフラグの一部は、安定性やインスタンスまたはそのデータの耐久性を損なうおそれのある方法で設定されることがあります。
リソースの制約
SLA が適用されるようにするには、次のリソース制約を回避する必要があります。
| 制約 | 説明 | 検出 | 対処方法 | 予防策 |
|---|---|---|---|---|
| ストレージがいっぱいである | インスタンスのストレージが不足していてストレージの自動増量機能が有効になっていない場合、インスタンスはオフラインになります。この停止は SLA の対象となりません。 | インスタンスが使用しているストレージの量は、Google Cloud Console のインスタンスの詳細ページで確認できます。詳細 ストレージの使用状況をモニタリングし、指定されたしきい値でアラートを受信するために、Stackdriver アラートを設定します。詳細 |
インスタンスのストレージ サイズを増やします。ストレージのサイズは増やすことができますが、減らすことはできません。 | インスタンスのストレージの自動増量を有効にします。詳細については、こちらをご覧ください。 |
| CPU オーバーロード | 6 時間にわたって CPU 使用率が 98% を超える場合、インスタンスはワークロードに適切なサイズではなく、SLA の対象となりません。 | 使用可能な CPU のうち、インスタンスが使用している割合は、Google Cloud Console のインスタンスの詳細ページで確認できます。詳細 CPU の使用率をモニタリングし、指定されたしきい値でアラートを受信するために、Stackdriver アラートを設定します。詳細 |
インスタンスの CPU 数を増やしてください。なお、CPU を変更するには、インスタンスを再起動する必要があります。 インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングします。 |
CPU 使用率をモニタリングし、必要に応じて増やします。なお、インスタンス CPU の変更では、再起動が必要です。 |