Migração (pull) em produção no MongoDB 6.0.17+ ou 7.0.13+ Cluster no Atlas
Nesta página
Importante
Recurso Indisponível em Instâncias sem Servidor
Neste momento, as instâncias sem servidor não permitem essa funcionalidade. Para saber mais, consulte Limitações de instâncias sem servidor.
Se os clusters de origem e de destino estiverem executando o MongoDB 6.0.17+ ou superior à versão 7.0.13, o Atlas pode puxar um cluster de origem para um cluster do Atlas usando o procedimento descrito nesta seção.
Esse processo usa o mongosync como ferramenta subjacente de migração de dados, permitindo migrações ao vivo mais rápidas com menos tempo de inatividade:
O Atlas sincroniza dados da origem para o cluster do Atlas até que você transfira sua aplicação para o cluster do Atlas.
Depois de atingir a etapa de substituição no procedimento a seguir:
Pare as gravações no cluster de origem.
Pare suas instâncias de aplicativo, aponte para o Atlas cluster e reinicie-as.
Restrições
As limitações Cluster-to-Cluster Sync se aplicam a esta migração em tempo real.
A migração ao vivo (pull) não suporta:
MongoDB 8.0 ou versões rápidas como a versão do cluster de origem ou destino.
Emparelhamento de VPC ou endpoints privados para o cluster de origem ou de destino.
A migração live não suporta a migração de índices do Atlas Search de um cluster de cluster de origem para o cluster de destino.
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:
Source Cluster MongoDB Version | Destination Atlas Cluster MongoDB Version |
---|---|
6.0.17 | 6.0.17 |
7.0.13 | 7.0.13 |
Acesso necessário
Para migrar seus dados ao vivo, você deve ter acesso de Project Owner
ao 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 | Antes de migrar um cluster de origem autônoma usando esse procedimento de migração, converta o cluster autônomo em um conjunto de réplicas. | |
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 | O número de fragmentos nos clusters de origem e destino pode ser diferente. O cluster fragmentado de origem deve usar Servidores de configuração do conjunto de réplicas (CSRS). Para saber mais, consulte a página Servidores de configuração do conjunto de réplicas. | |
Cluster fragmentado | Conjunto de réplicas |
Pré-requisitos
Se o cluster for executado com autenticação, atenda aos seguintes pré-requisitos:
Para conjuntos de réplicas, conceda as funções
backup
ereadAnyDatabase
no banco de dados admin ao usuário que executará o processo de migração.Para clusters fragmentados, conceder as funções
backup
,readAnyDatabase
eclusterMonitor
no banco de dados admin ao usuário que executará o processo de migração. Garanta que o usuário especificado exista em cada fragmento e no conjunto de réplicas do servidor de configuração. O usuário deve ter permissões para as seguintes ações:Pare ou inicie o balanceador de cluster fragmentado.
Leia todos os bancos de dados e coleções no host.
Leia o oplog no host.
Certifique-se de que esse usuário seja autenticado usando SCRAM-SHA-1 e SCRAM-SHA-256. Para saber mais, consulte Segurança do cluster de origem.
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 em produçã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
Se a sua organização tiver requisitos de rede rigorosos e você não puder habilitar o acesso de rede exigido para servidores de migração em produção MongoDB, consulte Migrar ao vivo uma Implantação da Comunidade no Atlas.
Atlas Cluster permite o tráfego de seus servidores de aplicativos
O Atlas permite conexões com um cluster a partir de hosts adicionados à lista de acesso de IP do projeto. Adicione os endereços IP ou blocos CIDR dos hosts do aplicativo à lista de acesso de 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:
A versão do MongoDB do cluster de origem e destino é pelo menos FCV 6.0.17+ e correspondente, ou pelo menos FCV 7.0.13+ 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.
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.
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 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
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.
Requisitos de oplog
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:
Aumente a oplog window mínima. Use essa opção se o auto-scaling de armazenamento estiver ativado (este é o padrão) no cluster de origem.
Aumente o tamanho fixo do oplog. Use essa opção se você desabilitar o auto-scaling de armazenamento no cluster de origem.
A migração ao vivo executa a verificação incorporada por padrão, o que requer um tamanho de oplog grande no cluster de destino. Isso evita erros no processo de verificação devido a um tamanho restrito de oplog.
Se o auto-scaling de armazenamento estiver desabilitado no cluster de destino, aumente o tamanho do oplog no cluster de destino para um valor fixo alto o suficiente.
Se o auto-scaling de armazenamento estiver habilitado no cluster de destino, defina uma oplog window mínima alta o suficiente no cluster de destino.
Se você não puder 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 da migração live descritos em Cluster-to-Cluster Sync: verificar a 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.
Se o Atlas não puder reiniciar o balanceador 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 balanceador de cluster de origem ou destino.
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:
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) ouM2/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.
Migre seu cluster
Observação
Migrações de preparação e produção
Considere executar este procedimento duas vezes. Execute uma migração parcial que pare primeiro na etapa Perform the Cutover. Isso cria um cluster de preparação atualizado com suporte do Atlas para testar o comportamento e o desempenho do aplicativo usando a mais recente versão do driver compatível com a versão do Atlas cluster do MongoDB.
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.
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.
Baixe e instale
mongosh
em uma máquina cliente representativa, se você ainda não a tiver.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
Inicie o processo de migração.
Selecione um cluster do Atlas de destino.
Navegue até o cluster do Atlas de destino e clique no botão reticências .... Na lista de cluster, o botão reticências ... aparece abaixo do nome do cluster. Quando você visualiza os detalhes do cluster, a elipse ... aparece no lado direito da tela, ao lado dos botões Connect e Configuration.
Clique em Migrate Data to this Cluster.
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.
Colete os seguintes detalhes do cluster de origem para facilitar a migração:
Para conjuntos de réplicas, o nome do host e a porta do cluster de origem primary. Por exemplo,
mongoPrimary.example.net:27017
. O Atlas se conecta somente ao membro primary do cluster de origem por padrão. Para aumentar a resiliência e facilitar o failover, se necessário, o Atlas obtém os endereços IP de outros nós do cluster de origem se esses nós tiverem registros DNS disponíveis publicamente.Para clusters fragmentados, o nome do host e a porta de cada
mongos
em cada fragmento. Por exemplo,mongos.example.net:27017
.O nome de usuário e a senha de banco de dados usados para se conectar ao cluster de origem. Para conjuntos de réplicas, o usuário do banco de dados deve ter as funções
readAnyDatabase
ebackup
. Para clusters fragmentados, o usuário do banco de dados deve ter as funçõesreadAnyDatabase
,backup
eclusterMonitor
.Se o cluster de origem usar
TLS/SSL
e não estiver usando uma Autoridade de Certificação (CA) pública, você precisará do arquivo CA do cluster de origem.
Prepare as informações conforme indicado na tela passo a passo e clique em I'm Ready To Migrate.
O Atlas exibe uma tela de passagem que coleta informações necessárias para se conectar ao cluster de origem.
O Atlas exibe o endereço IP do servidor de migração live do MongoDB responsável pela sua migração live na parte superior na tela de apresentação. Configure o firewall do cluster de origem para conceder acesso ao endereço IP exibido.
Para conjuntos de réplicas, insira o nome do host e a porta do nó primário do cluster de origem na caixa de texto fornecida. Para clusters fragmentados, digite o nome do host e a porta de cada
mongos
.Se você estiver migrando um conjunto de réplicas para um cluster fragmentado:
Se você quiser fragmentar as collections, clique na marca de seleção em Include sharding parameters e cole seu JSON de configuração de fragmentação na caixa de texto usando o exemplo de fragmentação. Salve esta configuração em um arquivo externamente, caso você queira consultá-la mais tarde.
A configuração de fragmentação JSON define a matriz
shardingEntries
, que especifica as coleções a serem fragmentadas e as chaves a serem usadas na fragmentação. O MongoDB fragmenta apenas as coleções que você inclui nessa array. Para saber mais, consulte Fragmentação.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.
Se o cluster de origem impor a autenticação, insira um nome de usuário e senha nas caixas de texto fornecidas.
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.
Para conjuntos de réplica, o Atlas exibe a Verify data post-migration (recommended) opção . Se você habilitar esta configuração, o Atlas verificará automaticamente os dados suportados após a migração. Se você desabilitar essa configuração, deverá executar a verificação de dados completa manualmente. Para saber mais, consulte Verificar Migrações.
Se o cluster de origem usar
TLS/SSL
e não estiver usando uma Autoridade de Certificação (CA) pública, ative Is encryption in transit enabled? e copie o conteúdo do arquivo de CA do cluster de origem para a caixa de texto fornecida.Se o seu cluster de destino tiver quaisquer dados existentes, marque a opção para excluir estes dados: Clear any existing data on your destination cluster e então insira o nome do cluster de destino. O Atlas exclui os dados existentes. 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.
Clique em Validate para confirmar que o Atlas pode se conectar ao cluster de origem.
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.
A alternância Is encryption in transit enabled? é ativada somente se o cluster de origem exigir isso.
O arquivo CA fornecido, se houver, é válido e correto.
Clique em Start Migration 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 Verify data post-migration (recommended) configuração 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.
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.
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.
Clique Proceed to cutover. O processo de transição de três etapas começa:
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.
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.
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 Cluster-to-Cluster Sync: 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 interface do usuário do Atlas.
Como arquivar um ticket de suporte:
No Atlas, acesse a página Project Support.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Ao lado do menu Projects, expanda o menu Options e clique em Project Support.
A página Suporte ao Projeto é exibida.
Solicite suporte.
Clique em Request Support.
Para Issue Category, selecione
Help with live migration
.Para Priority, selecione a prioridade apropriada. Para perguntas, selecione
Medium Priority
. Se houve uma falha na migração, selecioneHigh Priority
.Para Request Summary, inclua
Live Migration
no seu resumo.Para More details, inclua quaisquer outros detalhes relevantes à sua pergunta ou erro de migração.
Clique no botão Request Support para enviar o formulário.