replSetReconfig

Preocupação global com gravação

A partir do MongoDB 5.0, você deve definir explicitamente a preocupação de gravação padrão global antes de tentar reconfigurar um conjunto de réplicas com uma configuração que altere a preocupação de gravação padrão implícita. Para definir a preocupação de escrita padrão global, utilize o comando setDefaultRWConcern.

term Campo de configuração de réplica

O campo term é definido pelo membro primário do conjunto de réplicas. O primário ignora o campo term se definido explicitamente na operação replSetReconfig .

A reconfiguração pode adicionar ou remover no máximo um membro votante de cada vez

replSetReconfig por padrão, permite adicionar ou remover não mais do que 1 voting membros por vez. Por exemplo, uma nova configuração pode fazer, no máximo, uma das seguintes alterações no cluster membership:

• Adicionando um novo membro do conjunto de réplica de votação.

• Removendo um membro do conjunto de réplica de votação existente.

• Modificando o votes para um membro do conjunto de réplica existente.

Para adicionar ou remover vários membros votantes, emita uma série de operações do replSetReconfig para adicionar ou remover um membro de cada vez.

A emissão de uma reconfiguração de força instala imediatamente a nova configuração, mesmo que ela adicione ou remova vários membros votantes. A reconfiguração forçada pode causar um comportamento inesperado, como a reversão de "majority" operações de gravação confirmadas.

A reconfiguração espera até que uma maioria dos membros instale a configuração da réplica

replSetReconfig espera até que a maioria dos membros votantes do conjunto de réplicas instale a nova configuração de réplica antes de retornar com êxito. Um membro votante é qualquer membro do conjunto de réplicas em que members[n].votes é 1, incluindo árbitros.

Os membros do conjunto de réplicas propagam sua configuração de réplica por meio de pulsações. Sempre que um membro descobre uma configuração com umversion e termsuperiores, ele instala a nova configuração. O processo de reconfiguração tem duas fases distintas de espera:

1) Aguarde que a configuração atual seja comprometida antes de instalar a nova configuração.

A configuração "atual" refere-se à configuração de réplica em uso pelo primário no momento em que replSetReconfig é emitido.

Uma configuração é confirmada quando:

• A maioria dos membros do conjunto de réplica de votação instalou a configuração atual e

• Todas as gravações que foram "majority" confirmadas na configuração anterior também foram replicadas para uma maioria na configuração atual.

Normalmente, a configuração atual já foi instalada na maioria dos membros do conjunto de réplica de votação. No entanto, a maioria das gravações confirmadas na configuração anterior pode não ser confirmada na configuração atual. Delayed membros ou membros que são lagging behind os principais podem aumentar o tempo gasto nessa fase.

Se a operação tiver sido emitida com um limite de maxTimeMS e a operação exceder o limite enquanto espera, a operação retornará um erro e descartará a nova configuração. O limite é cumulativo e não é redefinido após prosseguir para a próxima fase.

2) Aguarde a maioria dos membros votantes na nova configuração instalar a nova configuração.

A configuração "nova" refere-se à configuração de réplica especificada para replSetReconfig.

O primário instala e começa a usar a nova configuração de réplica antes de propagar a configuração para os nós restantes do conjunto de réplicas. A operação aguarda apenas que a maioria dos nós votantes instale a nova configuração e não requer a espera para que a nova configuração seja confirmada.

Se a operação foi emitida com um limite maxTimeMS e a operação exceder o limite durante a espera, a operação retornará um erro , mas continuará usando e propagando a nova configuração.

A emissão de uma reconfiguração forçada instala imediatamente a nova configuração, independentemente do status de compromisso da configuração anterior. A reconfiguração forçada pode causar um comportamento inesperado, como a reversão de "majority" operações de gravação confirmadas.

Para verificar o status de compromisso da configuração atual da réplica, emita replSetGetConfig com o parâmetro commitmentStatus no conjunto de réplicas principal.

