ゾーンの分離

OceanBaseデータベースの高度な災害復旧機能を実現するために、ゾーンという概念が導入されました。ゾーンは論理的な概念であり、一般的には類似した災害復旧特性を持つノードの集合です。物理的なレベルでは、1つのゾーンは通常独立した物理的デプロイメント単位であり、データセンター（IDC）やクラウド上のアベイラビリティゾーン、あるいは単独のラック（Rack）であることがあります。OceanBaseクラスタを複数のゾーン（通常は少なくとも3つのゾーン）に展開することで、単一のゾーンで障害が発生した場合のフォールトアイソレーションと迅速な復旧を実現します。

ゾーンレベルの災害復旧やゾーンレベルの運用保守変更が必要な場合、ゾーンを分離することができます。分離後、新しい読み書きリクエストはそのゾーン内のノードにルーティングされなくなるため、障害を隔離したり、無損失で運用保守変更を実行したりできます。

• フォールトアイソレーションのシナリオ：例えば、複数データセンター構成のアーキテクチャにおいて、あるデータセンター内のスイッチに異常が発生した場合、一部のノードでパケットロス、再送信、さらには選挙の主が決まらない（エレクトが行われない）状況が発生することがあります。迅速な復旧のために、そのデータセンターに対応するゾーンを直接分離することができます。

• 運用保守変更のシナリオ：例えば、OceanBaseクラスタのアップグレード時に採用されるローテーションアップグレード方式では、まず1つのゾーンを分離し、ユーザーのトラフィックをそのゾーンから他のゾーンに切り替えた後、アップグレードを実行します。そのゾーンのアップグレードが完了したらStart操作を実行してトラフィックを復旧し、次に他のゾーンを順次アップグレードすることで、アップグレードをユーザーに対して透過的に行うことができます。

ゾーンを分離するとは、ユーザーのトラフィックをそのゾーンから切り替えるだけであり、Paxos投票メンバーの数は変更されません。異なる分離コマンドは異なるセキュリティレベルを保証しており、実行する具体的な分離コマンドに基づいて、その後安全に実行できる操作を慎重に検討する必要があります。分離コマンドは短期間の分離シナリオに適しており、継続的に注意を払い、二次障害に対する緊急対策を事前に準備する必要があります。短期間で復旧できない場合は、代替ゾーンを使用する方法で根本的にリスクを排除することができます。

ゾーンを分離するには以下の3つのコマンドがあり、異なる分離コマンドは異なるセキュリティレベルを保証しています：

• STOP ZONE コマンドでゾーンを分離する

• FORCE STOP ZONE コマンドでゾーンを分離する

• ISOLATE ZONE コマンドでゾーンを分離する

上記のコマンドでゾーンを正常に分離すると、ゾーンの STATUS の値が INACTIVE に変わり、そのゾーンが分離状態にあることを示します。

STOP ZONE

コマンドの書式は以下のとおりです：

obclient [(none)]> ALTER SYSTEM STOP ZONE 'zone_name';

STOP ZONE は最も安全なゾーン隔離コマンドです。STOP Zone は、業務トラフィックをそのゾーンから切り離し、ゾーン内ノードと業務トラフィックを隔離する効果を実現するだけでなく、隔離されたゾーン以外の他のゾーンのノードが依然として Paxos の多数派を構成できることを保証します。これにより、隔離されたゾーンのノードに対して pstack、ログレベルの調整などの任意の操作、さらにはプロセスの停止を安全に実行できます。STOP ZONE は、障害隔離と停止メンテナンスが必要なシナリオに適しており、障害隔離と運用変更における第一選択の隔離コマンドです。

成功した実行後に隔離されたゾーン内のノードに対して任意の操作を安全に実行できるようにするため、STOP ZONE コマンドの事前検出は比較的厳格であり、内部の様々な状態チェックを通じて、ターゲットノードでプロセスを停止した後でも、クラスタの残りの利用可能ノードのレプリカが依然として Paxos の多数派を構成できることを保証し、データベースサービスの連続性に影響を与えないようにします。

