ゾーンの分離

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 コマンドの制限は以下のとおりです：

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. テナントのローカリティ属性の変更が STOP ZONE コマンドと同時に発生した場合、誤判断を防ぐために、ローカリティ変更中の STOP ZONE は禁止されています。

      例：テナント 1001 がローカリティを変更してレプリカを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 ビューを照会して、テナントのローカリティ変更操作が存在するかどうかを確認できます。

   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の過半数が破壊され、テナントがホストレスになり、データベースサービスの継続性に影響を与えます。

関連ドキュメント

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

• Zoneの表示

• Zoneの追加

• Zoneの削除

• Zoneの変更

• ノードの分離