Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Sistemas autogerenciados
/
Implemente e gerencie clusters fragmentados autogerenciados
/
Administração
/
Administração do servidor de configuração

Substituir um servidor de configuração autogerenciado

Nesta página

  • Visão geral
  • Considerações
  • Procedimento

Importante

O seguinte procedimento se aplica a servidores de configuração 5.0. Para versões anteriores do MongoDB, consulte a versão correspondente do Manual do MongoDB.

Visão geral

Se o servidor de configuração se tornar somente leitura, ou seja, não tiver um primário, o cluster fragmentado não terá compatibilidade com operações que alterem os metadados do cluster, como divisão de partes e migrações. Embora nenhuma parte possa ser dividido ou migrado, o aplicativo poderá gravar dados no cluster fragmentado.

Se um dos servidores de configuração não estiver disponível ou inoperável, repare-o ou substitua-o o mais rápido possível. O procedimento seguinte substitui um membro de um conjunto deréplicas do servidor de configuração do por um novo membro.

O tutorial é específico do MongoDB 5.0. Para versões anteriores do MongoDB, consulte a versão correspondente do Manual MongoDB.

Considerações

As seguintes restrições se aplicam a uma configuração de conjunto de réplica quando usada para servidores de configuração:

Procedimento

1

Inicie o servidor de configuração de substituição.

Inicie uma instância do mongod, especificando as opções --configsvr, --replSet, --bind_ip e outras opções conforme adequado para sua implantação.

Aviso

Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.

mongod --configsvr --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
2

Adicione o novo servidor de configuração ao conjunto de réplicas.

Conecte o mongosh ao primary do conjunto de réplicas do servidor de configuração de configuração e utilize o rs.add() para adicionar o novo membro.

Aviso

Antes do MongoDB 5.0, um secundário recém-adicionado ainda conta como membro votante, embora não possa servir leituras nem se tornar primário até que seus dados sejam consistentes. Se você estiver executando uma versão do MongoDB anterior à 5.0 e adicionar um secundário com suas configurações votes e priority maiores que zero, isso pode levar a um caso em que a maioria dos membros votantes está online, mas nenhum primário pode ser eleito. Para evitar tais situações, considere adicionar o novo secundário inicialmente com priority :0 e votes :0. Em seguida, execute rs.status() para garantir que o membro tenha feito a transição para o estado SECONDARY. Por fim, use rs.reconfig() para atualizar sua prioridade e votos.

rs.add( { host: "<hostnameNew>:<portNew>", priority: 0, votes: 0 } )

O processo de sincronização inicial copia todos os dados de um nó do conjunto de réplicas do servidor de configuração para o novo nó sem reiniciar.

mongos instâncias reconhecem automaticamente a alteração nos nós do conjunto de réplicas do servidor de configuração sem reiniciar.

3

Atualize os votos e as configurações de prioridade do servidor de configuração recém-adicionados.

  1. Certifique-se de que o novo nó tenha atingido o estado SECONDARY. Para verificar o estado dos nós do conjunto de réplicas, execute rs.status():

    rs.status()

  2. Reconfigure o conjunto de réplicas para atualizar os votos e a prioridade do novo nó:

    var cfg = rs.conf();
    cfg.members[n].priority = 1;  // Substitute the correct array index for the new member
    cfg.members[n].votes = 1;     // Substitute the correct array index for the new member
    rs.reconfig(cfg)

    em que n é o índice da matriz do novo nó na matriz members .

Aviso

  • O método rs.reconfig() shell pode forçar o primário atual a se retirar, o que causa uma eleição. Quando as etapas primárias são desativadas, o mongod fecha todas as conexões do cliente. Embora isso normalmente leve de 10 a 20 segundos, tente fazer essas alterações durante os períodos de manutenção programados.

  • Evite reconfigurar conjuntos de réplicas que contenham membros de diferentes versões do MongoDB, pois as regras de validação podem diferir entre as versões do MongoDB.

4

Desligue todos os nós do conjunto de réplicas.

Se estiver substituindo o nó primário, retire o primário antes de desligar.

5

Remova o nó a ser substituído do conjunto de réplicas do servidor de configuração.

Após a conclusão da sincronização inicial do servidor de configuração de substituição, a partir de uma sessão do mongosh que está conectada ao primário, utilize o rs.remove() para remover o nó antigo.

rs.remove("<hostnameOld>:<portOld>")

mongos instâncias reconhecem automaticamente a alteração nos nós do conjunto de réplicas do servidor de configuração sem reiniciar.

6

Se necessário, atualize a mongos configuração do ou entrada de DNS.

Com servidores de configuração do conjunto de réplicas, as instâncias mongos especificam na configuração --configdb ou sharding.configDB o nome do conjunto de réplicas do servidor de configuração e pelo menos um dos nós do conjunto de réplicas.

Dessa forma, se a instância mongos não especificar o membro do conjunto de réplicas removido na configuração --configdb ou sharding.configDB, nenhuma ação adicional será necessária.

Se, no entanto, uma instância mongos especificou o nó removido na configuração --configdb ou configDB:

  • Atualize a configuração para a próxima vez que você reiniciar o mongos ou

  • Modifique a entrada DNS que aponta para o sistema que forneceu o servidor de configuração antigo, para que o mesmo nome de host aponte para o novo servidor de configuração.

Voltar

Administração do servidor de configuração

Próximo

Reiniciar