このページでは、Cloud SQL インスタンスの高可用性（HA）構成の概要を説明します。HA の新しいインスタンスを構成する、あるいは既存のインスタンスで HA を有効にするには、インスタンスでの高可用性の有効化と無効化を参照してください。
HA 構成の概要
HA 構成の目的は、ゾーンまたはインスタンスが利用できなくなったときのダウンタイムの削減です。これは、ゾーンでサービスが停止した場合や、インスタンスが破損した場合に発生することがあります。HA を使用すれば、クライアント アプリケーションで引き続きデータを使用できるようになります。
HA 構成は「クラスタ」とも呼ばれ、データの冗長性を確保します。HA 向けに構成された Cloud SQL インスタンスは「リージョン インスタンス」とも呼ばれ、構成されたリージョン内のプライマリ ゾーンとセカンダリ ゾーンに配置されます。リージョン インスタンスはプライマリ インスタンスとスタンバイ インスタンスで構成されます。各ゾーンの永続ディスクへの同期レプリケーションにより、トランザクションが commit されたとしてレポートされる前に、プライマリ インスタンスへの書き込みのすべてが両方のゾーンのディスクに複製されます。インスタンスまたはゾーンで障害が発生した場合、永続ディスクはスタンバイ インスタンスにアタッチされ、新しいプライマリ インスタンスになります。ユーザーは新しいプライマリに再転送されます。このプロセスは、フェイルオーバーと呼ばれます。
フェイルオーバー後は、元のインスタンスが再びオンラインになっても、フェイルオーバーを受信したインスタンスがプライマリ インスタンスのままとなります。サービスが停止したゾーンまたはインスタンスが再び使用可能になると、元のプライマリ インスタンスは破棄され、再作成されます。その後、それが新しいスタンバイ インスタンスになります。将来、フェイルオーバーが発生した場合、新しいプライマリは元のゾーン内の元のインスタンスにフェイルオーバーします。
サービス停止が発生したゾーンのプライマリ インスタンスが必要な場合は、フェイルバックを実施できます。フェイルバックはフェイルオーバーと同じ手順を逆方向に実施し、トラフィックを元のインスタンスに再転送します。フェイルバックを実施するには、フェイルオーバーの開始で説明されている手順を行います。
Cloud SQL と Cloud SQL HA 構成のリージョン永続ディスク サポートには、完全なサービスレベル契約（SLA）が適用されます。HA 向けに構成されたインスタンスを使用する場合は、スタンドアロン インスタンスの 2 倍の料金がかかります。これには、CPU、RAM、およびストレージの料金が含まれます。詳細については、料金のページをご覧ください。
リードレプリカ
リードレプリカは、プライマリ インスタンスのように高可用性にできません。ゾーンでサービスが停止している間、そのゾーンのリードレプリカへのトラフィックは停止します。ゾーンが再び使用可能になると、ゾーン内のリードレプリカはプライマリ インスタンスからレプリケーションを再開します。サービスが停止していないゾーンにリードレプリカがある場合、スタンバイ インスタンスがプライマリ インスタンスになると、リードレプリカはスタンバイ インスタンスに接続されます。
リードレプリカは、プライマリ インスタンスやスタンバイ インスタンスとは異なるゾーンに配置することをおすすめします。たとえば、ゾーン A にプライマリ インスタンス、ゾーン B にスタンバイ インスタンスがある場合、リードレプリカをゾーン C に配置します。これにより、プライマリ インスタンスのゾーンがダウンしても、リードレプリカが引き続き稼働します。また、リードレプリカが利用できないときは、プライマリ インスタンスに読み取りを送信するビジネス ロジックをクライアント アプリケーションに追加する必要もあります。
注: スタンバイ インスタンスは、読み取りクエリには使用できません。これは、Cloud SQL for MySQL の従来の HA 構成とは異なります。
フェイルオーバーの概要
HA 構成のインスタンスが応答しなくなると、Cloud SQL は自動的にスタンバイ インスタンスからデータを提供するように切り替えます。フェイルオーバーが発生したかどうかを確認するには、オペレーション ログのフェイルオーバー履歴を調べます。
各タブをクリックして、フェイルオーバーがインスタンスに与える影響を確認してください。
正常
フェイルオーバー
フェイルオーバー後
フェイルバック
プロセス
次のプロセスが発生します。
プライマリ インスタンスまたはゾーンで障害が発生します。
プライマリ インスタンスがハートビート シグナルとして、1 秒ごとにシステム データベースに対して書き込み操作を行います。複数のハートビートが検出されない場合、フェイルオーバーが開始されます。フェイルオーバーが発生するのは、プライマリ インスタンスが約 60 秒間応答しない場合、またはプライマリ インスタンスが配置されているゾーンでサービスが停止している場合です。
スタンバイ インスタンスが再接続されて、データの提供を開始します。
スタンバイ インスタンスは、プライマリ インスタンスと共有する静的 IP アドレスを使用してセカンダリ ゾーンからデータを提供します。
要件
Cloud SQL がフェイルオーバーできるようにするには、次の要件を満たす構成が必要です。
- プライマリ インスタンスが通常の動作状態である（停止していない、メンテナンス中でない、バックアップ、インポート、エクスポートなど長時間実行されている Cloud SQL インスタンス オペレーションがない）こと。
- セカンダリ ゾーンとスタンバイ インスタンスが、どちらも正常な状態であること。スタンバイ インスタンスが応答せず、セカンダリ ゾーンへのレプリケーションが中断された場合、フェイルオーバー オペレーションはブロックされます。Cloud SQL でスタンバイ インスタンスが修復され、セカンダリ ゾーンが使用可能になると、レプリケーションが再開され、Cloud SQL でフェイルオーバーが可能になります。
バックアップと復元
高可用性を実現するには、自動バックアップとポイントインタイム リカバリを有効にする必要があります（ポイントインタイム リカバリではバイナリログを使用します）。アプリケーションとインスタンス
HA インスタンスと非 HA インスタンスの使用方法に違いはありません。したがって、アプリケーションを特別な方法で構成する必要はありません。フェイルオーバーが発生すると、プライマリ インスタンスとリードレプリカへの既存の接続が切断されます。プライマリ インスタンスへの接続が再確立されるまでに約 2～3 分かかります。レプリカへの接続には時間がかかることがあります。アプケーションは再接続する際に同じ接続文字列または IP アドレスを使用するため、フェイルオーバー後にアプリケーションを更新する必要はありません。
アプリケーションがフェイルオーバーによってどのように影響されるかを正確に判断するには、手動でフェイルオーバーを開始します。
メンテナンスによるダウンタイム
メンテナンス イベントは、他のインスタンスと同様に、HA が構成されたプライマリ インスタンスに影響します。少しの間、プライマリ インスタンスが停止することが予測されます。メンテナンスが HA インスタンスに与える影響の詳細については、メンテナンスの仕組みをご覧ください。サービスへの影響を最小限に抑えるには、メンテナンスの設定を変更して、ダウンタイムが発生する時間帯を制御します。
パフォーマンス
リージョン永続ディスクのパフォーマンスは、多くの要因に左右されます。特に、vm instance type のサイズとワークロードの入出力がパフォーマンスに影響します。もう 1 つの指標は、SSD（ソリッド ステート ドライブ）を使用しているリージョン永続ディスクのレイテンシが、ローカル SSD を使用している永続ディスクのレイテンシよりも高くなっているかどうかです。つまり、ワークロードがストリーミング ワークロードではなくレイテンシの影響を受けやすい場合、ローカル SSD を使用している永続ディスクよりも SSD を使用しているリージョン永続ディスクでレイテンシが高くなるので、ワークロードが 1 秒あたりの入出力オペレーションの回数（IOPS）の上限に達しないことになります。これは、2 つのコピーを書き込むために必要な冗長性によってテール レイテンシが増加するためです。
従来の MySQL の高可用性オプション
2021 年第 1 四半期までは、フェイルオーバー レプリカを使用する MySQL インスタンスに高可用性を付与する従来型のプロセスを使用できます。Cloud Console では、従来の機能は使用できません。代わりに、gcloud または cURL コマンドを使用します。レガシー構成: 高可用性向けに構成された新しいインスタンスを作成する、またはレガシー構成: 既存のインスタンスを高可用性向けに構成するをご覧ください。
次のステップ
- インスタンスでの高可用性を有効または無効にする
- フェイルオーバーを開始する
- データベース接続の管理について学習する
- Cloud SQL のリージョンとゾーンについて学習する