Cloud SQL の障害復旧（DR）について

このページでは、Cloud SQL での障害復旧について説明します。

概要

Google Cloud のデータベースの障害復旧（DR）は、特にリージョンで障害が発生した場合やリージョンが使用不可になった場合に、処理の継続性を実現することが目的です。Cloud SQL はリージョンサービスです（Cloud SQL が HA 用に構成されている場合）。したがって、Cloud SQL データベースをホストする Google Cloud リージョンが使用不可になると、Cloud SQL データベースも使用できなくなります。

処理を続行するには、できるだけ早くセカンダリリージョンでデータベースを利用できるようにする必要があります。このような DR 計画を実現するには、Cloud SQL の中でクロスリージョンリードレプリカを構成する必要があります。エクスポート / インポートまたはバックアップ / 復元によるフェイルオーバーも可能ですが、この方法では所要時間が長くなり、特に大規模なデータベースの場合は顕著です。

クロスリージョンフェイルオーバー構成を使用するのが適切であるビジネスシナリオの例を以下に示します。

ビジネスアプリケーションのサービスレベル契約が、リージョンの Cloud SQL サービスレベル契約（Cloud SQL エディションに応じて 99.99% の可用性）を超えています。別のリージョンにフェイルオーバーすることで、サービスの停止を軽減できます。
ビジネスアプリケーションのすべての階層はすでにマルチリージョンであり、リージョンが停止した場合も処理を続行できます。クロスリージョンフェイルオーバー構成により、データベースの継続的な可用性を確保できます。
要求される目標復旧時間（RTO）と目標復旧地点（RPO）は、時間単位ではなく分単位です。別のリージョンへのフェイルオーバーは、データベースの再作成よりも高速です。

通常、DR プロセスには 2 つのパターンがあります。

データベースがセカンダリリージョンにフェイルオーバーします。データベースの準備ができてアプリケーションで使用されると、そのデータベースが新たにプライマリデータベースになり、その後もプライマリデータベースを継続します。
データベースがセカンダリリージョンにフェイルオーバーしても、プライマリリージョンが障害から回復すると、プライマリリージョンにフォールバックします。

この Google Cloud SQL データベースの障害復旧の概要では、2 番目のバリアントについて説明します。これは、障害が発生したデータベースが回復し、プライマリリージョンにフォールバックするケースです。この DR プロセスは、ネットワークのレイテンシや、プライマリリージョンでのみ利用可能なリソースがあるため、プライマリリージョンで実行する必要があるデータベースに特に適しています。このパターンを使用すると、データベースはプライマリリージョンでサービスが停止している間のみ、セカンダリリージョンで実行されます。

この DR ドキュメントに関連するチュートリアルは次のとおりです。

障害復旧アーキテクチャ

次の図は、HA Cloud SQL インスタンスのデータベース DR をサポートする最小限のアーキテクチャを示しています。

プライマリインスタンスとスタンバイインスタンスは 1 つのリージョンに配置され、リードレプリカは 2 番目のリージョンにあります。

このアーキテクチャは次のように機能します。

Cloud SQL の 2 つのインスタンス（プライマリインスタンスとスタンバイインスタンス）は、単一のリージョン（プライマリリージョン）内の 2 つの別々のゾーンにあります。インスタンスは、リージョン永続ディスクを使用して同期されます。
Cloud SQL（クロスリージョンリードレプリカ）の 1 つのインスタンスが 2 番目のリージョン（セカンダリリージョン）にあります。DR の場合、クロスリージョンリードレプリカは、リードレプリカの設定を使用して（非同期レプリケーションを使用）プライマリインスタンスとの同期をとるように設定されます。

プライマリインスタンスとスタンバイインスタンスは、同じリージョンディスクを共有しているため、インスタンスの状態は同一です。

この設定では非同期レプリケーションを使用するため、クロスリージョンリードレプリカがプライマリインスタンスの後で遅延する可能性があります。フェイルオーバーが発生したときに、クロスリージョンリードレプリカは RPO ゼロをサポートできる可能性があります。

障害復旧（DR）プロセス

障害復旧（DR）プロセスは、プライマリリージョンが使用不可になったときに開始します。セカンダリリージョンで処理を再開するには、クロスリージョンリードレプリカをプロモートすることによってプライマリインスタンスのフェイルオーバーをトリガーします。手動か自動かを問わず、実行する必要のある運用ステップが DR プロセスとして規定されており、これによってリージョン障害が軽減されるとともに、プライマリインスタンスがセカンダリリージョンで稼働する状態が確立します。

