適用対象
この内容はOceanBaseデータベースEnterprise Editionにのみ適用されます。OceanBaseデータベースCommunity Editionは、現在アービトレーションサービス機能をサポートしていません。
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コマンドを実行した場合、またはレプリカが配置されているZoneにALTER SYSTEM STOP ZONEコマンドを実行した場合レプリカが配置されているobserverプロセスに
kill -9、kill -15、kill -19などの操作を実行した場合レプリカが配置されているServerのネットワークが切断された場合
レプリカが配置されているServer上のテナントログディスクが満杯になった場合
レプリカが長時間の障害によりログがリーダーに遅れた場合、障害回復後にレプリカの再構築がトリガーされます。再構築期間中は、そのレプリカのデータとログが不完全なため、ログストリームの昇格を実行できません。
ログストリームのデグレードの主要なプロセスは以下のとおりです：
ログストリームリーダー上で実行されているアービトレーションサービスは、一部のレプリカが
arbitration_timeout以内にリーダーにログ確認メッセージを返信していないことを検出すると、さらなるチェックを実行し、ログが同期されていないレプリカに対してログストリームのデグレード操作を実行する準備をします。アービトレーションサービスは定期的な検出を通じて、ログが同期されていないレプリカにデグレードポリシーに記載されている異常が存在するかどうかをチェックします。異常が存在する場合、ログストリームのデグレード操作を実行します。
注意
障害が発生したレプリカ（デグレード済みのレプリカを含む）の合計数がフル機能レプリカの合計数の半分に等しい場合にのみ、アービトレーションサービスはログストリームのデグレード操作を実行します。例えば、4F1A（4つのFレプリカと1つのアービトレーションサービス）のデプロイメントシナリオでは：
- Fレプリカが1つだけ異常を発生させた場合、アービトレーションサービスはログストリームのデグレードを実行しません。この時点で4Fの多数派である3Fはまだ生存しており、ログの同期を正常に行うことができるためです。
- Fレプリカが2つ異常を発生させた場合（例：2つのFレプリカのネットワークが切断されたり、1つのFレプリカが再構築中で、もう1つのFレプリカが配置されているServerがダウンしたりした場合）、アービトレーションサービスはログストリームのデグレードを実行します。
- Fレプリカが3つ以上異常を発生させた場合、この時点ではFレプリカとアービトレーションサービスが1つずつしか生存しておらず、多数派を満たさないため、ログストリームは主を持たず、ログストリームのデグレードを実行できません。
クラスタでログストリームのデグレードが発生したかどうかは、SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE DEGRADED_LIST NOT LIKE ''; ステートメントで確認できます。クエリ結果にログストリームに対応する DEGRADED_LIST レコードが空ではない場合、そのログストリームがデグレードされたことを意味します。
ログストリームの昇格ポリシー
現在のログストリームが既にデグレード状態にある場合、アービトレーションサービスは定期的に DEGRADED_LIST 内のレプリカをチェックします。デグレードされたレプリカのログ同期が回復し、かつそのレプリカにデグレードポリシーに記載されている異常が存在しないことが確認された場合、ログストリームの昇格を許可します。
ログストリームの昇格の主要なプロセスは以下のとおりです：
ログストリームリーダー上で実行されているアービトレーションサービスは定期的に
DEGRADED_LIST内のレプリカをチェックします。デグレードされたレプリカがリーダーにログ確認メッセージを返信した場合、アービトレーションサービスはさらなるチェックを実行し、デグレードされたレプリカに対するログストリームの昇格を準備します。アービトレーションサービスは、デグレードされたレプリカにログストリームのデグレードポリシーに記載されている異常がまだ存在するかどうかをチェックします。異常が存在しない場合、ログストリームの昇格操作を実行します。
注意
ログストリームの昇格時には、すべてのデグレードされたレプリカに異常がない必要はありません。例えば、4F1A（4つのFレプリカと1つのアービトレーションサービス）のデプロイメントシナリオで、2つのFレプリカが配置されているServerのダウンによりデグレードされた場合、その後1つのFレプリカのみが回復してログの同期を開始したとしても、アービトレーションサービスはその回復したレプリカに対してログストリームの昇格操作を実行します。
関連ドキュメント
その他のアービトレーションサービスに関する操作については、以下を参照してください：