Substituir um servidor de configuração autogerenciado
Nesta página
Importante
O seguinte procedimento se aplica a servidores de configuração 6.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 6.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:
Deve ter zero árbitros.
Não deve ter membros atrasados.
Deve construir índices (ou seja, nenhum membro deve ter a configuração
members[n].buildIndexesdefinida como falsa).
Procedimento
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)>
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 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.
Atualize os votos e as configurações de prioridade do servidor de configuração recém-adicionados.
Certifique-se de que o novo nó tenha atingido o estado
SECONDARY. Para verificar o estado dos nós do conjunto de réplicas, executers.status():rs.status() 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 matrizmembers.
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, omongodfecha 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.
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.
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
mongosouModifique 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.