次の図は、DR プロセスを示しています。

リージョン 1 が使用不可になると、元のリードレプリカがプライマリに昇格されます。

この DR プロセスは以下の手順で構成されます。

プライマリインスタンスを実行しているプライマリリージョン（R1）が使用不可になります。
オペレーションチームがこの障害を認識して正式に認め、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、セカンダリリージョン（R2）にあるクロスリージョンリードレプリカをプロモートして新しいプライマリインスタンスにすることができます。
クライアント接続が再構成されて、新しいプライマリインスタンスで処が再開し、R2 のプライマリインスタンスにアクセスされるようになります。

この初期プロセスによって、プライマリデータベースが稼働する状態が再び確立します。ただし、完全な DR アーキテクチャ（新しいプライマリインスタンス自体にスタンバイインスタンスとクロスリージョンリードレプリカがある）は確立しません。

完全な DR プロセスによって、単一のインスタンス（新しいプライマリ）が HA に対して有効になり、クロスリージョンリードレプリカを持つ状態になります。また、完全な DR プロセスは、元のプライマリリージョンでの元のデプロイへのフォールバックも実施します。

セカンダリリージョンにフェイルオーバーする

完全な DR プロセスでは、フェイルオーバー後に完全な DR アーキテクチャを確立するためのステップを追加することで、基本的な DR プロセスを拡張します。次の図は、フェイルオーバー後の完全なデータベース DR アーキテクチャを示しています。

クライアントが新しいプライマリインスタンスへのアクセスを開始し、リードレプリカが 3 番目のリージョンに設定されます。

完全なデータベースの DR プロセスは、次の手順で構成されます。

プライマリデータベースを実行しているプライマリリージョン（R1）が使用できなくなります。
オペレーションチームが障害を認識して正式に応答し、フェイルオーバーが必要かどうかを判断します。
フェイルオーバーが必要な場合は、セカンダリリージョン（R2）のクロスリージョンリードレプリカをプロモートして、新しいプライマリインスタンスにできます。
クライアント接続が、新しいプライマリインスタンス（R2）にアクセスして処理するように再構成されます。
R2 で新しいスタンバイインスタンスが作成され、プライマリインスタンスに追加されます。スタンバイインスタンスは、プライマリインスタンスとは異なるゾーンにあります。プライマリインスタンスのスタンバイインスタンスが作成されたため、プライマリインスタンスの可用性が向上しました。
3 番目のリージョン（R3）では、新しいクロスリージョンリードレプリカが作成され、プライマリインスタンスに接続されます。この時点で、完全な障害復旧アーキテクチャが再構築され、運用が可能になります。

ステップ 6 を実装する前に元のプライマリリージョン（R1）が使用可能になると直ちに、クロスリージョンリードレプリカはリージョン R3 ではなくリージョン R1 に配置できるようになります。この場合は、元のプライマリリージョン（R1）へのフォールバックの複雑性が低減し、必要とする手順が減少します。

スプリットブレイン状態を回避する

プライマリリージョン（R1）の障害が発生しても、R1 が再び使用可能になったときに元のプライマリインスタンスとスタンバイインスタンスが、自動によるシャットダウンまたは削除が行われることなどにより、アクセス不可になることはありません。R1 が使用できるようになると、クライアントは（偶発的であっても）元のプライマリインスタンスのデータの読み取りと書き込みを行うことができます。この場合、スプリットブレイン状態になる可能性があり、一部のクライアントが古いプライマリデータベースの古いデータにアクセスし、他のクライアントが新しいプライマリデータベースの最新データにアクセスして、ビジネス上の問題が起きる可能性があります

スプリットブレイン状態を回避するには、R1 が使用可能になった後でクライアントが元のプライマリインスタンスにアクセスできないようにする必要があります。クライアントが新しいプライマリインスタンスの使用を開始する前に、元のプライマリをアクセス不可にし、アクセス不可にした直後に元のプライマリを削除することをおすすめします。

フェイルオーバー後の初期バックアップの確立

クロスリージョンリードレプリカをフェイルオーバーの新しいプライマリに昇格させると、新しいプライマリ内のトランザクションと元のプライマリのトランザクションが完全には同期されないことがあります。したがって、こうしたトランザクションは新しいインスタンスでは使用できません。

