OceanBaseデータベースの高度な災害復旧機能を実現するために、ゾーンという概念が導入されました。ゾーンは論理的な概念であり、一般的には類似した災害復旧特性を持つノードの集合です。物理的なレベルでは、ゾーンは通常独立した物理的デプロイメント単位であり、データセンター（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 コマンドの制限事項は以下のとおりです：
複数のゾーンおよび複数のゾーンのノードを同時に停止することは許可されません。他のゾーンまたは他のゾーンのノードが既に停止されている場合、
STOP ZONEはエラー-4660，cannot stop server or stop zone in multiple zonesを返します。このエラーメッセージが表示された場合は、DBA_OB_SERVERSおよびDBA_OB_ZONESを照会して、ゾーンまたはノードが停止されていないか確認できます。STOP ZONEコマンドは、すべてのテナントのすべてのログストリームの Paxos メンバーリストをチェックし、ターゲットゾーンノードと他の非利用可能ノードを除いて、残りのノード上のレプリカが依然として Paxos の多数派を構成できるかどうかを確認します。多数派を構成できない場合は、STOP ZONE操作の実行は許可されません。非利用可能ノードには、
INACTIVE、stopped（ACTIVE状態でstop_timeフィールドが0より大きい場合）およびDELETING状態のノードが含まれます。ログストリームの Paxos メンバーリストをチェックするためには、すべてのログストリームにリーダーが存在する必要があります。ログストリームにリーダーが見つからない場合、エラー
-4179が返され、問題のログストリーム情報が表示されます。例：テナント
1001の1番ログストリームにリーダーがない場合、エラーメッセージはTenant(1001) LS(1) has no leader, stop zone not allowedとなります。このエラーメッセージが表示された場合は、GV$OB_LOG_STATビューを照会してログストリームのリーダーレプリカ情報を確認し、リーダーレプリカの異常を調査できます。テナントの Locality プロパティの変更が
STOP ZONEコマンドと同時に発生した場合、誤判断を防ぐため、Locality 変更中のSTOP ZONEは禁止されています。例：テナント
1001が Locality を変更してレプリカを1つ削減しており、ログストリームのメンバーリストが A、B、C から A、B に変わっているとき、もし B ノードが存在するゾーンを停止する必要がある場合、STOP ZONEコマンドは停止可能と誤判断し、レプリカ削減操作と競合する可能性があります。誤判断を避けるため、STOP ZONEコマンドはエラー-4179を返し、Tenant(1001) locality is changing, stop zone not allowedという変更中のテナント情報を表示します。このエラーメッセージが表示された場合は、DBA_OB_TENANTSビューを照会して、テナント Locality 変更操作が存在するか確認できます。ターゲットゾーンノードと他の非利用可能ノードを除外した後、残りのノード上のレプリカが多数派を満たせない場合、エラー
-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ビューを照会して、ログストリームのメンバーリストとレプリカ情報が多数派を満たしているか確認できます。
STOP ZONEは、正常に実行後に隔離されたゾーン内のノードに対して任意の侵入的操作を実行できることを保証します。つまり、残りの利用可能ノード上のレプリカが多数派を満たす前提の下で、残りの利用可能ノードの多数派レプリカのログが同期されていることも保証し、隔離されたゾーン内のノードがプロセスを停止した後でも、残りのノードのログが依然として多数派を形成できるようにします。ログ同期の判断条件：ログストリームのフォロワーレプリカとリーダーレプリカの最新ログポイントを比較し、ログポイントの差が5秒以内であればログが同期されているとみなします。
GV$OB_LOG_STATビューのEND_SCNフィールドを照会することで、指定したログストリームの各レプリカの最新ログポイントを取得できます。この条件を満たさない場合、エラー
-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;
注意事項：
FORCE STOP ZONEの後も対象ZoneノードがPaxosログ同期に引き続き参加し、対象Zoneノードが明確にオフラインにならない場合は、FORCE STOP ZONEを安全に使用して障害の隔離および業務トラフィックの切り替えを実現できます。一部のレプリカログが同期されていない場合でも、サービスの連続性には影響しません。ユーザーが
FORCE STOP ZONEの後に対象ノードをオフラインにしたい場合は、遅延レプリカが存在するログストリームの状況に注意し、対象ノードがオフラインになった後、そのログストリームのサービス提供に影響がないか確認する必要があります。また、GV$OB_LOG_STATビューをクエリすることで、サービスへの影響時間を評価できます。
警告
FORCE STOP ZONE は、隔離対象Zone内のノード以外にログ遅延があるノードが存在する場合にのみ適用されます。この場合、Zoneを隔離する目的は単に障害の隔離であり、プロセスの停止を引き起こす侵襲的な操作は一切行ってはなりません。そうでない場合、Paxosの多数派が崩れ、テナントが主を失い、データベースサービスの連続性に影響を与える可能性があります。
ISOLATE ZONE
STOP ZONE や FORCE STOP ZONE と比較して、ISOLATE ZONE の事前チェックは最も緩やかで、応答速度が最も速いです。ただし、安全性は保証されません。つまり、対象ゾーン内のノードがダウンした後でも、クラスタの残りノードのレプリカが Paxos の過半数を維持してサービスを継続できることは保証されません。
obclient [(none)]> ALTER SYSTEM ISOLATE ZONE zone_name;
ISOLATE ZONE コマンドの事前チェック緩和ロジックは以下の通りです：
ISOLATE ZONEコマンドは、複数ゾーンのノードを同時に隔離することを制限しなくなりました。他のゾーンのノードが既に隔離されている場合（いずれかの隔離コマンドを実行した場合）でも、ISOLATE ZONEコマンドを実行できます。典型的なシナリオ：クラスタに3つのゾーン（Z1、Z2、Z3）があり、Z1とZ3の各1つのノードに障害が発生し、隔離が必要です。Z1の障害ノードの隔離に成功した後、
STOP ZONEまたはFORCE STOP ZONEコマンドを使用してZ3の障害ノードを隔離しようとすると、複数ゾーンの同時隔離は許可されないというエラーが発生します。この場合、ISOLATE ZONEコマンドのみを実行し、障害ノードから業務トラフィックを切り替えることができます。隔離後は、プロセスの停止を引き起こす可能性のある侵入的な操作は一切行えません。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 ビューに記載されている既に隔離されたゾーンとノードの情報と照合することで、上記の制限条件を破っていないか確認できます。
警告
ISOLATE ZONE は、隔離対象ゾーン内のノード以外に他のノードの状態異常が存在するシナリオにのみ適用されます。この場合、ゾーンを隔離する目的は単に障害隔離であり、プロセスの停止を引き起こす可能性のある侵入的な操作は一切行えません。そうでない場合、Paxosの過半数が崩れ、テナントが主を失い、データベースサービスの連続性に影響を与えます。
まとめ
どのシナリオにおいても、最初に選択すべきは STOP ZONE コマンドです。正常に実行されれば、障害隔離の目的を達成するだけでなく、隔離されたゾーン内のノードに対して安全に緊急処置や運用保守操作を実行できることも保証されます。STOP ZONE が成功しない場合は、弱化版のゾーン隔離コマンドを選択できますが、弱化版のゾーン隔離後は、侵入的な操作を安全に実行できる保証はありません。
FORCE STOP ZONE は、隔離対象ゾーン内のノード以外に他のノードのログが遅延しているシナリオに適用されます。ISOLATE ZONE は、隔離対象ゾーン内のノード以外に他のノードの状態異常が存在するシナリオに適用されます。この場合、ゾーンを隔離する目的は単に障害隔離であり、プロセスの停止を引き起こす可能性のある侵入的な運用保守操作は一切行えません。そうでない場合、Paxosの過半数が崩れ、テナントが主を失い、データベースサービスの連続性に影響を与えます。
関連ドキュメント
その他のゾーン関連の運用保守操作については、以下の情報を参照してください：