ノードの隔離

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

• 障害隔離シナリオ：ノードに異常が発生した場合、異常ノードを業務トラフィックから隔離する必要があります。例えば、あるデータセンター内のスイッチに異常が発生した場合、一部のノードでパケットロス、再送信、さらにはプライマリ選出が行われないという現象が起こります。迅速な復旧のために、これらの異常ノードを直接隔離することができます。ノードが復旧したら、Start操作を実行してノードのトラフィックを再開します。

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

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

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

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

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

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

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

STOP 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メンバーリストをチェックするためには、すべてのログストリームにリーダーが存在する必要があります。ログストリームにリーダーが存在しない場合、エラー -4179 が報告され、問題のあるログストリーム情報が表示されます。

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

   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. ログ同期の判断条件：ログストリームのフォロワーレプリカとリーダーレプリカの最新のログポイントを比較し、ログポイントの差が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 コマンドは、複数のゾーンのノードを同時に隔離することを制限しなくなりました。他のゾーンのノードがすでに隔離されている場合（いずれかの隔離コマンドを実行した場合）、ISOLATE SERVER コマンドを実行することができます。

   典型的なシナリオ：クラスタには3つのゾーン（Z1、Z2、Z3）があり、Z1とZ3にそれぞれ1つのノードが障害を起こし、隔離が必要です。Z1の障害ノードの隔離が成功した後、STOP SERVER または FORCE STOP SERVER コマンドを使用してZ3の障害ノードを隔離しようとすると、複数のゾーンを同時に隔離することは許可されないというエラーが表示されます。この場合、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 コマンドの制限は以下の通りです：

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

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

まとめ

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

FORCE STOP SERVER は、隔離対象ノード以外に他のノードのログ遅延が存在する場合に適用されます。ISOLATE SERVER は、隔離対象ノード以外に他のノードの状態異常が存在する場合に適用されます。この場合、ノードを隔離する目的は単に障害隔離であり、プロセスの停止を引き起こすような侵襲的な運用保守操作を一切行ってはなりません。そうしないと、Paxosの過半数が破壊され、テナントが無主となり、データベースサービスの連続性に影響を与えます。

関連ドキュメント

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

• ノードの表示

• ノードの再起動

• ノードの追加

• ノードの削除

• ノードの置き換え