ベストプラクティスとして、フェイルオーバーの開始時とクライアントがデータベースにアクセスする前に、新しいプライマリインスタンスを直ちにバックアップすることをおすすめします。このバックアップは、フェイルオーバー発生時点の整合性がとれた既知の状態を表しています。このようなバックアップは、規制目的で、またはクライアントが新しいプライマリにアクセスするときに問題が発生した場合に既知の状態に戻すという目的で重要になる可能性があります。

元のプライマリリージョンにフォールバックする

前述したように、このドキュメントでは元のリージョン（R1）にフォールバックする手順を説明します。フォールバックプロセスには 2 つのバージョンがあります。

第 3 リージョン（R3）で新しいクロスリージョンリードレプリカを作成した場合は、プライマリリージョン（R1）に別の（2 番目の）クロスリージョンリードレプリカを作成する必要があります。
プライマリリージョン（R1）で新しいクロスリージョンリードレプリカを作成した場合、R1 で別のクロスリージョンリードレプリカを新たに作成する必要はありません。

R1 のクロスリージョンリードレプリカが存在する場合、Cloud SQL インスタンスは R1 にフォールバックできます。このフォールバックはサービスの停止によってではなく、手動でトリガーされるため、このメンテナンス作業に適した日時を選択できます。

したがって、プライマリ、スタンバイ、クロスリージョンリードレプリカを備えた完全な DR を実現するには、2 回のフェイルオーバーが必要になります。1 回目のフェイルオーバーは、サービスの停止によってトリガーされます（真のフェイルオーバー）。2 回目のフェイルオーバーによって、出発点となるデプロイが再確立されます（フォールバック）。

元のプライマリリージョン（R1）へのフォールバックは、次のステップで構成されます。

元のプライマリリージョン（R1）で、新しく作成されたクロスリージョンレプリカをプロモートします。
プロモートしたインスタンスが HA レプリカとして作成されたものではない場合は、ゾーン障害から保護するためにそのインスタンス上で HA を有効にします。
新しいプライマリインスタンスに接続するようにアプリケーションを再構成します。
新しいプライマリインスタンスのクロスリージョンレプリカを DR リージョン（R2）内に作成します。
（省略可）複数の独立したプライマリインスタンスが実行される状態を回避するために、DR リージョン（R2）のプライマリインスタンスをクリーンアップします。

高度な障害復旧（DR）

Cloud SQL Enterprise Plus エディションを使用している場合は、高度な DR を利用できます。高度な DR によって、クロスリージョンフェイルオーバー後の復旧とフォールバックが単純になります。障害復旧プロセスで説明しているように、DR を行うときに、古いプライマリインスタンスの、障害が発生したリージョンと、新しいプライマリインスタンスの稼働中リージョンとの接続が解除されます。DR のときに、元のデプロイリージョンへの接続を復元して古いプライマリインスタンスを再び稼働させるには、一連の手動フォールバック手順を実施する必要があります。

高度な DR では、リージョン障害が発生したときにレプリカフェイルオーバーを起動することができます。レプリカフェイルオーバーでは、通常の DR を行うときと同様にクロスリージョンリードレプリカをプロモートしますが、指定障害復旧（DR）レプリカをプロモートする点が異なります。DR レプリカのプロモートは即時に行われます。古いプライマリインスタンスは削除されるのではなく、Cloud SQL の非同期レプリケーショントポロジの一部として残ります。古いプライマリインスタンス（インスタンス A）は最終的に、自身の DR レプリカ（インスタンス B）が新しいプライマリインスタンスにプロモートされた後に、その DR レプリカのレプリカとなります。

古いプライマリインスタンス（A）がレプリカになった後に、高度な DR の最後のステップを実行できます。Cloud SQL のデプロイを元の状態に戻して、データの損失を発生させることなく古いプライマリインスタンス（A）を元の役割つまりプライマリインスタンスに戻すことができます。このような、古いプライマリインスタンス（A）のゼロデータ損失復元を実行するには、スイッチオーバーオペレーションを使用できます。スイッチオーバーを実行するときに、データが失われることはありません。プライマリインスタンス（B）は、その指定 DR レプリカ（A）がプライマリインスタンス（B）と等しい状態になるまでの間、読み取り専用モードで残っているからです。DR レプリカ（A）がレプリケーションの更新をすべて受信すると、DR レプリカ（A）がプライマリインスタンスの役割を引き継ぎ、それまでのプライマリインスタンス（B）は自動的に、現在のプライマリインスタンス（A）の DR レプリカとして再構成されます。インスタンスはそれぞれの元の役割に戻り、その結果としてトポロジは DR とレプリカフェイルオーバーの前の、元の状態に戻ります。

