Zoneの分離

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

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

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

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

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

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

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

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

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

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

STOP ZONE

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

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

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

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

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

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

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

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

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

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

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

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

   4. ターゲットZoneノードと他の非利用可能ノードを除外した後、残りのノード上のレプリカが多数派にならない場合、エラー -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 は、実行成功後にも、隔離されたZone内のノードに対して任意の侵入的操作を実行できることを保証します。つまり、残りの利用可能ノード上のレプリカが多数派を満たす前提の下で、残りの利用可能ノードの多数派レプリカのログが同期されていることも保証され、隔離された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 データベースはFORCE STOP ZONE と ISOLATE ZONEという 2 種類のZone隔離コマンドを提供しています。これらはそれぞれが別のレベルで前提チェックを緩和し、制限を減らすことで、より多くのシナリオでZoneの隔離を成功させることができますが、Zoneが隔離された後の操作には制限があります。どのようなシナリオにおいても、まずは STOP ZONE コマンドを選択する必要があります。STOP ZONE が成功しない場合は、弱化版のZone隔離コマンドを選択可能ですが、弱化版のZone隔離後に実行できる操作には制限があります。

FORCE STOP ZONE

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

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

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

注意事項：

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

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

ISOLATE ZONE

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

関連ドキュメント

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

• Zoneの確認

• Zoneの追加

• Zoneの削除

• Zoneの変更

• ノードの分離