アービトレーションによる高可用性ソリューション

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

分散データベースにおいて、複数のデータレプリカ間で過半数の障害が発生した場合（半数のレプリカが故障するか、もう半分とネットワークが切断される）、クラスタ外部のアービトレーションサービスを介して変更の意思決定（リーダー選出/メンバーグループの変更）に参加し、サービスを復旧することができます。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クラスタ内でアービトレーションサービスを有効にした後、アービトレーションサービスの置換または削除操作をサポートします。

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

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