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

Migre um cluster fragmentado autogerenciado para hardware diferente

Nesta página

  • Desabilitar o balancer
  • Migrar cada servidor MongoDB de configuração separadamente
  • Reiniciar as Instâncias do mongos
  • Migrar os shards
  • Reative o balancer

O tutorial é específico do MongoDB 7.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 6.0.3, a divisão automática de partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Nas versões do MongoDB anteriores a 6.0.3, o 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].buildIndexes definida 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.

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 sua instância a um endereço IP acessível publicamente, você deve proteger 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 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.

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

  1. Encerre o processo mongod . Para garantir um desligamento limpo, use o comando shutdown .

  2. Mova o diretório de dados (ou seja, o dbPath) para a nova máquina.

  3. Reinicie o processo mongod no novo local.

  4. Conecte ao primário atual do conjunto de réplicas.

  5. 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 2 na array members :

    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.

  6. Para confirmar a nova configuração, emita rs.conf().

  7. 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.

  1. 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 replSetStepDown ou o método rs.stepDown() . O exemplo a seguir mostra o método rs.stepDown() :

    rs.stepDown()

  2. Assim que o primário for retirado e outro membro se tornar PRIMARY estado. Para migrar o primário com passo pendente, siga o procedimento Migrar um membro de um shard do conjunto de réplicas

    Você 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 6.0.3, a divisão automática de chunks não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Nas versões do MongoDB anteriores a 6.0.3, sh.startBalancer() também permite a divisão automática para o cluster fragmentado.

Voltar

Reiniciar