マイノリティノードの障害

このセクションでは、マイノリティノードの障害に対する処理フローについて説明します。

背景

OceanBaseデータベースは分散型データベースであり、典型的なデプロイメントパターンはマルチレプリカアーキテクチャです。この章では、いずれのログストリームにも影響を与えない多数派レプリカを持つノードの障害についてのみ説明します。例えば、3レプリカ構成では、任意の1つのノードが障害を起こしても多数派に影響はありません。5レプリカ構成では、任意の2つのノードが障害を起こしても多数派に影響はありません。一部のログストリームでレプリカが欠落している場合、予想されるノード障害許容度より少ない障害でも多数派に影響を与える可能性があります。このようなシナリオについては、多数派ノード障害を参照してください。

一般的なノード障害には主に以下のものがあります：

• ノードのハードウェア異常によりダウンする場合。

• ノードのハードウェア異常によりダウンはしないものの、そのノード上のobserverプロセスが異常終了する場合。例えば、ホストメモリの障害によりobserverプロセスがクラッシュする場合。

• ノードのハードウェア異常によりダウンはしないものの、そのノード上のobserverプロセスの状態が異常になる場合。例えば、I/O異常によりobserverプロセスの読み書きリクエストがタイムアウトする場合。

• ノードのハードウェア異常によりダウンはしないものの、そのノード上のobserverプロセスがSSTableまたはRedoLogに書き込むデータに誤りが生じ、その後のChecksum検証でそれが検出される場合。

• OceanBaseデータベースのバグによりobserverプロセスが異常を起こす場合。例えば、スレッドが停止したり、メモリ上限を超えたり、プロセスがクラッシュしたりする異常が発生する場合。

手順

OceanBaseデータベースのバグがobserverプロセスの異常を引き起こした場合、まずは該当ノードを速やかに隔離する必要があります。ノードの隔離に関する操作については、ノードの隔離を参照してください。サービスへの影響がない場合は、現場を維持したままOceanBaseのテクニカルサポートに連絡し、対応を依頼できます。サービスに影響が出ている場合は、速やかにプロセスを再起動または再開してから、OceanBaseのテクニカルサポートに連絡し、対応を依頼する必要があります。

ハードウェアの異常がノードの異常を引き起こした場合、またはハードウェア異常が疑われる場合は、異常なノードを隔離して交換する必要があります。具体的な操作手順は以下のとおりです：

1. rootユーザーでクラスタのsysテナントにログインします。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に合わせてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

   データベース接続に関するより詳細な操作ガイドについては、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。

2. 異常なノードに対して、できるだけ早くStop ServerまたはForce Stop Server操作を実行し、業務トラフィックへの影響を避けるため、実行が成功したことを確認します。

   Stop Serverのステートメントは以下のとおりです：

   obclient [(none)]> ALTER SYSTEM STOP SERVER 'svr_ip:svr_port';
   

   例：

   obclient [(none)]> ALTER SYSTEM STOP SERVER '172.xx.xx.xx:2882';
   

   Force Stop Serverのステートメントは以下のとおりです：

   obclient [(none)]> ALTER SYSTEM FORCE STOP SERVER 'svr_ip:svr_port';
   

   例：

   obclient [(none)]> ALTER SYSTEM FORCE STOP SERVER 172.xx.xx.xx:2882';
   

   Stop ServerおよびForce Stop Server操作の内部実行プロセスに関する情報については、ノードの隔離を参照してください。

3. 異常なノードが存在するZoneにノードを追加します。

   ノードの追加に関する具体的な操作については、ノードの追加を参照してください。

4. 新規ノード上で、異常なノード上のレプリカを補完します。

   以下の3つのシナリオに分類されます：

   • observerプロセスが既に終了している場合。

     主動的にUnit移行を開始することも、Root Serviceが自動的にUnit移行を開始するのを待つこともできます。observerプロセスが終了してから永続的なオフライン時間を超えると、Root Serviceは自動的にUnit移行を開始します。永続的なオフライン時間はシステムパラメータserver_permanent_offline_timeによって制御され、同時にシステムパラメータenable_rereplicationが有効な状態であることを確認する必要があります。

     手動でUnit移行を開始する操作については、Unit移行を参照してください。

   • 異常なノード上のデータエラー、またはプロセス状態の異常により移行Unit操作が停止している場合、またはプロセス状態の異常によりグローバル状態が異常になっている場合（例：マージが停止している場合）。

     observerプロセスを手動でkillし、その後、最初のシナリオ（observerプロセスが既に終了している場合）の処理を参照して対処できます。

   • ハードウェアの潜在的な問題があり、クラスタ全体の状態に異常を引き起こさない場合。

     このシナリオではobserverプロセスをKillする必要はありません（observerをKillした後にクラスタのリスクエクスポージャーが大きくなるのを避けるため）。主動的にUnit移行を開始し、異常なノード上のUnitをすべて新規ノードに移行できます。

     手動でUnit移行を開始する操作については、Unit移行を参照してください。

   説明

   常に主動的にUnit移行を開始することを推奨します：

   • 主動的な移行により、異常なノード上のすべてのUnitを新規ノードに移行することができ、Root Serviceが自動的に開始するのを防ぎ、元のUnitトポロジー構造を維持し、ノード間のバランスを崩すことを避けることができます。
   • Root Serviceが自動的にUnit移行を開始する場合、プロセスが終了してから永続的なオフライン時間を超えるまで待機する必要があり、ノード異常のリスクエクスポージャーが高まります。
   • 主動的にUnit移行を開始することで、移行トラフィックがクラスタリソースに占める割合をリアルタイムで監視し、アプリケーショントラフィックへの影響を避けることができます。

     ノード異常を発見した際、ノードの終了から永続的なオフライン時間を超えており、かつRoot Serviceが既にUnit移行を自動的に開始している場合は、移行後のトポロジー構造を観察し、移行トラフィックがクラスタリソースに占める割合を確認し、ビジネス担当者への連携を適切に行う必要があります。

5. 操作終了後、oceanbase.DBA_OB_UNIT_JOBSビューでデータ補完の進捗状況を確認できます。

   obclient [(none)]> SELECT * FROM oceanbase.DBA_OB_UNIT_JOBS WHERE JOB_TYPE = 'MIGRATE_UNIT';
   +--------+--------------+------------+-------------+----------+----------------------------+----------------------------+-----------+---------+----------+------------+------------+-------------+
   | JOB_ID | JOB_TYPE     | JOB_STATUS | RESULT_CODE | PROGRESS | START_TIME                 | MODIFY_TIME                | TENANT_ID | UNIT_ID | SQL_TEXT | EXTRA_INFO | RS_SVR_IP  | RS_SVR_PORT |
   +--------+--------------+------------+-------------+----------+----------------------------+----------------------------+-----------+---------+----------+------------+------------+-------------+
   |      4 | MIGRATE_UNIT | INPROGRESS |        NULL |        0 | 2023-01-04 17:22:02.208219 | 2023-01-04 17:22:02.208219 |      1004 |    1006 | NULL     | NULL       |xx.xx.xx.238|        2882 |
   +--------+--------------+------------+-------------+----------+----------------------------+----------------------------+-----------+---------+----------+------------+------------+-------------+
   

   クエリ結果が空の場合、Unit移行が完了し、データ補完が成功したことを意味します。

6. 異常なノード上のUnitが新規ノード上で補完された後、異常なノードを削除します。

   ノードの削除に関する具体的な操作については、ノードの削除を参照してください。