高度な DR では、レプリカフェイルオーバーとスイッチオーバーの両方のオペレーションに関与するすべてのインスタンスがそれぞれの IP アドレスを保持します。

高度な DR のスイッチオーバーオペレーションは定期的な DR 訓練の実施にも使用できるので、Cloud SQL トポロジがクロスリージョンフェイルオーバーに対応できるかどうかのテストと準備を、実際の障害発生前に行うことができます。実際の障害が発生した場合は、テスト済みのクロスリージョンレプリカフェイルオーバーを実行できます。

指定障害復旧（DR）レプリカ

高度な DR の必須コンポーネントの一つである DR レプリカには、次の特性があります。

DR レプリカは、直接接続されたクロスリージョンリードレプリカです。
DR レプリカの指定は何回でも変更できます。
DR レプリカの指定は、スイッチオーバーまたはレプリカフェイルオーバーのオペレーション中を除き、いつでも変更できます。

また、高度な DR を使用した後の RTO を短縮するために、次のことをおすすめします。

DR レプリカをプライマリインスタンスと同じサイズで構成します。
プライマリインスタンスで HA が有効になっている場合は、DR レプリカでも HA を有効にします。

レプリカフェイルオーバー

レプリカフェイルオーバーは、次のステップで構成されます。

レプリカフェイルオーバーの実行前に、DR レプリカがプライマリインスタンスに割り当て済みであり、可能であればスイッチオーバーを実行することによってプロセスがテスト済みです。
プライマリリージョン（ここでプライマリデータベースが実行されています）が使用不可になります。
オペレーションチームが、障害復旧が必要であると判断します。
指定 DR レプリカへのレプリカフェイルオーバーを実行します。
クロスリージョン指定 DR レプリカが即座にプライマリインスタンスになり、読み取りと書き込みの受け入れを開始します。
この時点で、新しいプライマリインスタンスを参照するようにアプリケーションを構成する必要があります。
古いプライマリインスタンスが再び使用可能になると、古いプライマリインスタンスは新しいプライマリインスタンスのリードレプリカになります。古いプライマリインスタンスの IP アドレスはそのまま保持されます。

レプリカフェイルオーバーを行った後に、プライマリインスタンスを元のリージョンで復元するには、スイッチオーバーオペレーションを実行します。これで、同じ DR レプリカとプライマリインスタンスのペアが逆転します。

スイッチオーバー

スイッチオーバーは、次のステップで構成されます。

スイッチオーバーオペレーションを開始する前に、DR レプリカをプライマリインスタンスに割り当てる必要があります。
プライマリインスタンスが正常に稼働していることを確認します。スイッチオーバーを実行できるのは、プライマリインスタンスと DR レプリカの両方がオンラインの場合のみです。
スイッチオーバーを開始します。スイッチオーバーを開始すると、プライマリインスタンスは書き込みの受け入れを停止して読み取り専用になります。
バイナリログが Cloud Storage にコピーされるまで待ちます。
指定 DR レプリカがプライマリインスタンスと同じ状態になります。
レプリケーションラグがゼロになると、DR レプリカが新しいプライマリインスタンスとしてプロモートされます。新しいプライマリインスタンスが接続の受け入れを開始します。これにはアプリケーションの読み取りと書き込みも含まれます。
古いプライマリインスタンスがリードレプリカとして再構成されます。
この時点で、新しいプライマリインスタンスを参照するにようにアプリケーションを構成する必要があります。
PITR が新しいプライマリインスタンスに対して自動的に有効になります。PITR は、最初の自動バックアップ後にのみ可能です。

次のステップ

高度な障害復旧（DR）を使用する。
Cloud SQL for MySQL の障害復旧のチュートリアルを試す。

Google Cloud に関するリファレンスアーキテクチャ、図、チュートリアル、ベストプラクティスを確認する。Cloud Architecture Center を確認します。