STOP ZONE コマンドの制限事項は以下のとおりです：

1. 同時に複数のゾーンおよび複数のゾーンのノードを Stop することは許可されません。他のゾーンまたは他のゾーンのノードが既に Stop されている場合、STOP ZONE はエラー -4660，cannot stop server or stop zone in multiple zones を返します。このエラーメッセージが表示された場合は、DBA_OB_SERVERS および DBA_OB_ZONES を照会して、ゾーンまたはノードが Stop されていないか確認できます。

2. STOP ZONE コマンドは、すべてのテナントのすべてのログストリームの Paxos メンバーリストをチェックし、ターゲットゾーンノードと他の非利用可能ノードを除いて、残りのノード上のレプリカが依然として Paxos の多数派を構成できるかどうかを確認します。多数派を構成できない場合は、STOP ZONE 操作の実行は許可されません。

   1. 非利用可能ノードには、INACTIVE、stopped（ACTIVE 状態で stop_time フィールドが 0 より大きい場合）および DELETING 状態のノードが含まれます。

   2. ログストリームの Paxos メンバーリストをチェックするためには、すべてのログストリームにリーダーが存在する必要があります。ログストリームにリーダーが見つからない場合、エラー -4179 が返され、問題のログストリーム情報が表示されます。

      例：テナント 1001 の 1 号ログストリームにリーダーがない場合、エラーメッセージは Tenant(1001) LS(1) has no leader, stop zone not allowed となります。このエラーメッセージが表示された場合は、GV$OB_LOG_STAT ビューを照会してログストリームのリーダーレプリカ情報を確認し、リーダーレプリカの異常を調査できます。

   3. テナントの Locality プロパティの変更が STOP ZONE コマンドと同時に発生した場合、誤判断を防ぐため、Locality 変更中の STOP ZONE は禁止されています。

      例：テナント 1001 が Locality を変更してレプリカを 1 つ削減しており、ログストリームのメンバーリストが A、B、C から A、B に変化しているとき、もし B ノードが存在するゾーンを Stop する必要がある場合、STOP ZONE コマンドは Stop が可能と誤判断し、レプリカ削減操作と競合する可能性があります。誤判断を避けるため、STOP ZONE コマンドはエラー -4179 を返し、Tenant(1001) locality is changing, stop zone not allowed というメッセージを表示します。このエラーメッセージが表示された場合は、DBA_OB_TENANTS ビューを照会して、テナントの Locality 変更操作が存在するか確認できます。

   4. ターゲットゾーンノードと他の非利用可能ノードを除外した後、残りのノード上のレプリカが多数派を満たせない場合、エラー -4179 が返され、問題のログストリーム情報が表示されます。

      例：テナント 1001 の 1 号ログストリームが STOP ZONE 後に多数派を満たせない場合、エラーメッセージは Tenant(1001) LS(1) has no enough valid paxos member after stop zone, stop zone not allowed となります。このエラーメッセージが表示された場合は、GV$OB_LOG_STAT ビューを照会して、ログストリームのメンバーリストとレプリカ情報が多数派を満たしているか確認できます。

3. STOP ZONE は、成功した実行後にも、隔離されたゾーン内のノードに対して任意の侵入的操作を実行できることを保証します。つまり、残りの利用可能ノード上のレプリカが多数派を満たす前提の下で、残りの利用可能ノードの多数派レプリカのログが同期されていることも保証され、隔離されたゾーン内のノードがプロセスを停止した後でも、残りのノードのログが依然として多数派を形成できるようにします。

   1. ログ同期の判断条件：ログストリームのフォロワーレプリカとリーダーレプリカの最新ログ時刻を比較し、ログ時刻の差が 5 秒以内であればログは同期されているとみなします。GV$OB_LOG_STAT ビューの END_SCN フィールドを照会することで、指定されたログストリームの各レプリカの最新ログ時刻を取得できます。

   2. この条件を満たさない場合、エラー -4179 が返され、問題のログストリーム情報が表示されます。

      例：テナント 1001 の 1 号ログストリームのログが同期されていない場合、エラーメッセージは Tenant(1001) LS(1) log not sync, stop server not allowed となります。このエラーメッセージが表示された場合は、GV$OB_LOG_STAT ビューの END_SCN フィールドを照会してログストリームレプリカの同期状況を確認できます。

   # 指定されたログストリームレプリカの最新ログ時刻情報を取得し、タイムスタンプ形式に変換する
   obclient [(none)]> SELECT SCN_TO_TIMESTAMP(END_SCN) FROM GV$OB_LOG_STAT WHERE TENANT_ID = 1001 and LS_ID = 1;
   

