Migração (pull) em produção no MongoDB 6.0.13+ ou 7.0.8+ Cluster no Atlas

Acesso à rede

Configurar permissões de rede para os seguintes componentes:

Validação de pré-migração

Antes de iniciar o seguinte procedimento de migração em produção, o Atlas executa verificações de validação nos clusters de origem e destino e verifica se:

• A versão do MongoDB do cluster de origem e destino é pelo menos FCV 6.0.13+ e correspondente, ou pelo menos FCV 7.0.8+ e está correspondente.

• O usuário de banco de dados do cluster de origem tem as permissões corretas, conforme descrito em Segurança do cluster de origem.

Segurança do cluster de origem

Vários papéis embutidos fornecem privilégios suficientes. Por exemplo:

Para acessar os clusters de conjuntos de réplicas de origem, o usuário do MongoDB deve ter as funções readAnyDatabase e backup.

No caso dos clusters fragmentados de origem, um usuário do MongoDB deve ter as funções readAnyDatabase, backup e clusterMonitor.

Para verificar se o usuário do banco de dados que executará o processo de migração em produção tem essas funções, execute o comando db.getUser() no banco de dados admin. Por exemplo, para um conjunto de réplicas, execute:

use admin
db.getUser("admin")
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
  {
    "role" : "backup",
    "db" : "admin"
  },
  {
    "role" : "readAnyDatabase",
    "db" : "admin"
  }
 ]
} ...

Especifique o nome de usuário e a senha do Atlas quando solicitado pela tela de orientação do procedimento de migração em produção.

O Atlas só é compatível com a SCRAM para conexão com clusters de origem que impõem autenticação.

Como o MongoDB protege seus servidores de migração ao vivo

Em qualquer migração ao vivo do tipo pull para o Atlas, o Atlas gerencia o servidor que executa a migração ao vivo e envia dados da origem para o cluster de destino.

O MongoDB toma as seguintes medidas para proteger a integridade e confidencialidade dos seus dados em trânsito para Atlas:

• O MongoDB criptografa dados em trânsito entre o servidor de migração em tempo real gerenciado pelo Atlassian e o cluster de destino. Se você precisar de criptografia para os dados em trânsito entre o cluster de origem e o servidor de migração gerenciado pelo Atlas, configure o TLS no cluster de origem.

• O MongoDB protege o acesso às instâncias do servidor de migração gerenciadas pelo Atlas, pois protege o acesso a qualquer outra parte do Atlas.

• Em casos raros em que a intervenção é necessária para investigar e restaurar serviços críticos, o MongoDB adere ao princípio do menor privilégio e autoriza apenas um pequeno grupo de usuários privilegiados a acessar seus clusters do Atlas por um tempo mínimo limitado necessário para reparar o problema crítico. O MongoDB requer MFA para que esses usuários efetuem login nos clusters Atlas e estabeleçam uma conexão SSH por meio do host bastion. A concessão desse tipo de acesso a usuários privilegiados requer a aprovação da gerência sênior do MongoDB. O MongoDB não permite o acesso por qualquer outro pessoal do MongoDB aos seus clusters do MongoDB Atlas.

• O MongoDB permite o uso de contas de usuário privilegiadas apenas para atividades privilegiadas. Para realizar atividades não privilegiadas, os usuários privilegiados devem usar uma conta separada. As contas de usuário privilegiadas não podem usar credenciais compartilhadas. As contas de usuários privilegiados devem seguir os requisitos de senha descritos na Seção 4.3.3 do whitepaper do Atlas Security.

• Você pode restringir o acesso aos seus clusters por todos os funcionários do MongoDB, incluindo usuários privilegiados, no Atlas. Se você optar por restringir esse acesso e o MongoDB determinar que o acesso é necessário para resolver um problema de suporte, o MongoDB deve primeiro solicitar sua permissão e, em seguida, decidir se deseja restaurar temporariamente o acesso de usuário privilegiado por até 24 horas. Você pode revogar a concessão de acesso temporária 24 horas a qualquer momento. Habilitar esta restrição pode resultar em um tempo maior para a resposta e resolução de problemas de suporte e, como resultado, pode afetar negativamente a disponibilidade dos seus clusters do Atlas.

• O MongoDB analisa a autorização de acesso de usuário privilegiado trimestralmente. Além disso, o MongoDB revoga o acesso de um usuário privilegiado quando ele não é mais necessário, inclusive dentro de 24 horas após o usuário privilegiado mudar de função ou deixar a empresa. Também registramos qualquer acesso do pessoal do MongoDB aos seus clusters Atlas, retemos os registros de auditoria por pelo menos seis anos e incluímos um registro de data e hora, ator, ação e saída. O MongoDB usa uma combinação de análises automatizadas e manuais para analisar esses logs de auditoria.

Para saber mais sobre a segurança do Atlas, consulte o whitepaper Atlas Security . Em particular, revise a seção "Acesso de pessoal do MongoDB aos clusters do MongoDB Atlas".

Criptografia de rede

Durante as migrações pull live, se o cluster de origem não usar a criptografia TLS para seus dados, o tráfego do cluster de origem para o Atlas não será criptografado. Determine se isso é aceitável antes de iniciar um procedimento de migração pull live.

Usuários e funções do banco de dados

O Atlas não migra nenhum dado de usuário ou papel para o cluster de destino.

Se o cluster de origem não usar autenticação, você deverá criar um usuário no Atlas porque o Atlas não oferece suporte à execução sem autenticação.

Se o cluster de origem impuser autenticação, você deverá recriar as credenciais que seus aplicativos utilizam no cluster do Atlas de destino. O Atlas utiliza SCRAM para autenticação de usuário. Para saber mais, consulte a página Configurar usuários do banco de dados.

