Recupere o banco de dados do aplicativo se o conjunto de réplicas perder a maioria

Visão geral

Em certas interrupções severas do cluster Kubernetes, o sistema do conjunto de réplicas do seu banco de dados de aplicativos pode perder a maioria dos nós do conjunto de réplicas. Por exemplo, se você tiver um sistema de banco de dados de aplicativos com dois nós em cluster 1 e três nós em cluster 2, e cluster 2 sofrer uma interrupção, o sistema do conjunto de réplicas do banco de dados de aplicativos perderá a maioria de nós necessária para eleger um primário. Sem um primário, o MongoDB Agent não pode reconfigurar um conjunto de réplicas.

Para habilitar o reescalonamento dos nós do conjunto de réplicas, o Kubernetes Operator deve reconfigurar à força aconfiguração de automação do MongoDB Agent para permitir a distribuição de nós do conjunto de réplicas nos clusters de membros íntegros restantes. Para isso, o operador Kubernetes define o replicaSets[n].force sinalizador na configuração do conjunto de réplicas. O sinalizador instrui o MongoDB Agent a forçar um conjunto de réplicas a usar a versão atual (mais recente) da Configuração de automação. Usar o sinalizador permite que o Operador Kubernetes reconfigure o conjunto de réplicas caso um nó primário não seja eleito.

Recuperar o banco de dados do aplicativo por meio de uma reconfiguração forçada

Para realizar uma reconfiguração forçada dos nós do banco de dados do aplicativo:

1. Altere as definições de configuração spec.applicationDatabase.clusterSpecList para reconfigurar a implantação do banco de dados do aplicativo em clusters Kubernetes íntegros para permitir que o conjunto de réplicas forme a maioria dos nós íntegros.

2. Remova os clusters Kubernetes com falha do spec.applicationDatabase.clusterSpecList ou reduza os clusters de membros do Kubernetes com falha. Dessa forma, o conjunto de réplicas não conta os nós do banco de dados hospedados nesses clusters como membros votantes do conjunto de réplicas. Por exemplo, com dois nós íntegros em cluster 1 e um cluster 2 com falha contendo 3 nós, você tem dois nós íntegros de um total de cinco membros do conjunto de réplicas (2/5 íntegro). Adicionar um nó a cluster 1 resulta em ter 3/6 proporção de nós íntegros para o número de membros no conjunto de réplicas. Para formar uma maioria do conjunto de réplicas, você tem as seguintes opções:

   • Adicione pelo menos dois novos nós de conjunto de réplicas ao cluster 1 ou um novo cluster Kubernetes íntegro. Isso atinge a maioria (4/7), com quatro nós em um conjunto de réplicas de sete membros.

   • Reduza um cluster Kubernetes com falha para zero nós ou remova o cluster do spec.applicationDatabase.clusterSpecList completamente e adicione pelo menos um nó ao cluster 1 para ter 3/3 nós íntegros no StatefulSet do conjunto de réplicas.

3. Adicione a anotação "mongodb.com/v1.forceReconfigure": "true" à Configuração de automação do MongoDB Agent no metadata.annotations. Adicione a anotação no nível superior do recurso personalizado MongoDBOpsManager e garanta que o valor "true" seja uma string entre aspas.

   Com base nessa anotação, o Operador Kubernetes executa uma reconfiguração forçada do conjunto de réplicas no próximo processo de reconciliação e dimensiona os nós do conjunto de réplicas do banco de dados de acordo com a configuração de implantação alterada.

   O Operador Kubernetes não tem meios para determinar se os nós no cluster Kubernetes com falha são íntegros. Portanto, se o Operador Kubernetes não puder se conectar ao servidor API do cluster Kubernetes do membro com falha, o Operador Kubernetes ignorará o cluster durante o processo de reconciliação dos nós do conjunto de réplicas do Banco de Dados de Aplicativo.

   Isso significa que a redução dos nós do Banco de Dados de Aplicativos remove os processos com falha da configuração do conjunto de réplicas. Nos casos em que apenas o servidor da API está inativo, mas os nós do conjunto de réplicas estão em execução, o Operador Kubernetes não remove os Pods dos clusters Kubernetes com falha.

   Para indicar que concluiu a reconfiguração forçada, o Operador Kubernetes adiciona a chave de anotação, "mongodb.com/v1.forceReconfigurePerformed", com o carimbo de data/hora atual como o valor.

   Importante

   O Operador Kubernetes executa apenas uma reconfiguração forçada do conjunto de réplicas. Depois que o conjunto de réplicas atinge o estado de execução, o Operador Kubernetes adiciona a anotação "mongodb.com/v1.forceReconfigurePerformed" para evitar que ele próprio force a reconfiguração no futuro. Portanto, para acionar novamente um novo evento de reconfiguração forçada, remova uma ou ambas as anotações a seguir do recurso, no metadata.annotations para o MongoDBOpsManager recurso personalizado .

   • "mongodb.com/v1.forceReconfigurePerformed"

   • "mongodb.com/v1.forceReconfigure"

4. Reaplique a configuração do recurso personalizado do MongoDBOpsManager alterado no Operador Kubernetes.