演算子クラスターが障害した場合のMongoDB Ops Managerの回復
Operator と KubernetesアプリケーションをホストしているKubernetesMongoDB Ops Manager クラスターに障害が発生した場合は、 演算子クラスターとMongoDB Ops Manager アプリケーションを手動で回復できます。
MongoDB Ops Managerの以前の実行状態を復元するには、 MongoDB Ops Managerとアプリケーション データベース リソースに対して定期的なバックアップ メカニズムを構成します。 Kubernetes Operator は、 MongoDB Ops Managerアプリケーションの配置を管理するためにこれらのリソースを必要とします。
Kubernetes Operator とMongoDB Ops Managerの回復
KubernetesOperator とMongoDB Ops Manager MongoDB Ops Managerを復元するには、新しいKubernetes クラスターで リソースを復元します。
新しいクラスターで Kubernetes 演算子を構成します。
手順に従って、新しい Kubernetes クラスターにKubernetes Operatorをインストールします。
注意
ノードクラスターを再利用する場合は、適切なサービス アカウントとロールが存在することを確認してください。 これらの値は重複する可能性があり、中央クラスターとノードクラスター間で権限が異なる場合があります。
Kubernetes 演算子に必要な適切なロールを確認する には、パブリック リポジトリ の サンプルを参照してください。
失敗したMongoDB Ops Managerリソースからバックアップされたリソースを取得します。
オブジェクト のコピー 失敗した リソースの仕様を変更し、次のリソースを検索し、プレースホルダー テキストを特定のMongoDB Ops ManagerMongoDB Ops Manager リソース名と名前空間に置き換えます。
リソース タイプ | Values |
|---|---|
シークレット |
|
ConfigMaps |
|
OpsManager |
|
次に、コピーした仕様を新しい ファイルに貼り付け、前述の値を使用して新しいリソースを構成します。 詳細については、「 MongoDB Ops Managerリソースの配置 」を参照してください。
MongoDB Ops Managerリソースを新しいクラスターに再適用します。
次のコマンドを使用して、更新されたリソースを適用します。
kubectl apply \ --context "$MDB_CENTRAL_CLUSTER_FULL_NAME" \ --namespace "mongodb" -f https://raw.githubusercontent.com/mongodb/mongodb-enterprise-kubernetes/master/samples/ops-manager/ops-manager-external.yaml
MongoDB Ops Manager リソースのステータスを確認するには、次のコマンドを使用します。
kubectl get om -o yaml -w
中央クラスターがRunning状態に達したら、アプリケーション データベースを必要なメンバー クラスターの分散にリスケールできます。
この時点で、新しく復元された Kubernetes Operator は、既存のアプリケーション データベースの管理を選択します。
初期プロジェクトの作成に使用されるConfigMap 。
前の Kubernetes Operator インスタンスで使用されていたシークレット。
または
MongoDBMongoDBMulticlusterカスタム リソース ソースクラスターで最後に使用可能な状態にある ドキュメント を含む、 Kubernetes Operator によってライフサイクル中に追加されました。
注意
アプリケーション データベースのレプリカセットでいくつかのノードがなくなり、投票過半数を形成できない場合は、 レプリカセット を強制的に再構成します。 これにより、投票権の過半数を形成する新しいレプリカセット ノードが追加され、レプリカセットがプライマリを選出できるようになります。