Reconfiguração automática para novos membros do conjunto de réplicas de votação

A partir do MongoDB 5.0, um secundário recém-adicionado não conta como um membro votante e não pode ser eleito até que tenha atingido o estado SECONDARY.

Quando um novo nó de votação é adicionado a um conjunto de réplicas, replSetReconfig adicionará internamente um campo newlyAdded à configuração do nó. Os nós com o campo newlyAdded não contam para o número atual de nós de votação. Quando a sincronização inicial for concluída e o nó atingir o estado SECONDARY , o campo newlyAdded será automaticamente removido.

Controle de acesso

Para executar o comando em sistemas que impõem controle de acesso, o usuário deve ter a ação de privilégio replSetConfigure no recurso de cluster. A role incorporada clusterManager , disponível no reconhecimento de data center admin , fornece o privilégio necessário para esse comando.

Comportamento de bloqueio

replSetReconfig obtém um bloqueio especial mutuamente exclusivo para evitar que mais de uma operação de replSetReconfig ocorra ao mesmo tempo.

Conjunto de réplicas de versão mista

Disponibilidade

A maioria dos membros do conjunto deve estar operacional para que as alterações se propaguem corretamente.

replSetReconfig pode acionar a saída do primário atual em algumas situações. A redução primária aciona uma eleição para selecionar uma nova primária:

• Quando o novo primário avança, ele incrementa o campo term para distinguir as alterações de configuração feitas no novo primário das alterações feitas no primário anterior.

• A partir do MongoDB 4.2, ao ser interrompido, o primary não fecha mais todas as conexões do cliente; no entanto, as gravações que estavam em andamento são eliminadas. Para obter detalhes, consulte Comportamento.

• No MongoDB 4.0 e versões anteriores, ao ser desativado, o primary fecha todas as conexões do cliente.

O tempo médio antes de um cluster eleger um novo primário normalmente não deve exceder 12 segundos, assumindo replica configuration settingspadrão . Isso inclui o tempo necessário para marcar a primária como indisponível e convocar e concluir uma eleição. Você pode ajustar este período de tempo modificando a opção de configuração de replicação do settings.electionTimeoutMillis. Fatores como a latência da rede podem prolongar o tempo necessário para que as eleições de conjuntos de réplicas sejam concluídas, o que, por sua vez, afeta o tempo em que o cluster pode operar sem um primário. Esses fatores dependem da arquitetura específica de seus clusters.

Durante o processo de eleição, o cluster não pode aceitar operações de gravação até que eleja o novo primário.

A lógica de conexão do seu aplicativo deve incluir tolerância para failovers automáticos e as eleições subsequentes. Os drivers do MongoDB podem detectar a perda do primário e repetir automaticamente determinadas operações de gravação uma única vez, fornecendo tratamento adicional integrado de failovers e eleições automáticas:

Drivers compatíveis permitem gravações repetíveis por padrão

Para reduzir ainda mais o impacto potencial em um cluster de produção, reconfigure somente durante os períodos de manutenção programados.

{ force: true }

Eliminar conexões de saída após remover um membro

O uso replSetReconfig para remover um membro do conjunto de réplicas não elimina automaticamente as conexões de saída abertas de outros membros do conjunto de réplicas para o membro removido.

Por padrão, os membros do conjunto de réplicas aguardam 5 minutos antes de descartar conexões com o membro removido. Em conjuntos de réplicas fragmentadas, você pode modificar esse tempo limite usando o parâmetroShardingTaskExecutorPoolHostTimeoutMS server.

db.adminCommand(
  {
    "dropConnections" : 1,
    "hostAndPort" : [
      "<hostname>:<port>"
    ]
  }
)

Substitua <hostname> e <port> pelos do membro removido.

Prioridade e votos dos membros

• Membros com priority maior que 0 não podem ter 0 votes.

• Não votante (ou seja, votes é 0) membros devem ter priority de 0.