スイッチオーバーとフェイルオーバー
この機能は、Business Critical (SaaS) および BYOC デプロイでのみ利用できます。
この機能は、すべての AWS リージョンと、以下の Google Cloud リージョンで利用できます: gcp-us-central1 および gcp-us-east4。Microsoft Azure では利用できません。
Zilliz Cloud のグローバルクラスターは、どのリージョンがプライマリクラスターをホストするかを変更する 2 つの操作をサポートしています。
-
Switchover: 同期済みのセカンダリクラスターをプライマリに昇格させる、計画的でデータ損失ゼロの操作です。
-
Failover: プライマリリージョンで障害が発生した後、セカンダリクラスターをプライマリに昇格させる緊急復旧操作です。
このページでは、それぞれの操作をいつ使うべきか、どのように実行するか、そして実行中および実行後に何が起こるかを説明します。
概要
スイッチオーバーとフェイルオーバーの比較
次の表では、この 2 つの操作を比較しています。
Switchover | Failover | |
|---|---|---|
使用するタイミング | 計画された操作: リージョンローテーション、コンプライアンス要件、データレジデンシーの変更。 | プライマリリージョンでの予期しない停止または障害。 |
トリガー | すべてのプライマリクラスターおよびセカンダリクラスターが稼働中のときに手動で開始されます。 | プライマリクラスターが異常状態になった際の復旧アクションとして手動で開始されます |
データ損失 (RPO) | 0 — データ損失はありません。昇格はデータ同期が完全に完了した後にのみ行われます。 | フェイルオーバー時点の同期遅延に等しくなります。 |
停止時間 (RTO) | ほぼゼロです。グローバルエンドポイントは自動的に再ルーティングされます。 | 通常は数分程度です。 |
前提条件 |
|
|
旧プライマリクラスターの扱い | セカンダリクラスターに降格されます。 | 破棄され、ごみ箱 に移動されます。新しいセカンダリが自動的に作成されます。 |
アプリケーションの変更 | グローバルエンドポイントを使用している場合は不要です。ルーティングは自動的に更新されます。詳細は Connect to Global Cluster を参照してください | グローバルエンドポイントを使用している場合は不要です。ルーティングは自動的に更新されます。詳細は Connect to Global Cluster を参照してください |
クラスターステータスの遷移
次の図は、スイッチオーバー、フェイルオーバー、自動復旧の各操作中にクラスターのステータスがどのように変化するかを示しています。

