高可用性構成の概要

MySQL | PostgreSQL | SQL Server

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

HA 構成の概要

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

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

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

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

フェイルオーバーの概要

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

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

正常

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

フェイルオーバー

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

フェイルバック

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

プロセス

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

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

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

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

要件

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

プライマリインスタンスが通常の動作状態である（停止していない、メンテナンス中でない、バックアップ、インポート、エクスポートなど長時間実行されている 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 コマンドを使用します。レガシー構成: 高可用性向けに構成された新しいインスタンスを作成する、またはレガシー構成: 既存のインスタンスを高可用性向けに構成するをご覧ください。