適用対象
この内容は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）がありません。
適用シナリオ
アービトレーションによる高可用性ソリューションの適用シナリオは以下の通りです：
- 同一都市内の2つのデータセンターで、アービトレーションを独立してデプロイできる条件を満たす場合（都市間でのデプロイが可能な場合）。
- 都市間の帯域幅リソースが不足している場合。
- コストに敏感で予算が限られている場合。
- 無損失のアクティブ／アクティブ機能を希望し、可用性が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のネットワーク切断またはダウン
- レプリカの再構築がトリガーされる
STOP SERVER/STOP ZONE/ISOLATE SERVERコマンドが実行された- observerプロセスに対して
kill -9、kill -15、kill -19操作が実行された - Server上のテナントログディスクが上限またはログディスクがハングした（ログディスクとはClogディレクトリが存在するディスクを指す）
アービトレーションサービスの操作
OceanBaseクラスタ内でアービトレーションサービスを有効にした後、アービトレーションサービスの置き換えまたは削除操作がサポートされます。