ノードの分離

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

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

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

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

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

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

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

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

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

STOP SERVER

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

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. 同時に複数のゾーンのノードを停止することは許可されません。複数のゾーンのノードを同時に停止した場合、または他のゾーンのノードが既に停止されている場合、-4660, cannot stop server or stop zone in multiple zones エラーが発生します。このエラーメッセージが表示された場合は、DBA_OB_SERVERS および DBA_OB_ZONES ビューをクエリして、複数のゾーンのノードが停止されていないか確認できます。

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

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

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

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

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

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

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

      例：テナント 1001 の1号ログストリームがノード停止後に多数派を満たせない場合、エラーメッセージは 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. ログ同期の判断条件：ログストリームのフォロワーレプリカとリーダーレプリカの最新ログ時刻を比較し、ログ時刻の差が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の2つに変わり、レプリカ不足の状態となりました。この時、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の多数派が崩れ、テナントが主を失い、データベースサービスの継続性に影響を与える可能性があります。

関連情報

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

• ノードの確認

• ノードの再起動

• ノードの追加

• ノードの削除

• ノードの置換