Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs
Página inicial do Docs
/
Gestão
/
Migre ou importe dados
Página inicial do Docs
/
Gestão
/
Migre ou importe dados
Página inicial do Docs
/
Gestão
/
Migre ou importe dados

Migre ao vivo (pull) um cluster para o Atlas

Importante

The feature described on this page is not currently supported on Atlas Infinite clusters during public preview. For the features supported in public preview, see Public Preview Availability.

o Atlas pode puxar um cluster de origem para um cluster do Atlas usando o procedimento descrito nesta seção.

This process uses Mongosync as the underlying data migration tool, enabling faster live migrations with less downtime:

  • O Atlas sincroniza dados da origem para o cluster do Atlas até que você transfira sua aplicação para o cluster do Atlas.

  • At the Atlas-managed or self-managed cutover step in the following procedure, complete these steps:

    • Pare as gravações no cluster de origem.

    • Pare suas instâncias de aplicativo, aponte para o Atlas cluster e reinicie-as.

Restrições

Todas as limitações do Mongosync se aplicam a esta migração ao vivo. Para saber mais sobre essas limitações, consulte Limitações do Mongosync.

Os clusters Flex não aceitam esse recurso no momento. Para saber mais, consulte Limitações do Atlas Flex.

Além disso, a migração ao vivo (pull) não suporta:

  • Migrar clusters que usam Latest Version With Auto Upgrades.

  • Usando emparelhamento VPC ou private endpoints como o caminho de dados de migração. As migrações em produção do Atlas para o Atlas transferem dados pela rede backbone gerenciada pelo Atlas. Você ainda pode usar o emparelhamento VPC ou private endpoints para conectividade de aplicativos aos seus clusters, mas o processo de migração em si não usa essas configurações de rede.

Live migration doesn't support migrating MongoDB Search indexes from a source cluster to the destination cluster.

Importante

A migração em produção e o Mongosync não são suportados em versões secundárias e, portanto, não funcionarão se o cluster usar Latest Version With Auto Upgrades. Para migrar um cluster que está atualmente em uma versão secundária, use ferramentas de migração autoguiadas.

Caminhos de migração suportados

A migração em produção do Atlas descrita nesta seção é compatível com os seguintes caminhos de migração:

cluster de origem
Versão do MongoDB
Cluster do Atlas de destino
Versão do MongoDB

5.0 Conjunto de réplicas

7.0 Conjunto de réplicas

5.0 Conjunto de réplicas/cluster fragmentado

7.0 Cluster fragmentado

6.0 Conjunto de réplicas

7.0 Conjunto de réplicas

6.0 Conjunto de réplicas

8.0 Conjunto de réplicas

6.0 Conjunto de réplicas/cluster fragmentado

7.0 Cluster fragmentado

6.0 Conjunto de réplicas/cluster fragmentado

8.0 Cluster fragmentado

7.0 Conjunto de réplicas

7.0 Conjunto de réplicas

7.0 Conjunto de réplicas

8.0 Conjunto de réplicas

7.0 Conjunto de réplicas/cluster fragmentado

7.0 Cluster fragmentado

7.0 Conjunto de réplicas/cluster fragmentado

8.0 Cluster fragmentado

8.0 Conjunto de réplicas

8.0 Conjunto de réplicas

8.0 Conjunto de réplicas/cluster fragmentado

8.0 Cluster fragmentado

Acesso necessário

To live migrate your data, you must have Project Owner and clusterMonitor access to Atlas.

Os usuários com acesso Organization Owner devem se adicionar ao projeto como um Project Owner.

Pares de configuração de cluster de origem e destino suportados

Para esse tipo de migração em produção, o Atlas suporta os seguintes pares de configuração de cluster de origem e destino:

Configuração do cluster de origem
Configuração do cluster de destino
Suporte à migração live
Notas

Autônomo

Qualquer tipo de cluster

Before migrating a standalone source cluster using this migration procedure, convert the standalone to a replica set.

Conjunto de réplicas

Conjunto de réplicas

Conjunto de réplicas

