適用対象
この内容はOceanBaseデータベースEnterprise版にのみ適用されます。OceanBaseデータベースCommunity版は、現在アービトレーションサービス機能をサポートしていません。
OceanBaseデータベースの現在のバージョンでは、アービトレーションサービス(Arbitration Service)が導入されました。これにより、2地域3データセンター構成で同一都市内のレプリカに障害が発生した場合のRT増大問題を解決するだけでなく、都市間の帯域幅コストを削減し、第3データセンターのコストを極めて低く抑えることができます。
アービトレーションサービスでは、テナントのログストリームに対応するアービトレーションメンバーが維持されます。アービトレーションメンバーには以下の特徴があります：
選挙、Paxos Prepareおよびメンバーグループ変更の投票にのみ参加し、ログ多数派投票(Paxos Accept)には参加しません。
ログを格納せず、MemTableやSSTableも持たないため、リソース(帯域幅/メモリ/ディスク/CPU)の消費が極めて少ないです。
プライマリとして選出されてサービスを提供することはできません。
フル機能レプリカの半数に障害が発生し、ログ同期に失敗し、かつログストリームのデグレード制御時間に達すると、アービトレーションサービスは自動的にログストリームのデグレードプロセスを実行し、障害レプリカをメンバーリストから削除します(ただし、テナントのローカリティは変更されません)。これによりサービスが復旧し、RPO = 0を実現できます。障害が発生したフル機能レプリカが復旧すると、アービトレーションサービスはログストリームの昇格プロセスを実行し、デグレードされたレプリカを再びメンバーリストに加え、より高い可用性を保証します。
説明
ログストリームのデグレード制御時間は、テナントレベルの構成パラメータarbitration_timeoutで制御されます。デフォルト値は5秒で、値の範囲は[3秒, +∞)です。arbitration_timeoutの詳細については、arbitration_timeoutを参照してください。
ログストリームのデグレード戦略
現在、半数のレプリカで以下の異常が発生し、ログの同期ができなくなった場合、アービトレーションサービスはログストリームのデグレード操作を実行します：
レプリカが配置されているServerがダウンした場合
レプリカが配置されているノードに
ALTER SYSTEM STOP SERVERコマンドを実行した場合、またはレプリカが配置されているゾーンにALTER SYSTEM STOP ZONEコマンドを実行した場合レプリカが配置されているobserverプロセスに
kill -9、kill -15、kill -19などの操作を実行した場合レプリカが配置されているServerのネットワークが切断された場合
レプリカが配置されているServer上のテナントログディスクが満杯になった場合
長時間の障害によってレプリカのログがLeaderより遅れると、障害からの復旧後にレプリカのRebuildがトリガーされます。Rebuild中は、そのレプリカのデータとログが不完全なため、ログストリームの昇格を実行できません。
ログストリームのデグレードの主要なプロセスは以下のとおりです：
ログストリーム Leader 上で実行されているアービトレーションサービスは、一部のレプリカが
arbitration_timeout以内に Leader にログ確認メッセージを返信していないことを検出すると、さらなるチェックを実行し、ログが同期されていないレプリカに対してログストリームのデグレード操作を実行する準備をします。アービトレーションサービスは定期的な検出を通じて、ログが同期されていないレプリカにデグレード戦略に記載されている異常が存在するかどうかをチェックします。異常が存在する場合、ログストリームのデグレード操作を実行します。
注意
障害が発生したレプリカ（デグレード済みのレプリカを含む）の合計数がフル機能レプリカの合計数の半分に等しい場合にのみ、アービトレーションサービスはログストリームのデグレード操作を実行します。例えば、4F1A（4つのFレプリカと1つのアービトレーションサービス）のデプロイメントシナリオでは：
- 1つのFレプリカだけに異常が発生した場合、アービトレーションサービスはログストリームのデグレードを実行しません。この時点で4Fの多数派である3Fはまだ生存しており、ログの同期を正常に行うことができるためです。
- 2つのFレプリカに異常が発生した場合（例：2つのFレプリカのネットワークが切断されたり、1つのFレプリカが再構築中で、もう1つのFレプリカが配置されているServerがダウンしたりした場合）、アービトレーションサービスはログストリームのデグレードを実行します。
- 3つ以上のFレプリカに異常が発生した場合、この時点ではFレプリカとアービトレーションサービスが1つずつしか生存しておらず、多数派を満たさないため、ログストリームにはLeaderが存在せず、ログストリームのデグレードを実行できません。
クラスタでログストリームのデグレードが発生したかどうかは、SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE DEGRADED_LIST NOT LIKE ''; ステートメントで確認できます。クエリ結果にログストリームに対応する DEGRADED_LIST レコードが空ではない場合、そのログストリームがデグレードされたことを意味します。
ログストリームの昇格戦略
現在のログストリームが既にデグレード状態にある場合、アービトレーションサービスは定期的に DEGRADED_LIST 内のレプリカをチェックします。デグレードされたレプリカのログ同期が復旧し、かつそのレプリカにデグレード戦略に記載されている異常が存在しないことが確認された場合、ログストリームの昇格を許可します。
ログストリームの昇格の主要なプロセスは以下のとおりです：
ログストリーム Leader 上で実行されているアービトレーションサービスは定期的に
DEGRADED_LIST内のレプリカをチェックします。デグレードされたレプリカが Leader にログ確認メッセージを返信した場合、アービトレーションサービスはさらなるチェックを実行し、デグレードされたレプリカに対するログストリームの昇格を準備します。アービトレーションサービスは、デグレードされたレプリカにログストリームのデグレード戦略に記載されている異常がまだ存在するかどうかをチェックします。異常が存在しない場合、ログストリームの昇格操作を実行します。
注意
ログストリームの昇格時には、デグレードされたすべてのレプリカで異常が解消されている必要はありません。例えば、4F1A（4つのFレプリカと1つのアービトレーションサービス）のデプロイメントシナリオで、2つのFレプリカが配置されているServerのダウンによりデグレードされた場合、その後1つのFレプリカのみが復旧してログの同期を開始したとしても、アービトレーションサービスはその復旧したレプリカに対してログストリームの昇格操作を実行します。
関連ドキュメント
その他のアービトレーションサービスに関する操作については、以下を参照してください：