Migre um cluster fragmentado autogerenciado para hardware diferente
Nesta página
O tutorial é específico do MongoDB 5.0. Para versões anteriores do MongoDB, consulte a versão correspondente do Manual MongoDB.
Os servidores de configuração para clusters fragmentados são implantados como umconjunto de réplicas . Os servidores de configuração do conjunto de réplica devem executar o mecanismo de armazenamento WiredTiger.
Este procedimento move os componentes do cluster fragmentado para um novo sistema de hardware sem tempo de inatividade para leituras e gravações.
Importante
Enquanto a migração estiver em andamento, não tente alterar para os Metadados de Cluster Fragmentados. Não use nenhuma operação que modifique os metadados do cluster de forma alguma. Por exemplo, não crie ou elimine bancos de dados, crie ou elimine collections ou use quaisquer comandos de fragmentação.
Desabilitar o balancer
Desative o balancer para interromper a migração de chunk e não execute nenhuma operação de gravação de metadados até que o processo seja concluído. Se houver uma migração em andamento, o balancer concluirá a migração em andamento antes de encerrar.
Para desativar o balanceador, conecte-se a uma das instâncias mongos do cluster e emita o seguinte método: [1]
sh.stopBalancer()
Para verificar o estado do balanceador, emita o método sh.getBalancerState().
Para mais informações, consulte Desabilitar o Balancer.
| [1] | A partir do MongoDB 4.2, sh.stopBalancer() também desabilita a divisão automática para o cluster fragmentado. |
Migrar cada servidor MongoDB de configuração separadamente
Servidores de configuração para clusters fragmentados podem ser implantados como um conjunto de réplicas (CSRS). O uso de um conjunto de réplicas para os servidores de configuração melhora a consistência entre os servidores de configuração, pois o MongoDB pode aproveitar os protocolos padrão de leitura e gravação do conjunto de réplicas para os dados de configuração. Além disso, o uso de um conjunto de réplicas para servidores de configuração permite que um cluster fragmentado tenha mais de 3 servidores de configuração, pois um conjunto de réplicas pode ter até 50 membros. Para implantar servidores de configuração como um conjunto de réplicas, os servidores de configuração devem executar o WiredTiger Storage Engine.
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).
Para cada membro do conjunto de réplicas do servidor de configuração:
Importante
Substitua os nós secundários antes de substituir o primary.
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.
Reiniciar as mongos instâncias do
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 membros do conjunto de réplicas. As instâncias mongos do cluster fragmentado devem especificar o mesmo nome de conjunto de réplicas do servidor de configuração, mas podem especificar membros diferentes do conjunto de réplicas.
Se uma instância mongos especificar um membro do conjunto de réplicas migradas na configuração --configdb ou sharding.configDB , atualize a configuração do servidor de configuração para a próxima vez que reiniciar a instância mongos .
Para mais informações, consulte Iniciar um mongos para o cluster fragmentado.
Migrar os shards
Migre os fragmentos um de cada vez. Para cada fragmento, siga o procedimento apropriado nesta seção.
Migrar um shard de conjunto de réplicas
Para migrar um cluster fragmentado, migre cada membro separadamente. Primeiro, migre os membros não primários e, em seguida, migre o primary por último.
Se o conjunto de réplicas tiver dois membros votantes, adicione um árbitro ao conjunto de réplicas para garantir que o conjunto mantenha a maioria de seus votos disponíveis durante a migração. Você pode remover o árbitro após concluir a migração.
Migrar um nó de um fragmento do conjunto de réplicas
Encerre o processo
mongod. Para garantir um desligamento limpo, use o comandoshutdown.Mova o diretório de dados (ou seja, o
dbPath) para a nova máquina.Reinicie o processo
mongodno novo local.Conecte ao primário atual do conjunto de réplicas.
Se o nome de host do membro tiver sido alterado, use
rs.reconfig()para atualizar o documento de configuração do conjunto de réplicas com o novo nome de host.Por exemplo, a seguinte sequência de comandos atualiza o nome de host para a instância na posição
2na arraymembers:cfg = rs.conf() cfg.members[2].host = "pocatello.example.net:27018" rs.reconfig(cfg) Para obter mais informações sobre atualizações do documento de configuração, consulte Exemplos.
Para confirmar a nova configuração, emita
rs.conf().Aguarde o membro se recuperar. Para verificar o estado do membro, emita
rs.status().
Migrar o primário em um fragmento de conjunto de réplicas
Ao migrar o primário do conjunto de réplicas, o conjunto deve eleger um novo primário. Esse processo de failover que torna o conjunto de réplicas indisponível para realizar leituras ou aceitar gravações durante a eleição, que normalmente é concluída rapidamente. Se possível, planeje a migração durante uma janela de manutenção.
Reduza o primário para permitir o processo de failover normal. Para reduzir o primário, conecte-se ao primário e emita o comando
replSetStepDownou o métodors.stepDown(). O exemplo a seguir mostra o métodors.stepDown():rs.stepDown() Assim que o primário for retirado e outro membro se tornar
PRIMARYestado. Para migrar o primário com passo pendente, siga o procedimento Migrar um membro de um shard do conjunto de réplicasVocê pode verificar a saída do
rs.status()para confirmar a alteração no status.
Reative o balancer
Para concluir a migração, reative o balanceador para retomar as migrações de partes.
Conecte a uma das instâncias do mongos do cluster e passe true para o método sh.startBalancer() : [2]
sh.startBalancer()
Para verificar o estado do balanceador, emita o método sh.getBalancerState().
Para mais informações, consulte Habilitar o Balancer.
| [2] | A partir do MongoDB 4.2, o sh.startBalancer() também habilita a divisão automática para o cluster fragmentado. |