高可用性構成の概要

このページでは、Cloud SQL インスタンスの高可用性（HA）構成の概要を説明します。HA の新しいインスタンスを構成する、あるいは既存のインスタンスで HA を有効にするには、インスタンスでの高可用性の有効化と無効化を参照してください。

HA 構成の概要

HA 構成はクラスタとも呼ばれ、データの冗長性を確保します。HA 向けに構成された Cloud SQL インスタンスはリージョン インスタンスとも呼ばれ、構成されたリージョン内のプライマリ ゾーンとセカンダリ ゾーンに配置されます。リージョン インスタンスはプライマリ インスタンスとスタンバイ インスタンスで構成されます。各ゾーンの永続ディスクへの同期レプリケーションにより、プライマリ インスタンスへの書き込みのすべてがスタンバイ インスタンスにも反映されます。インスタンスまたはゾーンで障害が発生した場合、この構成によりダウンタイムが短縮され、クライアント アプリケーションで引き続きデータを使用できます。

注: スタンバイ インスタンスは、読み取りクエリには使用できません。これは、Cloud SQL for MySQL の従来の HA 構成とは異なります。

Cloud SQL と Cloud SQL HA 構成のリージョン PD（永続ディスク）サポートは一般提供されており、そのすべてが SLA の適用対象です。HA 向けに構成されたインスタンスを使用する場合は、スタンドアロン インスタンスの 2 倍の料金がかかります。これには、CPU、RAM、およびストレージの料金が含まれます。詳細については、料金のページをご覧ください。

Cloud SQL HA 構成の概要図以下のテキストで説明されています。

フェイルオーバーの概要

HA 構成のインスタンスが応答しなくなると、Cloud SQL は自動的にスタンバイ インスタンスからデータを提供するように切り替えます。この動作は「フェイルオーバー」と呼ばれます。フェイルオーバーが発生したかどうかを確認するには、オペレーション ログのフェイルオーバー履歴を調べます。

各タブをクリックして、フェイルオーバーがインスタンスに与える影響を確認してください。

正常

フェイルオーバー前の正常なインスタンスを示す図

フェイルオーバー

フェイルオーバー発生時のインスタンスを示す図

フェイルバック

フェイルバック後のインスタンスを示す図

プロセス

次のプロセスが発生します。

  • プライマリ インスタンスまたはゾーンで障害が発生します。

    プライマリ インスタンスがハートビート シグナルとして、1 秒ごとにシステム データベースに対して書き込み操作を行います。複数のハートビートが検出されない場合、フェイルオーバーが開始されます。フェイルオーバーが発生するのは、プライマリ インスタンスが約 60 秒間応答しない場合、またはプライマリ インスタンスが配置されているゾーンでサービスが停止している場合です。

  • スタンバイ インスタンスが再接続されて、データの提供を開始します。

    スタンバイ インスタンスは、プライマリ インスタンスと共有する静的 IP アドレスを使用してセカンダリ ゾーンからデータを提供します。

要件

Cloud SQL がフェイルオーバーできるようにするには、次の要件を満たす構成が必要です。

  • プライマリ インスタンスが通常の動作状態（停止していない、メンテナンス中でない、長時間実行オペレーションの最中でない）にある。
  • セカンダリ ゾーンとスタンバイ インスタンスが、どちらも正常な状態であること。スタンバイ インスタンスが応答せず、セカンダリ ゾーンへのレプリケーションが中断された場合、フェイルオーバー オペレーションはブロックされます。Cloud SQL でスタンバイ インスタンスが修復され、セカンダリ ゾーンが使用可能になると、レプリケーションが再開され、Cloud SQL でフェイルオーバーが可能になります。

バックアップ

高可用性を実現するには、自動バックアップを有効にする必要があります。

アプリケーションとインスタンス

非 HA インスタンスと HA インスタンスの使用方法にはまったく違いがありません。したがって、アプリケーションを特定の方法で構成する必要はありません。フェイルオーバーが発生すると、プライマリ インスタンスとリードレプリカへの既存の接続が切断されます。接続が再確立されるまでには約 2～3 分かかります。アプケーションは再接続する際に同じ接続文字列または IP アドレスを使用するため、フェイルオーバー後にアプリケーションを更新する必要はありません。

アプリケーションがフェイルオーバーによってどのように影響されるかを正確に判断するには、手動でフェイルオーバーを開始します。

メンテナンスによるダウンタイム

メンテナンス イベントは、他のインスタンスと同様に、HA が構成されたプライマリ インスタンスに影響します。この間、プライマリ インスタンスが停止することが予測されます。サービスへの影響を最小限に抑えるために、メンテナンスの時間枠を設定してダウンタイムが発生する時間帯を管理できます。

インスタンスでメンテナンスが発生しても、スタンバイ インスタンスにはフェイルオーバーしません。メンテナンスの更新は、プライマリ インスタンスとスタンバイ インスタンスに同時に適用されます。

パフォーマンス

リージョン永続ディスクのパフォーマンスは、多くの要因に左右されます。特に、vm instance type のサイズとワークロードの入出力がパフォーマンスに影響します。もう 1 つの指標は、SSD（ソリッド ステート ドライブ）を使用しているリージョン永続ディスクのレイテンシが、ローカル SSD を使用している永続ディスクのレイテンシよりも高くなっているかどうかです。つまり、ワークロードがストリーミング ワークロードではなくレイテンシの影響を受けやすい場合、ローカル SSD を使用している永続ディスクよりも SSD を使用しているリージョン永続ディスクでレイテンシが高くなるので、ワークロードが 1 秒あたりの入出力オペレーションの回数（IOPS）の上限に達しないことになります。これは、2 つのコピーを書き込むために必要な冗長性によってテール レイテンシが増加するためです。

従来の MySQL の高可用性オプション

2021 年第 1 四半期までは、フェイルオーバー レプリカを使用する MySQL インスタンスに高可用性を付与する従来型のプロセスを使用できます。Cloud Console では、従来の機能は使用できません。代わりに、gcloud または cURL コマンドを使用します。レガシー構成: 高可用性向けに構成された新しいインスタンスを作成する、またはレガシー構成: 既存のインスタンスを高可用性向けに構成するをご覧ください。

次のステップ