高可用性について

MySQL | PostgreSQL | SQL Server

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

HA 構成の概要

HA 構成の目的は、ゾーンまたはインスタンスが利用できなくなったときのダウンタイムの削減です。これは、ゾーンの停止中やハードウェアに問題がある場合に発生する可能性があります。HA を使用すれば、クライアントアプリケーションで引き続きデータを使用できるようになります。

HA 構成では、データの冗長性が確保されます。HA 向けに構成された Cloud SQL インスタンスはリージョンインスタンスとも呼ばれ、構成されたリージョン内にプライマリゾーンとセカンダリゾーンがあります。リージョンインスタンスはプライマリインスタンスとスタンバイインスタンスで構成されます。各ゾーンの永続ディスクへの同期レプリケーションにより、トランザクションが commit されたとしてレポートされる前に、プライマリインスタンスへの書き込みのすべてが両方のゾーンのディスクに複製されます。インスタンスまたはゾーンに障害が発生した場合、スタンバイインスタンスが新しいプライマリインスタンスになります。ユーザーは新しいプライマリインスタンスに再転送されます。このプロセスは、フェイルオーバーと呼ばれます。

フェイルオーバー後は、元のインスタンスが再びオンラインになっても、フェイルオーバーを受信したインスタンスがプライマリインスタンスのままとなります。サービスが停止したゾーンまたはインスタンスが再び使用可能になると、元のプライマリインスタンスは破棄され、再作成されます。その後、それが新しいスタンバイインスタンスになります。将来、フェイルオーバーが発生した場合、新しいプライマリは元のゾーン内の元のインスタンスにフェイルオーバーします。

サービス停止が発生したゾーンのプライマリインスタンスが必要な場合は、フェイルバックを実施できます。フェイルバックはフェイルオーバーと同じ手順を逆方向に実施し、トラフィックを元のインスタンスに再転送します。フェイルバックを実施するには、フェイルオーバーの開始で説明されている手順を行います。

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

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

リードレプリカ

リードレプリカで可用性が問題になる場合は、レプリカで HA を有効にできます。このようなレプリカをプライマリインスタンスにプロモートさせた場合、そのレプリカは高可用性インスタンスとしてすでに設定されています。

ゾーンでサービスが停止している間、そのゾーンのリードレプリカへのトラフィックは停止します。ゾーンが再び使用可能になると、ゾーン内のリードレプリカはプライマリインスタンスからレプリケーションを再開します。サービスが停止しているゾーンにリードレプリカがない場合、スタンバイインスタンスがプライマリインスタンスになると、リードレプリカはスタンバイインスタンスに接続します。

ベストプラクティスとして、リードレプリカの一部をプライマリインスタンスやスタンバイインスタンスとは異なるゾーンに置くことを検討してください。たとえば、ゾーン A にプライマリインスタンスが、ゾーン B にスタンバイインスタンスがある場合、ゾーン C にリードレプリカを置いて信頼性を向上させます。これにより、プライマリインスタンスのゾーンがダウンしても、リードレプリカが引き続き稼働します。また、リードレプリカが利用できないときは、プライマリインスタンスに読み取りを送信するビジネスロジックをクライアントアプリケーションに追加する必要もあります。

フェイルオーバーの概要

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

ログエクスプローラでクエリを作成する方法をご確認ください。オペレーションを実施したユーザーなど、オペレーションに関する詳細情報が必要な場合は、監査ロギングを有効にする必要があります。

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

正常

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

フェイルオーバー

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

フェイルオーバー後

フェイルオーバー後のインスタンスを示す図

フェイルバック

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

プロセス

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

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

ハートビートシステムは、プライマリインスタンスが正常かどうかを 1 秒ごとに検出します。複数のハートビートが検出されない場合、フェイルオーバーを開始します。
スタンバイインスタンスが再接続されて、データの提供を開始します。

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

要件

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

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

バックアップと復元

高可用性を実現するために、自動バックアップを実行することを強くおすすめします。

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

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

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

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

メンテナンスイベントは、他のインスタンスと同様に、HA で構成されたプライマリインスタンスに影響します。少しの間、プライマリインスタンスが停止することが予測されます。メンテナンスが HA インスタンスに与える影響の詳細については、メンテナンスの仕組みをご覧ください。サービスへの影響を最小限に抑えるには、メンテナンスの設定を変更して、ダウンタイムが発生する時間帯を制御します。