ノードの隔離

ノードに異常が発生したり、運用保守上の変更が必要な場合、そのノードを隔離できます。隔離後は、新規の読み書きリクエストがそのノードにルーティングされなくなるため、障害の隔離や運用保守上の変更をロスレスで実行することが可能です。

• 故障隔離シナリオ：ノードに異常が発生した場合、異常ノードを業務トラフィックから隔離する必要があります。例えば、あるデータセンター内のスイッチに異常が発生した場合、特定のノードでパケット損失、再送信、さらにはリーダーが選出されない状態が発生することがあります。迅速な復旧のために、これらの異常ノードを直接隔離できます。ノードが復旧したら、Start操作を実行してノードのトラフィックを回復します。

• 運用保守変更シナリオ：ノードに運用保守上の変更が必要な場合、業務トラフィックへの影響を無くし透過的である必要があります。例えば、特定のノードサーバーの再起動が必要な場合、再起動中に業務トラフィックに影響を与えないようにするために、ノード隔離操作を実行し、再起動対象サーバー上の業務トラフィックを他のノードに切り替えることができます。再起動操作が完了したら、Start操作を実行してノードのトラフィックを回復します。

ノードを隔離するとは、業務トラフィックをそのノードから切り替えるだけであり、Paxos投票メンバーの数は変更されません。隔離コマンドによりセキュリティレベルの保証が異なるため、実行する具体的な隔離コマンドに基づいて、その後安全に実行できる操作を慎重に検討する必要があります。隔離コマンドは短期間の隔離シナリオに適しており、継続的に注意を払い、二次障害に備えた緊急対応計画を事前に準備する必要があります。短期間で復旧できない場合は、ノードの置換によって根本的にリスクを排除することができます。ノードの置換に関する詳細な操作については、ノードの置換を参照してください。

ノードを隔離するには、以下の3種類のコマンドがあり、隔離コマンドによりセキュリティレベルの保証が異なります：

• STOP SERVER コマンドでノードを隔離する

• FORCE STOP SERVER コマンドでノードを隔離する

• ISOLATE SERVER コマンドでノードを隔離する

上記のコマンドでノードを正常に隔離した後、隔離されたノードの STATUS フィールドは引き続き ACTIVE のまま変わりませんが、STOP_TIME フィールドの値は NULL から隔離操作の時点に変わり、そのノードが Stopped 状態にあることを示します。

STOP SERVER

コマンドのフォーマットは以下のとおりで、一度に複数のserverをStopすることができます。

obclient [(none)]> ALTER SYSTEM STOP SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

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

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

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

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

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

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

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

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

   3. テナントの Locality 属性変更コマンドと STOP SERVER コマンドが同時実行される場合、誤判断を防ぐため、Locality 変更中はノードのStopを禁止します。

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

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

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

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

   1. ログ同期の判断条件：ログストリームのFollowerレプリカとLeaderレプリカの最新のログポイントを比較し、ログポイントの差が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 SERVER は最も安全な隔離コマンドですが、同時にその前提条件も最も厳格です。実際の運用では、特に障害緊急時には、上記の前提条件を完全に満たせない場合があり、結果として STOP SERVER コマンドが正常に実行できないことがあります。そのため、OceanBase データベースは、FORCE STOP SERVER と ISOLATE SERVER という2つの別のノード隔離コマンドを提供しています。これらは事前チェックを緩和し、制限を減らすことで、より多くのシナリオでノードの隔離を成功させることができますが、ノードが隔離された後の操作には制限があります。どのようなシナリオでも、 STOP SERVER コマンドを第一選択とする必要があります。STOP SERVER が成功しない場合にのみ、弱化版のノード隔離コマンドを選択できますが、弱化版のノード隔離後に実行できる操作は制限されます。

FORCE STOP SERVER

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

FORCE STOP SERVER の典型的なユースケース：ノードA、B、Cの3つのノードがあり、ノードBのレプリカログに1時間ほどの大きな遅延が発生しています。この時、ノードCでハードウェア異常が発生し、停止してメンテナンスが必要になりました。隔離後にプロセスを安全に停止するために、まずは STOP SERVER コマンドでノードを隔離するのが最適です。しかし、ノードBのレプリカログに遅延があるため、STOP SERVER コマンドは正常に実行できません。そのため、次善の策として FORCE STOP SERVER コマンドを使用してノードを隔離し、まずハードウェア異常が業務トラフィックに影響を与えるのを防ぎます。その後、ノードBのログ遅延の原因を調査し、ノードBのログがリアルタイムに戻ったら再度 STOP SERVER コマンドを実行します。正常に実行されれば、安全に停止してメンテナンスを行うことができます。

obclient [(none)]> ALTER SYSTEM FORCE STOP SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

ISOLATE SERVER

STOP SERVER および FORCE STOP SERVER と比較して、ISOLATE SERVER の事前チェックは最も緩やかで、応答速度が最も速いですが、セキュリティを保証するものではありません。つまり、ターゲットノードがダウンした後でも、クラスタの残りのノードのレプリカが Paxos の多数派を維持し、サービスを継続できることを保証するものではありません。

obclient [(none)]> ALTER SYSTEM ISOLATE SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

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

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

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

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

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

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

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

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

まとめ

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

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

関連ドキュメント

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

• ノードの確認

• ノードの再起動

• ノードの追加

• ノードの削除

• ノードの置換