-
Switchover:
-
スイッチオーバーでは、ターゲットのセカンダリが現在のプライマリと同期する間、クラスターは RUNNING から SWITCHING に遷移します。同期が完了すると、ターゲットのセカンダリは新しいプライマリに昇格し、元のプライマリはセカンダリに降格します。両方のクラスターは新しい役割で RUNNING に戻ります。
-
タイムアウト期間内に同期が完了しない場合、スイッチオーバーはロールバックされます。両方のクラスターは元の役割を保持したまま RUNNING に戻ります。
-
-
Failover:
-
障害または停止によりプライマリクラスターが ABNORMAL 状態に入った場合、フェイルオーバーをトリガーできます。ターゲットのセカンダリは新しいプライマリに昇格し、旧プライマリは破棄されてごみ箱に移動されます。
-
フェイルオーバーが完了すると、Zilliz Cloud は完全なトポロジーを復元するために新しいセカンダリクラスターを自動的に作成します。新しいセカンダリと残りのすべてのセカンダリクラスターは CREATING 状態で開始し、プロビジョニングとデータ同期が完了すると RUNNING に遷移します。作成に失敗した場合、クラスターは REBUILD_FAILED 状態になります。リビルドを再試行するか、サポートが必要な場合は お問い合わせ ください。
-
フェイルオーバー自体が失敗した場合、クラスターは ABNORMAL 状態のままです。フェイルオーバーを再試行するか、サポートが必要な場合は お問い合わせ ください。
-
-
Auto-recovery:
プライマリクラスターの問題が自然に解消された場合、クラスターは手動介入なしで ABNORMAL から RUNNING に戻ります。この場合、フェイルオーバーは不要です。
スイッチオーバーを実行する
計画的なリージョンローテーションでは、セカンダリクラスターをプライマリの役割に昇格させるためにスイッチオーバーを実行できます。
始める前に
-
グローバルクラスター内のすべてのクラスターが RUNNING 状態である必要があります。
-
同期遅延は 30 秒以下である必要があります。遅延がこのしきい値を超える場合、スイッチオーバーは拒否されます。Global Topology タブで遅延を確認してください。
-
Query CU または Replica の スケーリング 操作が進行中でないことを確認してください。
手順
-
Web コンソールを使用する場合
次のデモでは、スイッチオーバーを実行する方法を示しています。
1Global Cluster ページに移動します。
2Switchover or Failover をクリックします。
3昇格するターゲットのセカンダリクラスターを選択します。
4Switchover を選択します。
5ダイアログで操作を確認します。
スイッチオーバーを開始すると、Zilliz Cloud はターゲットのセカンダリが現在のプライマリと完全に同期するのを待ってから、新しいプライマリに昇格させます。
-
RESTful API を使用する場合
次の例では、クラスター
in01-secondaryが新しいプライマリクラスターになるようにスイッチオーバーを実行します。API の詳細については、Switchover Global Cluster を参照してください。bashcurl --request POST \--url "${BASE_URL}/v2/globalClusters/${globalClusterId}/switchover" \--header "Authorization: Bearer ${TOKEN}" \--header "Content-Type: application/json" \-d '{"newPrimaryClusterId": "in01-secondary"}'次は出力例です。
bash{"code": 0,"data": {"globalClusterId": "glo-xxxxxxxxxxxxxxxx","oldPrimaryClusterId": "in01-primary","newPrimaryClusterId": "in01-secondary","jobId": "job-xxxxxxxxxxxxxxxx"}}
スイッチオーバー後
-
元のプライマリはセカンダリクラスターとなり、新しいプライマリから複製データの受信を開始します。
-
グローバルエンドポイントのルーティングは、新しいプライマリに書き込みを送るよう自動的に更新されます。
-
新しい Global Topology ビューで確認できます。すべてのクラスターは RUNNING 状態に戻っているはずです。
-
新しいプライマリクラスター上でバックアップポリシーを再設定してください。バックアップポリシーは新しいプライマリに自動的には引き継がれません。
フェイルオーバーを実行する
プライマリリージョンで停止が発生し、プライマリクラスターが ABNORMAL 状態になっている場合は、フェイルオーバーを使用します。
フェイルオーバーは緊急操作です。スイッチオーバーとは異なり、完全なデータ同期を待ちません。プライマリでコミットされたものの、ターゲットのセカンダリにまだ複製されていない書き込みは失われます。データ損失量は、フェイルオーバー時点の同期遅延に等しくなります。
始める前に
-
プライマリクラスターに到達できず、ABNORMAL 状態であることを確認してください。
-
昇格するセカンダリクラスターを特定してください。複数のセカンダリが利用可能な場合は、同期遅延が最も小さいもの(プライマリの最新状態に最も近いもの)を選択してください。
手順
-
Web コンソールを使用する場合
次のデモでは、フェイルオーバーを実行する方法を示しています。
1Global Cluster ページに移動します。
2Switchover or Failover をクリックします。
3昇格するターゲットのセカンダリクラスターを選択します。
4Failover を選択します。
5ダイアログで操作を確認します。
📘注意フェイルオーバーが失敗した場合、クラスターは ABNORMAL 状態のままです。フェイルオーバー操作を再試行するか、サポートチケットを作成 できます。
-
RESTful API を使用する場合
次の例では、クラスター
in01-secondaryが強制的にプライマリに昇格されるようフェイルオーバーを実行します。API の詳細については、Failover Global Cluster を参照してください。bashcurl --request POST \--url "https://api.cloud.zilliz.com/v2/globalClusters/glo-xxxxxxxxxxxxxxxx/failover" \--header "Authorization: Bearer ${API_KEY}" \--header "Accept: application/json" \--header "Content-Type: application/json" \--data-raw '{"newPrimaryClusterId": "in01-secondary"}'次は出力例です。
bash{"code": 0,"data": {"globalClusterId": "glo-xxxxxxxxxxxxxxxx","oldPrimaryClusterId": "in01-primary","newPrimaryClusterId": "in01-secondary","jobId": "job-xxxxxxxxxxxxxxxx"}}
フェイルオーバー後
-
元のプライマリは破棄され、ごみ箱に移動されます。Global Topology ビューには表示されなくなります。
-
完全なグローバルトポロジーを復元するために、新しいセカンダリクラスターが自動的に作成されます。新しいセカンダリのプロビジョニング中は、グローバルトポロジーからは見えません。代わりに、グローバルクラスターのページに次のバナーが表示されます: "A new secondary cluster will be created and become available shortly."
-
残りのセカンダリクラスターもリビルドのために CREATING 状態に遷移し、リビルドが完了すると RUNNING になります。
-
グローバルエンドポイントは、新しいプライマリに書き込みを送るよう更新されます。
-
新しいプライマリクラスター上でバックアップポリシーを再設定してください。バックアップポリシーは新しいプライマリに自動的には引き継がれません。
ルーティング動作
次の表は、各操作の実行中および完了後にグローバルエンドポイントとパブリックエンドポイントがどのように動作するかをまとめたものです。
エンドポイントの種類 | スイッチオーバー中 | フェイルオーバー中 | 完了後 |
|---|---|---|---|
グローバルエンドポイント |
|
|
|
パブリックエンドポイント |
|
|
|
進行中のタスクへの影響
次の表は、スイッチオーバーおよびフェイルオーバー中に進行中のタスクがどのように処理されるかをまとめたものです。
| タスク | スイッチオーバー中 | フェイルオーバー中 |
|---|---|---|
| Backup | タスクは失敗します。スイッチオーバー完了後、新しいプライマリで自動的に再試行されます。 | タスクは失敗します。フェイルオーバー完了後、新しいプライマリで自動的に再試行されます。 |
| Query CU scaling | スケーリングの進行中はスイッチオーバーはブロックされます。 | タスクは失敗します。フェイルオーバー完了後に再試行されます。 |
| Replica scaling | スケーリングの進行中はスイッチオーバーはブロックされます。 | タスクは失敗します。フェイルオーバー完了後に再試行されます。 |