Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Recupere o MongoDB Ops Manager e o AppDB se o cluster central funcionar

Se os clusters do Kubernetes que executam as instâncias do MongoDB Ops Manager aplicativo ou os nós do banco de dados de aplicativo falharem, mas o cluster central estiver disponível, você poderá usar o Kubernetes operador para reconfigurar as implantações do conjunto de réplicas do banco de dados de aplicativo e as instâncias do MongoDB Ops Manager aplicativo com base nos seguintes cenários:

  • Se algumas ou todas as instâncias do aplicativo MongoDB Ops Manager falharem, nenhum dado será perdido porque o aplicativo MongoDB Ops Manager não terá estado. Para aumentar a disponibilidade do Aplicativo de MongoDB Ops Manager , adicione novas instâncias do Aplicativo de MongoDB Ops Manager a clusters de membros Kubernetes já configurados e disponíveis ou adicione novos clusters do Kubernetes para executar as instâncias do Aplicativo de MongoDB Ops Manager .

  • Se apenas uma minoria de nós do conjunto de réplicas falhar e a maioria dos nós em um conjunto de réplicas estiver disponível, durante o processo de reconciliação, o operador Kubernetes ignorará os clusters Kubernetes com falha e o aplicativo de banco de dados permanecerá em um estado gravável.

    Use as configurações de spec.applicationDatabase.clusterSpecList para adicionar nós do conjunto de réplicas do banco de dados de aplicativos a clusters Kubernetes de membros já configurados e disponíveis ou adicionar novos clusters Kubernetes nos quais você distribuirá os membros do conjunto de réplicas com falha do banco de dados de aplicativos. Você também pode reduzir a escala dos nós do conjunto de réplicas em um cluster Kubernetes com falha para reconfigurar o conjunto de réplicas para não conter mais esses nós.

  • If a majority of replica set's nodes fail, the replica set can't form a voting majority to elect a primary node. To learn more, see Replica Set Deployment Architectures. In this case, if at least one node in an Application Database's replica set remains available, then no data is lost. Because there is no primary node in a replica set, you must forcibly reconfigure the replica set to add new replica set nodes. The nodes will form a voting majority allowing the replica set to elect a primary. New Application Database instances will sync with the healthy nodes to receive the data.

  • If all Kubernetes member clusters hosting the Application Database's replica set nodes fail, this causes an irreversible data loss (Ops Manager doesn't back up the Application Database). If possible, use an odd number of member Kubernetes clusters and distribute your Application Database nodes across data centers, zones, or Kubernetes clusters. To learn more, see Replica Sets Distributed Across Two or More Data Centers.

Avalie esta página