レプリカセットが過半数を失った場合のアプリケーションデータベースの回復
Kubernetesノード クラスターに障害が発生し、アプリケーション データベースがプライマリを選択するために使用できるレプリカセットのノードの大部分を失った場合、 Kubernetes演算子は強制的なレプリカセットの再構成を自動的にtriggerしません。 レプリカセットの強制再構成を手動で開始し、アプリケーション データベースのレプリカセットを正常な状態に復元する必要があります。
Overview
Kubernetes クラスターの特定の重大な停止時に、アプリケーション データベースのレプリカセットの配置により、レプリカセットのノードの大部分が失われる可能性があります。 たとえば、 cluster 1に 2 つのノードとcluster 2に 3 つのノードがあるアプリケーション データベースの配置で、cluster 2 に 3 つのノードがあり、 が停止した場合、アプリケーション データベースのレプリカセットの配置は、選択するために必要なノードの過半数を失うことになります。プライマリ。 プライマリがないと、MongoDB Agent はレプリカセットを再構成できません。
レプリカセットのノードの再スケジュールを有効にするには、Kubernetes Operator は MongoDB Agent のオートメーション構成を強制的に再構成して、残りの正常なノードクラスターにレプリカセット ノードを配置できるようにする必要があります。 これを実現するために、Kubernetes 演算子 はreplicaSets[n]. forceを設定します レプリカセット構成の フラグ。 フラグは、レプリカセットに現在の（最新）オートメーション構成 バージョンを使用するように MongoDB Agent を強制的に指示します。 フラグを使用すると、プライマリ ノードが選択されない場合に Kubernetes Operator はレプリカセットを再構成できます。
強制された再構成によるアプリケーション データベースの回復
アプリケーション データベースのノードの強制的な再構成を実行するには、次の手順に従います。
spec.applicationDatabase.clusterSpecList構成設定を変更して、正常な Kubernetes クラスターへのアプリケーション データベースの配置を再構成し、レプリカセットが正常なノードの大部分を構成できるようにします。失敗した Kubernetes クラスターを
spec.applicationDatabase.clusterSpecListから削除するか、失敗した Kubernetes メンバークラスターをスケールダウンします。 この方法では、レプリカセットは、それらのクラスターでホストされているアプリケーション データベースのノードをレプリカセットの投票ノードとしてカウントしません。 たとえば、cluster 1に正常なノードが 2 つと、 3ノードを含む失敗したcluster 2には、合計 5 つのレプリカセット ノードから 2 つの正常なノードがあります（ 2 / 5正常）。cluster 1に 1 つのノードを追加すると、レプリカセット内のノード数に対する正常なノードの3 / 6の比率になります。 レプリカセットの過半数を形成するには、次のオプションがあります。少なくとも 2 つの新しいレプリカセット ノードを
cluster 1または新しい正常な Kubernetes クラスターに追加します。 これにより、7 ノードのレプリカセットに 4 つのノードが含まれるという過半数（ 4 / 7 ）が実現されます。失敗した Kubernetes クラスターを 0 のノードにスケールダウンするか、クラスターを
spec.applicationDatabase.clusterSpecListから完全に削除し、cluster 1に少なくとも 1 つのノードを追加して、レプリカセットの ステートメントに3 / 3の正常なノードを含めます。
メタデータ.annotations
"mongodb.com/v1.forceReconfigure": "true"のMongoDB Agent のオートメーション構成に注釈 を追加します。MongoDBOpsManagerカスタムリソースの最上位に注釈を追加し、値"true"stringが引用符で囲まれた文字列であることを確認します。この注釈に基づいて、Kubernetes Operator は次回の調整プロセスでレプリカセットの強制的な再構成を実行し、変更された配置構成に従ってアプリケーションデータベースのレプリカセット ノードを増やします。
Kubernetes Operator は、失敗した Kubernetes クラスター内のノードが正常であるかどうかを判断するための手段を持ちません。 したがって、Kubernetes Operator が障害ノードの Kubernetes クラスターの API サーバーに接続できない場合、Kubernetes Operator は、アプリケーションデータベースのレプリカセット ノードの調整プロセス中にクラスターを無視します。
つまり、アプリケーション データベース ノードをスケールダウンすると、レプリカセット構成から失敗したプロセスが排除されます。 API サーバーのみがダウンしているが、レプリカセットのノードが実行中の場合、Kubernetes Operator は障害が発生した Kubernetes クラスターからポッドを削除しません。
強制的な再構成が完了したことを示すために、Kubernetes 演算子 は、現在のタイムスタンプを値として持つ注釈キー
"mongodb.com/v1.forceReconfigurePerformed"を追加します。重要
Kubernetes Operator は、レプリカセットの強制再構成を 1 回だけ実行します。 レプリカセットが実行状態に達すると、Kubernetes Operator は
"mongodb.com/v1.forceReconfigurePerformed"アノテーションを追加して、将来再度再構成を強制しないようにします。 したがって、新しい強制再構成イベントを再トリガーするには、 metadata.annotations の次の注釈の 1 つまたは両方をリソースから削除します。MongoDBOpsManager（ カスタム リソースの場合"mongodb.com/v1.forceReconfigurePerformed""mongodb.com/v1.forceReconfigure"
Kubernetes Operator で変更された
MongoDBOpsManagerカスタム リソースの構成を再適用します。