STOP ZONE は最も安全なゾーン隔離コマンドですが、同時にその前提条件も最も厳格です。実際の運用において、特に障害緊急時のシナリオでは、上記の前提条件を完全に満たせない場合があり、その結果 STOP ZONE コマンドが正常に実行できないことがあります。そのため、OceanBase データベースは他の 2 種類のゾーン隔離コマンドを提供しています：FORCE STOP ZONE と ISOLATE ZONE。これらはそれぞれ異なる程度で前提チェックを緩和し、制限を減らすことで、より多くのシナリオでゾーンの隔離を成功させることができますが、ゾーンが隔離された後の操作には制限があります。どのようなシナリオにおいても、まずは STOP ZONE コマンドを選択すべきです。STOP ZONE が成功しない場合は、弱化版のゾーン隔離コマンドを選択できますが、弱化版のゾーン隔離後に実行できる操作には制限があります。

FORCE STOP ZONE

STOP ZONE コマンドと比較して、FORCE STOP ZONE コマンドはログ同期チェックをスキップします。FORCE STOP ZONE コマンドは、隔離されたゾーン内のノードから業務トラフィックを切り離すことを保証しますが、隔離されたゾーン内のノードが安全にプロセスを停止できることは保証しません。プロセスを強制的に停止すると、Paxosの多数派が崩れ、データベースサービスの継続性に影響を与える可能性があります。

FORCE STOP ZONE の典型的なユースケース：あるデータセンター内のサーバーやネットワーク機器にハードウェア異常が発生し、停止してメンテナンスが必要な場合です。隔離後にプロセスを安全に停止するために、通常は STOP ZONE コマンドでデータセンターに対応するゾーンを隔離します。しかし、他のゾーン内のノードのレプリカログに大きな遅延があり、STOP ZONE コマンドが正常に実行できない場合があります。その場合は、次善の策として FORCE STOP ZONE コマンドを使用してゾーンを隔離し、まずハードウェア異常が業務トラフィックに影響を与えるのを防ぎます。その後、レプリカログの遅延原因を調査し、レプリカログがリアルタイムになったら再度 STOP ZONE コマンドを実行し、正常に実行されれば安全に停止してメンテナンスを行えます。

obclient [(none)]> ALTER SYSTEM FORCE STOP ZONE zone_name;

注意事項：

1. FORCE STOP ZONE の後も対象ゾーンのノードが引き続きPaxosログ同期に参加し、対象ゾーンのノードが明確にオフラインにならない場合、FORCE STOP ZONE を安全に使用して障害の隔離および業務トラフィックの切り替えを実現できます。一部のレプリカログが同期しなくても、サービスの継続性には影響しません。

2. ユーザーが FORCE STOP ZONE の後に対象ノードをオフラインにしたい場合は、遅延レプリカが存在するログストリームの状況に注意し、対象ノードがオフラインになった後、そのログストリームがサービス提供に影響を与えるかどうかを確認する必要があります。また、GV$OB_LOG_STAT ビューをクエリすることで、サービスへの影響時間を評価できます。

ISOLATE ZONE

STOP ZONE および FORCE STOP ZONE と比較して、ISOLATE ZONE の事前チェックは最も緩やかで、応答速度が最も速いです。ただし、安全性は保証されません。つまり、対象ゾーン内のノードがダウンした後でも、クラスタの残りノードのレプリカが Paxos の多数派を維持し、サービスを継続できることは保証されません。