Cluster fragmentado

Ao executar este tipo de migração, você pode especificar os parâmetros de fragmentação. Para saber mais, consulte o procedimento de migração em produção nesta seção e este exemplo de fragmentação.

Cluster fragmentado

Cluster fragmentado

The number of shards in source and destination clusters might differ. The source sharded cluster must use CSRS (Config Server Replica Sets). To learn more, see Replica Set Config Servers.

Cluster fragmentado

Conjunto de réplicas

Pré-requisitos

  • Se o cluster for executado com autenticação, atenda aos seguintes pré-requisitos:

Importante

Fonte Prontidão do cluster

Para ajudar a garantir uma migração de dados tranquila, seu cluster de origem deve atender a todas as recomendações de cluster de produção. Verifique a Lista de verificação de operações e as Notas de produção antes de iniciar o processo de migração ao vivo.

Observação

Você não pode migrar um cluster em estado inativo. O cluster que executa o MongoDB deve estar operacional para que a migração ao vivo para o Atlas ocorra, pois o Atlas migra um membro do cluster por vez, começando pelos membros secundários e finalizando pelo membro primário. Certifique-se de que seu cluster esteja em execução antes de tentar a migração.

Acesso à rede

Configurar permissões de rede para os seguintes componentes:

O firewall do cluster de origem permite tráfego do servidor de migração ao vivo

Todos os firewalls para o cluster de origem devem conceder ao servidor de migração ao vivo do MongoDB acesso ao cluster de origem.

O processo de migração ao vivo do Atlas transmite dados através de um servidor de migração ao vivo controlado pelo MongoDB. O Atlas fornece os intervalos IP dos servidores de migração em tempo real MongoDB durante o processo de migração em tempo real. Conceda a esses intervalos de IP acesso ao cluster de origem. Isso permite que o servidor de migração em tempo real MongoDB se conecte aos clusters de origem.

Observação

If your organization has strict network requirements and you cannot enable the required network access to MongoDB live migration servers, see Live Migrate a Community Deployment to Atlas.

Atlas Cluster permite o tráfego de seus servidores de aplicativos

O Atlas permite conexões com um cluster de hosts adicionados à lista de acesso IP do projeto. Adicione os endereços IP ou blocos CIDR dos hosts de aplicativos à lista de acesso IP do projeto. Faça isso antes de iniciar o procedimento de migração.

O Atlas adiciona temporariamente os endereços IP dos servidores de migração MongoDB à lista de acesso IP do projeto. Durante o procedimento de migração, você não pode editar ou excluir esta entrada. O Atlas remove esta entrada assim que o procedimento for concluído.

Para saber como adicionar entradas à lista de acesso de IP do Atlas, consulte Configurar entradas de lista de acesso de IP.

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:

  • The source cluster's database user has the correct permissions as described in Source Cluster Security.

  • O cluster de origem não contém o banco de dados de metadados mongosync_reserved_for_internal_use. Você deve descartar manualmente esse banco de dados antes de iniciar a migração.

  • O Atlas cluster de destino não deve ter dados. Se o cluster tiver quaisquer dados antes de começar, você terá a opção de limpar os dados no cluster de destino durante o processo de migração live. Como alternativa, você pode excluir manualmente os dados no cluster de destino antes de iniciar o procedimento de migração.

Observação

If you are migrating from a sharded source cluster running MongoDB version 5.0, you must first run the following cleanupOrphaned command on the primary replica set member of each shard in the source cluster. This command ensures all orphaned documents are correctly purged before the migration.

db.runCommand({cleanupOrphaned: "<database>.<collection>"})

Segurança do cluster de origem

O usuário de migração precisa das seguintes funções integradas, além de uma função personalizada que inclua as ações de bloqueio de gravar:

For source replica set clusters, a MongoDB user must have the readAnyDatabase, backup roles and the bypassWriteBlockingMode action.

For source sharded clusters a MongoDB user must have the readAnyDatabase, backup, clusterMonitor roles and the bypassWriteBlockingMode action.

