Execute a migração em produção (Pull) de um conjunto de réplicas no Atlas (MongoDB anterior a 6.0.13)

Caminho de migração

A migração live (pull) do Atlas é compatível com os seguintes caminhos de migração:

Acesso à rede

Configurar permissões de rede para os seguintes componentes:

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

Antes de iniciar o procedimento de migração live, o Atlas executa verificações de validação nos clusters de origem e destino.

• O cluster de origem é um conjunto de réplicas.

  Se o cluster de origem for autônoma, converta o autônomo em um conjunto de réplicas antes de usar a migração em produção do tipo pull.

• O Atlas cluster de destino é um conjunto de réplicas.

Segurança do cluster de origem

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

• Para agrupamentos de origem, um usuário deve ter as funções readAnyDatabase, clusterMonitor e backup.

  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.

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

  Além disso, o usuário do banco de dados do cluster de origem deve ter a função de ler o oplog no banco de dados admin. Para saber mais, consulte Oplog Access.

• Nos clusters de origem que executam o MongoDB 3.4, o usuário deve ter, no mínimo, as funções clusterMonitor e readAnyDatabase. Por exemplo:

   use admin
   db.createUser(
     {
       user: "mySourceUser",
       pwd: "mySourceP@$$word",
       roles: [ "clusterMonitor", "readAnyDatabase" ]
     }
   )

• Em clusters de origem que executam o MongoDB 3.2, um usuário deve ter, no mínimo, ambas as funções de clusterManager e readAnyDatabase, bem como acesso de leitura no banco de dados local. Isso requer uma função personalizada, que você pode criar com os seguintes comandos:

    use admin
    db.createRole(
         {
           role: "migrate",
           privileges: [
             { resource: { db: "local", collection: "" }, actions: [ "find" ] }
           ],
           roles: ["readAnyDatabase", "clusterManager"]
         }
       )
     db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "migrate" ]
         }
       )

• Para clusters de origem que executam o MongoDB 2.6 ou 3.0, o usuário deve ter, no mínimo, a função readAnyDatabase. Por exemplo:

    use admin
       db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "readAnyDatabase" ]
         }
       )

Especifique o nome de usuário e senha para Atlas quando solicitado pelo procedimento de migração ao vivo.

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

Suporte para autenticação SCRAM iniciada no MongoDB 3,0. Se o cluster de origem estiver executando o MongoDB 2.6, você poderá migrá-lo usando a migração pull live sem habilitar a autenticação SCRAM.

Se o cluster de origem utilizar um mecanismo de autenticação diferente para conectar, você poderá utilizar o mongomirror para migrar dados do cluster de origem para o Atlas cluster de destino.

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 relatório técnico Atlas Security. Em particular, revise a seção "Acesso de pessoal do MongoDB aos clusters do MongoDB Atlas".

Limites da chave do índice

Se a implantação do MongoDB contiver índices com chaves que excedam o Limite de chave de índice, antes de iniciar o procedimento de migração em produção, modifique os índices para que eles não contenham chaves de tamanho grande.

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.

Suporte para autenticação SCRAM iniciada no MongoDB 3,0. Se o cluster de origem estiver executando o MongoDB 2.6, você poderá migrá-lo usando a migração pull live sem habilitar a autenticação SCRAM.

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

  • London

  Americas

  • Leste dos EUA

  • Oeste dos EUA

  APAC

  • Mumbai

  • Cingapura

  • Sydney

  • Tokyo

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

• O Atlas cluster de destino deve ser um conjunto de réplicas.

• 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 é possível migrar um cluster para o MongoDB v6.0 ou posterior usando o procedimento nesta página.

  Se seus clusters de origem e destino estiverem executando o MongoDB 6.0.13 ou posterior, você poderá migrar em produção para o Atlas usando este procedimento.

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

Evite Volumes 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 alterações no namespace

Não faça nenhuma alteração de namespace durante o processo de migração, por exemplo, utilizar o comando renameCollection ou executar um pipeline de agregação que inclua o estágio de agregação do $out.

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 em produção:

• 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

A migration to your Atlas cluster will expire in <number> hours!
Navigate to your destination cluster to start the cutover process. If
you don't take any action within <number> hours, the migration will be
cancelled and you will need to start again. You can also extend the
migration process if you need more time.