アービトレーションサービスの概要

OceanBaseデータベースの現在のバージョンでは、アービトレーションサービス(Arbitration Service)が導入されました。これにより、2リージョン3データセンター構成で同一リージョン内のレプリカに障害が発生した場合のRT増大問題を解決するだけでなく、異なるリージョン間の帯域幅コストを削減し、第3データセンターのコストを極めて低く抑えることができます。

アービトレーションサービスは、テナントのログストリームに対応するアービトレーションメンバーを管理します。アービトレーションメンバーには以下の特徴があります：

• 選挙、Paxos Prepare、およびメンバーグループ変更の投票にのみ参加し、ログ多数派投票(Paxos Accept)には参加しません。

• ログを格納せず、MemTableやSSTableも持たないため、リソース(帯域幅/メモリ/ディスク/CPU)の消費が極めて少ないです。

• プライマリとして選出されてサービスを提供することはできません。

フル機能レプリカの半数が障害によりログ同期に失敗し、ログストリームのダウングレード制御時間に達すると、アービトレーションサービスは自動的にログストリームのダウングレードプロセスを実行し、障害レプリカをメンバーリストから削除します(ただし、テナントのローカリティは変更されません)。これによりサービスが復旧し、RPO = 0を実現します。障害が発生したフル機能レプリカが回復すると、アービトレーションサービスはログストリームのアップグレードプロセスを実行し、ダウングレードされたレプリカを再びメンバーリストに追加することで、より高い可用性を保証します。

ログストリームのダウングレードポリシー

現在、半数のレプリカが以下の異常を起こし、ログの同期ができなくなった場合、アービトレーションサービスはログストリームのダウングレード操作を実行します：

• レプリカが存在するServerがダウンした場合

• レプリカが存在するノードに ALTER SYSTEM STOP SERVER コマンドを実行した場合、またはレプリカが存在するZoneに ALTER SYSTEM STOP ZONE コマンドを実行した場合

• レプリカが存在するobserverプロセスに kill -9、kill -15、kill -19 などの操作を実行した場合

• レプリカが存在するServerのネットワークが切断された場合

• レプリカが存在するServer上のテナントログディスクが満杯になった場合

• レプリカが長時間の障害によりログがリーダーに遅れた場合、障害が回復するとレプリカのRebuildがトリガーされます。Rebuild期間中は、そのレプリカのデータとログが不完全なため、ログストリームのアップグレードを実行できません。

ログストリームのダウングレードの主なプロセスは以下のとおりです：

1. ログストリームのリーダー上で動作するアービトレーションサービスは、一部のレプリカが arbitration_timeout の間にリーダーにログ確認メッセージを返信していないことを検出します。その場合、アービトレーションサービスはさらなるチェックを実行し、ログが同期されていないレプリカに対してログストリームの降格操作を準備します。

2. アービトレーションサービスは定期的な検出を通じて、ログが同期されていないレプリカに降格ポリシーで列挙されている異常が存在するかどうかをチェックします。異常が存在する場合、ログストリームの降格操作を実行します。

   注意

   アービトレーションサービスがログストリームの降格操作を実行するのは、障害が発生したレプリカ（降格済みのレプリカを含む）の総数がフル機能レプリカの総数の半分に等しい場合のみです。例えば、4F1A（4つのFレプリカに1つのアービトレーションサービス）デプロイメントシナリオでは：

   • Fレプリカのうち1つだけに異常が発生した場合、アービトレーションサービスはログストリームの降格を実行しません。この時点で4Fの多数派である3Fはまだ生存しており、ログの同期を正常に行うことができるためです。
   • Fレプリカのうち2つに異常が発生した場合（例：2つのFレプリカがネットワーク切断、または1つのFレプリカがRebuild、もう1つのFレプリカが配置されているServerがダウン）、アービトレーションサービスはログストリームの降格を実行します。
   • Fレプリカのうち3つ以上に異常が発生した場合、この時点ではFレプリカとアービトレーションサービスのうち生存しているのは1つのみであり、多数派を満たすことができません。そのため、ログストリームは主を失い、ログストリームの降格を実行することができません。

クラスタ内でログストリームの降格が発生したかどうかは、SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE DEGRADED_LIST NOT LIKE ''; ステートメントで確認できます。クエリ結果にログストリームに対応する DEGRADED_LIST レコードが空ではない場合、そのログストリームで降格が発生したことを意味します。

ログストリームの昇格ポリシー

現在のログストリームが既に降格状態にある場合、アービトレーションサービスは定期的に DEGRADED_LIST 内のレプリカをチェックします。降格されたレプリカのログ同期が回復し、かつそのレプリカに降格ポリシーで列挙されている異常が存在しないことが確認された場合、ログストリームの昇格を許可します。

ログストリームの昇格の主なプロセスは以下のとおりです：

1. ログストリームのリーダー上で動作するアービトレーションサービスは定期的に DEGRADED_LIST 内のレプリカをチェックします。降格されたレプリカがリーダーにログ確認メッセージを返信した場合、アービトレーションサービスはさらなるチェックを実行し、降格されたレプリカに対するログストリームの昇格を準備します。

2. アービトレーションサービスは、降格されたレプリカにログストリームの降格ポリシーで列挙されている異常が存在するかどうかをチェックします。異常が存在しない場合、ログストリームの昇格操作を実行します。

   注意

   ログストリームの昇格時には、すべての降格されたレプリカに異常がない必要はありません。例えば、4F1A（4つのFレプリカに1つのアービトレーションサービス）デプロイメントシナリオで、2つのFレプリカが配置されているServerのダウンにより降格された場合、その後1つのFレプリカのみが回復してログの同期を開始したとしても、アービトレーションサービスはその回復したレプリカに対してログストリームの昇格操作を実行します。

関連ドキュメント

アービトレーションサービスに関するその他の操作については、以下を参照してください：

• 2レプリカ+アービトレーションサービスのOceanBaseクラスタのデプロイ

• テナントでアービトレーションサービスを有効にする

• テナントでアービトレーションサービスを無効にする

• ログストリームの降格制御時間の変更

• クラスタのアービトレーションサービスの置換

• クラスタのアービトレーションサービスの削除

• 残存するクラスタ情報のクリーンアップ