obclient [(none)]> ALTER SYSTEM ISOLATE ZONE zone_name;

ISOLATE ZONE コマンドの事前チェック緩和ロジックは以下の通りです：

1. ISOLATE ZONE コマンドは、複数のゾーンのノードを同時に隔離することを制限しなくなりました。他のゾーンのノードが既に隔離されている場合（いずれかの隔離コマンドを実行した場合でも）、ISOLATE ZONE コマンドを実行できます。

   典型的なシナリオ：クラスタに3つのゾーン（Z1、Z2、Z3）があり、Z1とZ3の各ゾーンで1つずつノードに障害が発生し、隔離が必要です。Z1の障害ノードを隔離した後、STOP ZONE または FORCE STOP ZONE コマンドを使用してZ3の障害ノードを隔離しようとすると、複数のゾーンを同時に隔離できないというエラーが発生します。この場合、ISOLATE ZONE コマンドのみを実行し、障害ノードから業務トラフィックを切り替えることができます。隔離後は、プロセスの停止を引き起こす可能性のある侵襲的な操作は一切行えません。

2. ISOLATE ZONE コマンドは、ログストリームレプリカの多数派やログ同期状況をチェックしなくなりました。該当条件を満たさなくても、ISOLATE ZONE コマンドを実行できます。

   典型的なシナリオ：ログストリームの初期のPaxosメンバーリストはA、B、Cの3つのノードでしたが、Cノードのマシンがダウンして永久にオフラインとなり、ログストリームのメンバーリストはA、Bに変更され、レプリカ不足状態となりました。この時、Bノードでハードウェア障害が発生し、そのノードが存在するゾーンを隔離したい場合、STOP ZONE および FORCE STOP ZONE はどちらも失敗し、「残りのレプリカが多数派を満たしていない」というエラーが発生します。この場合、ISOLATE ZONE コマンドのみを実行し、障害ノードから業務トラフィックを切り替えることができます。隔離後は、プロセスの停止を引き起こす可能性のある侵襲的な操作は一切行えません。

ISOLATE ZONE コマンドの制限事項は以下の通りです：

複数のゾーンノードが隔離された場合、ISOLATE ZONE はすべてのテナントのPrimary Zone属性をチェックし、テナントのPrimary Zoneが存在する地域のすべてのゾーンを同時に隔離することはできないと要求します。これは、テナントの読み書きサービスが他の地域に切り替わり、結果としてビジネスリクエストが異なる都市間をアクセスする際の所要時間が大幅に増加するのを防ぐためです。

DBA_OB_TENANTS ビューでテナントのPrimary Zone属性を確認し、DBA_OB_ZONES および DBA_OB_SERVERS ビューに記載されている既に隔離されたゾーンとノードの情報と照合することで、上記の制限条件を破っていないか確認できます。

まとめ

どのシナリオにおいても、まずは STOP ZONE コマンドを選択すべきです。正常に実行されれば、障害隔離の目的を達成するだけでなく、隔離されたゾーン内のノードに対して安全に緊急処置や運用保守操作を実行できることも保証されます。STOP ZONE が成功しない場合は、弱化版のゾーン隔離コマンドを選択できますが、弱化版のゾーン隔離後は、侵襲的操作を安全に実行できる保証はありません。

FORCE STOP ZONE は、隔離対象ゾーン内のノード以外に他のノードのログが遅延しているシナリオに適用されます。ISOLATE ZONE は、隔離対象ゾーン内のノード以外に他のノードの状態異常が存在するシナリオに適用されます。この場合、ゾーンを隔離する目的は単に障害隔離であり、プロセスの停止を引き起こす可能性のある侵襲的な運用保守操作は一切行えません。そうでない場合、Paxosの多数派が崩れ、テナントが主を失い、データベースサービスの連続性に影響を与える可能性があります。

関連ドキュメント

その他のゾーン関連の運用操作については、以下を参照してください：

• ゾーンの確認

• ゾーンの追加

• ゾーンの削除

• ゾーンの変更

• ノードの分離