Balanceadores de cluster de origem e destino

Para evitar qualquer impacto no desempenho de gravação durante a migração, o Atlas interrompe os balanceadores de cluster fragmentados nos clusters de origem e destino no início do procedimento e inicia os balanceadores no final do procedimento.

Se você cancelar a migração live, o Atlas reiniciará os balanceadores nos clusters de origem e destino.

Se o Atlas não puder reiniciar o balancer de carga nos clusters de origem ou destino no final de uma migração live bem-sucedida, um banner de aviso indicará que você deve reiniciar manualmente o balancer de cluster de origem ou destino.

Configuração do cluster de destino

Ao configurar o cluster de destino, considere o seguinte:

• O processo de migração em tempo real transmite dados através de um servidor de migração em tempo real gerenciado pelo MongoDB. Cada servidor é executado na infraestrutura hospedada na região mais próxima ao cluster de origem. As seguintes regiões estão disponíveis:

  Europa

  • Frankfurt

  • Irlanda

  • Londres

  Américas

  • Leste dos EUA

  • Oeste dos EUA

  APAC

  • Mumbai

  • Cingapura

  • Sydney

  • Tóquio

• Use a região de nuvem para o cluster de destino no Atlas que tenha a menor latência de rede em relação aos servidores das aplicações ou ao seu sistema hospedado no cluster de origem. O ideal é que os servidores da sua aplicação estejam executando na nuvem na mesma região que a região primária do Atlas cluster de destino. Para saber mais, consulte Provedores de nuvem.

• O cluster de destino no Atlas deve corresponder ou exceder a implantação de origem em termos de RAM, CPU e armazenamento. Provisione um cluster de destino de tamanho adequado para que ele possa acomodar o processo de migração e a carga de trabalho esperada, ou escale o cluster de destino para um nível com mais capacidade de processamento, largura de banda ou E/S de disco.

• Para maximizar o desempenho da migração, use pelo menos um cluster M40 para o cluster de destino. Ao migrar grandes conjuntos de dados, use um cluster M80 com 6000 discos IOPS ou superior.

  Você também pode optar por aumentar temporariamente o tamanho do cluster do Atlas de destino durante o processo de migração.

  Depois de migrar a carga de trabalho do aplicativo para um cluster no Atlas, entre em contato com o suporte para obter assistência com o ajuste de desempenho adicional e o dimensionamento do cluster de destino para minimizar os custos.

• Para evitar alterações inesperadas no dimensionamento, desative o dimensionamento automático no cluster de destino. Para mais informações, consulte Gerenciar Clusters.

• Para evitar o crescimento ilimitado da coleção de oplog e garantir que a janela de atraso da migração live permaneça dentro dos limites da janela de atraso de replicação do oplog, defina um tamanho de oplog para um valor fixo grande o suficiente para a duração do processo de migração live.

  Para saber mais, consulte:

  • Dimensionar um cluster

  • Opções de configuração do Atlas

  • Dimensionamento do oplog na documentação do Cluster-to-Cluster Sync .

  Se você estiver observando problemas de desempenho mesmo depois de seguir essas recomendações, entre em contato com o suporte.

• Não é possível selecionar um cluster de camada M0 (Camada Gratuita) ou M2/M5 de camada compartilhada como o cluster de destino para migração ao vivo.

• Não altere o sinalizador featureCompatibilityVersion enquanto a migração em tempo real do Atlas estiver em execução.

Evite cargas de trabalho no cluster de destino

Evite executar quaisquer cargas de trabalho, inclusive aquelas que possam estar sendo executadas em namespaces que não se sobreponham ao processo de migração em tempo real, no cluster de destino. Essa ação evita possíveis conflitos de bloqueio e degradação de desempenho durante o processo de migração ao vivo.

Não execute várias migrações para o mesmo cluster de destino ao mesmo tempo.

Não inicie o processo de corte de seus aplicativos para o cluster de destino enquanto o processo de migração ao vivo estiver sincronizando.

Evite backups em nuvem

O Atlas para de tirar snapshots de backup em nuvem sob demanda do cluster de destino durante a migração ao vivo. Depois que você concluir a etapa de cutover no procedimento de migração em tempo real nesta página, o Atlas retomará a captura de snapshots de backup na nuvem com base em sua política de backup.

Evitar eleições

O processo de migração ao vivo faz a melhor tentativa de continuar uma migração durante interrupções temporárias de rede e eleições nos clusters de origem ou destino. No entanto, esses eventos podem causar falha no processo de migração ao vivo. Se o processo de migração em tempo real não puder ser recuperado automaticamente, reinicie-o desde o início.

Lista de verificação de pré-migração

Antes de iniciar o procedimento de migração live:

• Se você ainda não tiver um cluster de destino, crie uma nova implantação do Atlas e configure-o conforme necessário. Para documentação completa sobre a criação de um cluster do Atlas, consulte Criar um Cluster.

• Depois que o cluster do Atlas for distribuído, certifique-se de que você possa se conectar a ele a partir de todo o hardware cliente em que suas aplicações são executadas. Testar sua cadeia de conexão ajuda a garantir que seu processo de migração de dados possa ser concluído com indisponibilidade mínima.

  1. Baixe e instale mongosh em uma máquina cliente representativa, se você ainda não a tiver.

  2. Conecte-se ao cluster de destino usando a cadeia de conexão da IU do Atlas. Para mais informações, consulte Conectar via mongosh.

  Depois de verificar sua conectividade com o cluster de destino, inicie o procedimento de migração ao vivo.

Procedimento