この記事では、マイノリティノードの障害に対する処理フローについて説明します。
背景
OceanBaseデータベースは分散型データベースであり、典型的なデプロイモードはマルチレプリカアーキテクチャです。この章では、いずれのログストリームにも影響を与えない多数派レプリカのノード障害についてのみ説明します。例えば、3レプリカ構成では、任意の1つのノードが障害を起こしても多数派には影響しません。また、5レプリカ構成では、任意の2つのノードが障害を起こしても多数派には影響しません。ただし、一部のログストリームで既にレプリカが不足している場合、予想されるノード障害許容度より少ない数の障害でも多数派に影響を与える可能性があります。このシナリオについては、多数派ノード障害を参照してください。
一般的なノード障害には主に以下のものがあります：
ノードのハードウェア異常によりダウンする。
ノードのハードウェア異常によりダウンすることはありませんが、そのノード上のobserverプロセスが異常終了する。例えば、ホストメモリ障害によりobserverプロセスがクラッシュする。
ノードのハードウェア異常によりダウンすることはありませんが、そのノード上のobserverプロセスの状態が異常になる。例えば、I/O異常によりobserverプロセスの読み書きリクエストがタイムアウトする。
ノードのハードウェア異常によりダウンすることはありませんが、そのノード上のobserverプロセスがSSTableやRedoLogへのデータ書き込みに誤りが生じ、その後のチェックサム検証で検出される。
OceanBaseデータベースのバグによりobserverプロセスが異常を起こす。例えば、スレッドがフリーズしたり、メモリ上限を超えたり、プロセスがクラッシュしたりする。
操作手順
OceanBaseデータベースのバグによりobserverプロセスが異常を起こした場合、まずは速やかにノードを隔離する必要があります。ノードの隔離に関する操作については、ノードの隔離を参照してください。サービスへの影響がない場合は、現場を維持し、OceanBaseテクニカルサポートに連絡して対応を依頼できます。サービスに影響が出ている場合は、速やかにプロセスを再起動または再開し、その後OceanBaseテクニカルサポートに連絡して対応を依頼します。
ハードウェアの異常によりノードが異常を起こした場合、またはハードウェアの異常が疑われる場合は、該当する異常ノードを隔離して交換する必要があります。具体的な操作手順は以下のとおりです：
rootユーザーでクラスタのsysテナントにログインします。接続例は以下のとおりです。データベースへの接続時は、実際の環境に基づいてください。
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -Aデータベースへの接続に関するより詳細な操作ガイドについては、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。
異常ノードに対して、速やかに
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つのシナリオに分かれます：
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移行を自動的に開始している場合は、移行後のトポロジーを観察し、移行トラフィックがクラスタリソースに占めるリソースを監視し、業務担当者への同期を適切に行う必要があります。
操作終了後、
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移行が完了し、データ補完に成功したことを意味します。
異常ノード上のUnitが新規ノード上で補完されたら、異常ノードを削除します。
ノードの削除に関する具体的な操作については、ノードの削除を参照してください。