機能の適用範囲
この内容はOceanBaseデータベースEnterprise Editionにのみ適用されます。OceanBaseデータベースCommunity Editionは、現在アービトレーションサービス機能をサポートしていません。
アービトレーションの概要
分散データベースにおいて、複数のデータレプリカ間で過半数の障害が発生した場合（半数のレプリカが故障するか、もう半分とネットワークが切断される）、クラスタ外部のアービトレーションサービスを介して変更の意思決定（リーダー選出/メンバーグループ変更）に参加し、サービスを復旧することができます。OceanBase データベース V4.1.0 からアービトレーションサービス（Arbitration Service）がサポートされています。アービトレーションサービスは、OceanBase クラスタにアービトレーション機能を提供する独立したプロセスです。これは、Paxos マルチレプリカ災害復旧ソリューションに基づいて提案された新しい高可用性ソリューションです。
アービトレーションサービスは OceanBase クラスタから独立してデプロイされ、特別モードで起動する軽量な observer プロセスです。このプロセスはログストリームレベルのアービトレーションメンバーを担います。 アービトレーションメンバーには以下の特徴があります：
- 選挙、Paxos Prepare、およびメンバーグループ変更の投票にのみ参加し、ログ多数派投票（Paxos Accept）には参加しません。
- ログを格納せず、MemTable や SSTable も持たないため、リソース（帯域幅/メモリ/ディスク/CPU）の消費が極めて少ないです。
- リーダーに選出されてサービスを提供することはできません。
アービトレーションサービスの利点
アービトレーション高可用性ソリューションの利点は以下の通りです：
- アービトレーションメンバーは従来のログ型レプリカのユースケースを置き換えることができ、可用性をほぼ維持したまま導入コストを削減できます。
- 全機能レプリカの半数が故障した場合、アービトレーションが自動的にフェールオーバーしてサービスを復旧します。フェールオーバー後の業務 RT は影響を受けません（異なる都市間でのログ同期は不要）。
- アービトレーションメンバーはログの同期や再生を必要とせず、Redo ログやベースラインデータも格納しないため、アービトレーションサービスのリソース（CPU /メモリ/ディスク/帯域幅）消費が大幅に削減されます。
- プライマリ/スタンバイデータベース方式と比較して、アービトレーション方式は2つの全機能レプリカを基盤とし、極めて低い追加リソース消費で無損失デュアルアクティブ機能を実現します。自動的な昇格・降格をサポートし、データ損失はありません（RPO=0）。
適用シナリオ
アービトレーション高可用性ソリューションの適用シナリオは以下の通りです：
- 同一都市内の二つのデータセンターがあり、アービトレーションを独立してデプロイできる条件を満たす場合（異なる都市間でも可能）。
- 異なる都市間で帯域幅リソースが限られている場合。
- コストに敏感で予算が限られている場合。
- 無損失デュアルアクティブ機能を希望し、可用性が3F/5F より若干低くても許容できる場合。
アービトレーション高可用性ソリューションは、全 F デプロイメントソリューションと比較してコストが低いですが、その代わりに可用性も若干低くなります。例えば 2F1A の場合、1つの F レプリカが故障するとアービトレーションによるフェールオーバーがトリガーされ、その後は単一レプリカでのみログが同期されます。極端な状況下で2番目の F レプリカも故障し回復不能になった場合、たとえ最初の F レプリカが後に回復してもデータ損失が発生します。これはアービトレーションメンバーが Redo ログを格納しないためです。3F デプロイメントシナリオではこの問題は発生しません。
アービトレーションの使用に適さないシナリオ：
- データセンターが2つしかなく、アービトレーションのデプロイに使用できる追加のマシン/データセンターがない場合。このようなシナリオではプライマリ/スタンバイデータベースの災害復旧ソリューションを使用するのが適しています。
- システムに究極の可用性を求め、全機能レプリカの使用コストを許容できる場合。このような場合は Paxos マルチレプリカ災害復旧ソリューションを使用するのが適しています。
各災害復旧ソリューションの比較については、災害復旧デプロイメントソリューション を参照してください。
アービトレーションサービスの設定
前提条件
テナントのローカリティが2Fまたは4Fの場合にのみ、アービトレーションサービスを有効にできます。
アービトレーションサービスのデプロイ
アービトレーションサービスは現在、単一マシンでデプロイされます。対応するデプロイ要件を満たすリソース仕様の適切なマシンを準備する必要があります。その後、アービトレーションモード特有の起動パラメータを使用してobserverプロセスを起動できます。詳細については、コマンドラインを使用した2レプリカ + アービトレーションサービスのOceanBaseクラスタのデプロイを参照してください。
アービトレーションサービスの使用
アービトレーションサービスのデプロイが完了したら、まずOceanBaseクラスタでアービトレーションサービスの追加操作を実行し、その後クラスタ内のテナントがアービトレーションサービスを使用できるようになります。 単一のアービトレーションサービスは、複数のOceanBaseクラスタの使用をサポートできます。
アービトレーションサービスの有効化/無効化
OceanBaseクラスタ内では、テナント単位でアービトレーションサービスを有効または無効にすることができます。
自動昇格・降格メカニズム
テナントでアービトレーションを有効にした後、フル機能レプリカの過半数以上が障害を起こし、ログが多数派に達しなくなった場合、アービトレーションによる自動降格を実現し、サービスを復旧するとともにRPO = 0を実現します。障害レプリカが復旧すると、クラスタは自動的に昇格し、初期のメンバーリストに戻ります。
自動昇格・降格の実装原理は以下の図のとおりです。降格時には、障害を起こしたフル機能レプリカをLearnerロールに変更し、昇格時には逆の変更を行い、Learnerをフル機能レプリカに戻します。
降格がトリガーされる可能性のあるシナリオは以下のとおりです：
- Serverのネットワーク切断またはダウン
- Rebuildレプリカのトリガー
STOP SERVER/STOP ZONE/ISOLATE SERVERコマンドの実行- observerプロセスに対して
kill -9、kill -15、kill -19操作を実行した場合 - Server上のテナントログディスクが満杯またはログディスクがハングした場合（ログディスクとはClogディレクトリが配置されているディスクを指します）
アービトレーションサービスの操作
OceanBaseクラスタ内でアービトレーションサービスを有効にした後、アービトレーションサービスの置換または削除操作をサポートします。