You must add the bypassWriteBlockingMode action to a custom role and assign it to the user who will do the migration. You can add the role on Atlas or self-managed clusters.

The custom role must include the setUserWriteBlockMode and bypassWriteBlockingMode actions on the cluster resource. For a self-managed source cluster, run the following commands in mongosh to create the custom role and assign it to the migration user:

use admin
db.createRole({
  role: "LiveMigrateWriteBlockingCustomRole",
  privileges: [
    {
      resource: { cluster: true },
      actions: [ "setUserWriteBlockMode", "bypassWriteBlockingMode" ]
    }
  ],
  roles: []
})
db.grantRolesToUser("admin", [
  { role: "LiveMigrateWriteBlockingCustomRole", db: "admin" }
])

Para um cluster de origem do Atlas, crie a função personalizada com o Atlas CLI ou a IU do Atlas e, em seguida, atribua-a aos usuários de banco de dados:

atlas customDbRoles create LiveMigrateWriteBlockingCustomRole \
  --privilege SET_USER_WRITE_BLOCK,BYPASS_USER_WRITE_BLOCK

Na IU do Atlas, selecione as ações setUserWriteBlockMode e bypassWriteBlockingMode no campo Action or Role. Para saber mais, consulte Adicionar funções personalizadas.

To verify that the database user who will run the live migration process has these roles, run the db.getUser() command on the admin database. For example, for a replica set, run:

use admin
db.getUser("admin")
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
  {
    "role" : "backup",
    "db" : "admin"
  },
  {
    "role" : "readAnyDatabase",
    "db" : "admin"
  }
  ,
  {
    "role" : "LiveMigrateWriteBlockingCustomRole",
    "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.

Atlas only supports SCRAM for connecting to source clusters that enforce authentication.

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:

  • MongoDB encrypts data in transit between the Atlas-managed live migration server and the destination cluster. If you require encryption for data in transit between the source cluster and the Atlas-managed migration server, configure TLS on your source cluster. To learn more, see Configure TLS/SSL.

  • 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 de privilégio mínimo e autoriza apenas um pequeno grupo de usuários privilegiados a acessar seus clusters do Atlas por um tempo mínimo e limitado necessário para corrigir o problema crítico. O MongoDB exige MFA para que esses usuários possam se conectar aos clusters do Atlas e estabelecer uma conexão SSH por meio do host bastion. A concessão deste tipo de acesso de usuário privilegiado requer aprovação da diretoria do MongoDB. O MongoDB não permite o acesso de nenhum outro funcionário 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".

Considerações

Criptografia de rede

During pull live migrations, if the source cluster does not use TLS encryption for its data, the traffic from the source cluster to Atlas is not encrypted. Determine if this is acceptable before you start a pull live migration procedure. To configure TLS on your source cluster, see Configure TLS/SSL.

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 Configurar usuários de banco de dados.

Requisitos de oplog

Requisitos do cluster de origem:

  • Para garantir que a janela de atraso da migração live permaneça dentro dos limites da janela de atraso de replicação do oplog, faça uma das seguintes ações no cluster de origem:

Requisitos do cluster de destino:

  • Para acomodar possíveis flutuações no tamanho do armazenamento relacionadas aos requisitos de tamanho do oplog, recomendamos que você escolha uma camada do cluster de destino que esteja pelo menos dois níveis acima do cluster de origem.

  • A migração live executa a verificação incorporada por padrão, o que exige que o cluster de destino tenha um tamanho de oplog grande. Isso evita erros no processo de verificação devido a um tamanho restrito de oplog.

    Se não for possível alocar um tamanho de oplog grande o suficiente ou aumentar uma janela mínima de oplog no cluster de destino, desative a opção Verify data post-migration (recommended) na interface de migração live e use um dos métodos de verificação de migração live descritos em Mongosync: Verificar transferência 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 fragmentado 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.

If Atlas can't restart the load balancer on the source or destination clusters at the end of a successful live migration, a warning banner indicates that you must manually restart the source or destination cluster balancer.

Configuração do cluster de destino

Ao configurar o cluster de destino, considere o seguinte:

  • O Atlas cluster de destino não deve ter dados. Se o cluster tiver quaisquer dados antes de começar, você terá a opção de limpar os dados no cluster de destino durante o processo de migração live. Como alternativa, você pode excluir manualmente os dados no cluster de destino antes de iniciar o procedimento de migração.

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

    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 gratuito (anteriormente conhecido como M0) ou um cluster flexível como cluster de destino para a migração em produção.

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

Verificador incorporado

O verificador incorporado é ativado por padrão para migrações de até 5 TB e 3 shards. Para migrações que excedem qualquer um desses limites, o verificador incorporado é desativado por padrão.

Evite cargas de trabalho no cluster de destino

As gravações são bloqueadas durante a migração live:

  • Quando uma migração live começa, as gravações no cluster de destino são bloqueadas. As tentativas de executar gravações no cluster de destino falham.

  • Antes de prosseguir com a transição, você deve interromper manualmente a gravação em seu cluster de origem. O Atlas impõe isso ativando o bloqueio de gravação no cluster de origem durante o processo de transição.

    Importante

    O bloqueio de escrita do cluster de origem e destino durante a transferência ocorrerá se você estiver migrando o cluster de origem que executa o MongoDB versão 6.0 e posterior.

  • Depois que uma migração live for concluída com êxito ou falhar, as gravações no cluster de destino poderão continuar.

    Observação

    O Atlas tenta remover automaticamente os blocos de gravação quando a migração é concluída.

    If you need to manually remove the write block on your cluster, use the setUserWriteBlockMode command with the global field set to false:

    db.adminCommand( {
      setUserWriteBlockMode: 1,
      global: false
    } )

    To run the setUserWriteBlockMode command, the user must have the setUserWriteBlockMode privilege.

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 pausa os snapshots de backups em nuvem programados e sob demanda do cluster de destino enquanto a migração em produção está em execução. Depois que você concluir a etapa de cutover no procedimento de migração em produção nesta página, o Atlas retomará automaticamente a captura de snapshots de backups em 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.

Migre seu cluster

Observação

Migrações de preparação e produção

Consider running this procedure twice. Run a partial migration that stops at the Perform the Cutover step first. This creates an up-to-date Atlas-backed staging cluster to test application behavior and performance using the latest driver version that supports the MongoDB version of the Atlas cluster.

Depois de testar sua aplicação, execute o procedimento completo de migração usando um Atlas cluster separado para criar seu ambiente de produção com suporte do Atlas.

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 do Atlas Infinite ou Atlas Core.

  • 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. Download and install mongosh on a representative client machine, if you don't already have it.

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

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

Procedimento

1
No Atlas, vá para o Migration Hub do seu projeto.

  1. Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione seu projeto no menu Projects na barra de navegação.

  3. Na barra lateral, clique em Migration sob o título Services.

O Hub de Migração é exibido.

2

Clique em Migrate from Atlas para iniciar o processo de migração.

O Atlas exibe uma tela de apresentação com instruções sobre como proceder com a migração live. O processo sincroniza os dados do cluster de origem com o novo cluster de destino. Depois de concluir o passo a passo, você poderá apontar seu aplicativo para o novo cluster.

3

Clique em Get Started para configurar os detalhes da migração.

A tela Migration from Atlas to Atlas é exibida.

4

Defina suas configurações de migração em produção na tela Set up Migration.

  1. Conecte-se ao seu cluster de origem.

    1. Selecione a origem Organization no menu suspenso.

    2. Selecione a origem Project no menu suspenso.

    3. Selecione a origem Cluster no menu suspenso.

  2. Conecte seu cluster de destino.

    Observação

    Você só pode selecionar um cluster de destino que pertença à organização da qual iniciar a migração. Verifique se você está na mesma organização que o cluster de destino para iniciar o processo de migração.

    1. Selecione o Project de destino no menu suspenso.

    2. Selecione o Cluster de destino no menu suspenso.

      O cluster de destino deve ser um Atlas cluster novo ou vazio. Se o cluster de destino tiver quaisquer dados existentes, você poderá optar por excluir esses dados durante o processo de migração. Se você deixar essa opção desmarcada e o cluster de destino tiver quaisquer dados durante o processo de migração, a migração falhará e emitirá um erro de validação.

  3. Definir configurações adicionais.

    • O Atlas exibe uma caixa de seleção para Verify data post-migration (recommended). Se você marcar esta opção, o Atlas verificará automaticamente os dados suportados após a migração. Se você deixar esta opção desmarcada, deverá executar a verificação de dados completa manualmente. Para saber mais, consulte Verificar Migrações.

    • Se o seu cluster de destino tiver quaisquer dados existentes e você marcar a opção Clear any existing data on your destination cluster?, o Atlas excluirá os dados existentes. Se você deixar essa opção desmarcada e o cluster de destino tiver dados com namespaces conflitantes durante o processo de migração, a migração falhará e emitirá um erro de validação.

    • Se você estiver migrando um conjunto de réplicas para um cluster fragmentado:

      • Se você quiser shard as coleções, clique na marca de seleção em Include sharding parameters e cole seu JSON de configuração de sharding na caixa de texto usando o exemplo de sharding. Salve esta configuração em um arquivo externamente, caso você precise consultá-la mais tarde.

        The sharding configuration JSON defines the shardingEntries array, which specifies the collections to shard, and the keys to use for sharding. MongoDB shards only those collections that you include into this array. To learn more, see Sharding.

        Se você omitir a especificação da configuração de fragmentação, poderá fragmentar as coleções no cluster de destino após migrar o cluster para o Atlas.

      • Além da configuração de fragmentação, um índice compatível para as chaves de fragmentação especificadas deve existir no cluster de destino em serviço.

        Marque a opção Create supporting indexes para que o MongoDB crie automaticamente índices de chaves de fragmento de suporte no cluster de destino no Atlas.

5

Clique em Continue para validar seus dados.

  1. O botão Continue muda para Validating... enquanto o Atlas valida as informações que você forneceu.

    Se a validação falhar, verifique se:

    • Você adicionou o Atlas à lista de acesso IP em seu cluster de origem.

    • As credenciais de usuário fornecidas, se houver, existem no cluster de origem e têm as permissões necessárias.

    • O arquivo CA fornecido, se houver, é válido e correto.

    • Consulte Segurança de Cluster de Origem para obter orientação sobre as permissões de usuário exigidas pela migração em produção do Atlas.

  2. Após completar a validação, clique em Continue novamente.

6

Revise as informações que você forneceu na tela Review & Confirm.

Se precisar alterar alguma informação, clique em Back para retornar à etapa anterior e fazer suas alterações.

  1. Clique em Start Migration.

    Um modal é exibido para confirmar que você deseja iniciar a migração.

7

Clique em Start Migration no modal para iniciar o processo de migração.

Depois que o processo de migração começa, a IU do Atlas exibe a Migrating Data tela passo a passo para o cluster do Atlas de destino. A tela de apresentação é atualizada à medida que o cluster de destino prossegue com o processo de migração. O processo de migração inclui:

  • Aplicação de novas gravações nos dados do cluster de origem nos dados do cluster de destino.

  • A cópia de dados do cluster de origem para o cluster de destino.

  • Finalizando a migração no cluster de destino.

  • Executando o processo de verificação, se você o tiver habilitado. Se você iniciou a migração com a configuração Verify data post-migration (recommended) habilitada, o Atlas notificará que executou a verificação de dados para os tipos compatíveis. Se você iniciou a migração com a verificação desativada, o Atlas solicitará que você verifique seus dados manualmente. Para saber mais, consulte Verificar Migrações.

Um valor de tempo de atraso é exibido durante a fase final do processo de migração que representa o atraso atual entre os clusters de origem e de destino.

Você receberá uma notificação por e-mail quando sua janela de expiração estiver quase terminando.

Quando o atraso atrás da origem está próximo de zero e o processo de migração é recuperado, o Atlas ativa o botão Cutover to your destination cluster e indica que os clusters de origem e destino estão sincronizados. Prossiga para a próxima etapa.

8

Execute a transição.

A substituição é um processo de três etapas de direcionamento das leituras e gravações do aplicativo do cluster de origem para o cluster de destino.

Quando o Atlas detecta que os clusters de origem e destino estão quase sincronizados, ele inicia um temporizador extensível de 120 horas (5 dias) para iniciar o estágio de substituição do procedimento de migração live. Após a passagem do período 120 horas, o Atlas para de sincronizar com o cluster de origem.

Nesse estágio do processo de migração, você pode prosseguir para a substituição ou estender o período de sincronização e, em seguida, prosseguir para a substituição.

  • Se você clicar em I'm ready to cutover, o Atlas iniciará o processo de cutover.

  • Se você clicar em Extend Sync e se a sincronização estendida for concluída com êxito, o Atlas confirmará que os clusters de origem e destino estão sincronizados. Prossiga com o processo de transição. Se o tempo de sincronização expirar, você poderá tentar novamente a migração.

    Se a migração estiver para expirar, o Atlas enviará um e-mail semelhante ao exemplo a seguir:

    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.

  1. Clique I'm ready to cutover. Prossiga com o processo de transição de três etapas rapidamente para garantir o mínimo de tempo de inatividade para seu aplicação.

  2. Clique Proceed to cutover. O processo de transição de três etapas começa:

    1. Interrompa as gravações em seu cluster de origem. Clique I confirm that I've stopped writes to my source cluster. Clique em Finalize migration para prosseguir.

    2. Aguarde alguns minutos enquanto o Atlas finaliza a migração. O Atlas executa estas ações para concluir o processo:

      • Remove as sub-redes do servidor de migração ao vivo do MongoDB da lista de acesso IP no cluster de destino.

      • Remover o usuário de banco de dados que a migração em produção usou para importar dados para o cluster de destino.

      Se o processo de transferência estiver em andamento há pelo menos 12 horas, a Atlas envia um e-mail sugerindo que você verifique o processo de migração ou entre em contato com o suporte.

    3. Se a migração for bem-sucedida, a página You have successfully migrated to Atlas será exibida. O Atlas mostra o status das alterações sincronizadas, o tempo de inatividade do aplicação , a duração do processo de migração, a quantidade de dados iniciais copiados e o número de coleções copiadas.

      • Verifique se seus dados são transferidos para o cluster de destino comparando contagens de documento e executando comparações de hash. Para saber mais, consulte Mongosync: Verificar Transferência de Dados.

      • Clique Connect to your new cluster. O Atlas redirecionará você para a página Connect to Atlas , onde você pode escolher um método de conexão.

      • Depois de se conectar ao cluster, retome as gravações no cluster de destino.

Suporte à migração

Se a sua migração falhar em qualquer estágio do processo de migração em tempo real, o Atlas o notificará por e-mail com um link para explorar os resultados da migração.

Se você tiver alguma dúvida sobre o suporte à migração além do que é abordado nesta documentação, ou se encontrar um erro durante a migração, solicite suporte por meio da IU do Atlas.

Como arquivar um ticket de suporte:

1

No Atlas, acesse a página Support.

  1. Se ainda não estiver exibido, selecione sua organização desejada no Menu Organizations na barra de navegação.

  2. Clique no ícone Support na barra de navegação.

  3. Clique em View plan.

The Support page displays.

2

Solicite suporte.

  1. Clique em Request Support.

  2. Para Issue Category, selecione Help with live migration.

  3. Para Priority, selecione a prioridade apropriada. Para perguntas, selecione Medium Priority. Se houve uma falha na migração, selecione High Priority.

  4. Para Request Summary, inclua Live Migration no seu resumo.

  5. Para More details, inclua quaisquer outros detalhes relevantes à sua pergunta ou erro de migração.

  6. Clique no botão Request Support para enviar o formulário.

Voltar
Verificar migrações
Próximo
Push do Cloud Manager
Avalie esta página

Nesta página