Como migrar do MongoDB para o MongoDB Atlas usando a migração em tempo real do Atlas

Last reviewed 2023-03-01 UTC

Este tutorial descreve e implementa uma migração de um Conjunto de réplicas do MongoDB autogerenciado que contém bancos de dados para um cluster totalmente gerenciado no Atlas do MongoDB usando o Serviço de migração em tempo real do Atlas (Migração em tempo real do Atlas) do MongoDB.

Ele é destinado a arquitetos, administradores e engenheiros de bancos de dados interessados em um serviço MongoDB totalmente hospedado ou que são responsáveis por migrar bancos de dados MongoDB em um conjunto de réplicas do MongoDB para um cluster do MongoDB Atlas.

Objetivos

  • Configurar sua fonte autogerenciada criando e carregando documentos em um conjunto de réplicas de amostra do MongoDB.
  • Configurar um cluster de destino de migração no MongoDB Atlas.
  • Usar a migração em tempo real do Atlas para migrar um banco de dados do seu conjunto de réplicas autogerenciado do MongoDB para um cluster Atlas totalmente gerenciado do MongoDB.
  • Entender e selecionar estratégias de teste, transição e substituição.

Este tutorial usa um conjunto de réplicas do MongoDB como origem. A migração de um cluster fragmentado do MongoDB para o MongoDB Atlas não é abordada neste tutorial. A diferença arquitetônica entre um conjunto de réplicas do MongoDB e um cluster fragmentado do MongoDB é explicada no post Stack Exchange: administradores de banco de dados.

Para concluir a migração deste tutorial, use a Migração em tempo real do Atlas, e não o utilitário Atlas mongomirror. O utilitário mongomirror requer a instalação de um agente no ambiente MongoDB de origem e opera em um nível inferior de abstração.

A configuração de migração neste tutorial é uma migração homogênea com uma semântica de cópia. Os dados não são transformados durante a migração e não ocorre nenhuma consolidação de banco de dados ou refragmentação de dados. É possível implementar funcionalidades além de uma semântica de cópia com a tecnologia de integração, como o Striim.

A migração neste tutorial é uma migração unidirecional de um conjunto de réplicas do MongoDB de origem para um cluster de destino do MongoDB Atlas. Após a conclusão da transição do conjunto de réplicas de origem do MongoDB para o cluster de destino, os bancos de dados de origem não são atualizados com as alterações no cluster de destino. Portanto, se você implementar essa solução em um ambiente de produção, não será possível alternar seus aplicativos para bancos de dados de origem atualizados em um substituto. Para mais informações sobre processos de substituição, consulte Migração de banco de dados: conceitos e princípios (Parte 2).

Arquitetura de migração

O diagrama a seguir mostra a arquitetura de implantação criada neste tutorial.

Servidores MongoDB no Compute Engine com o caminho de migração do principal para o MongoDB Atlas.

A seta representa o caminho de migração de dados do conjunto de réplicas do MongoDB de origem em execução no Compute Engine para o cluster de destino em execução no MongoDB Atlas no Google Cloud.

A arquitetura de implantação contém os seguintes componentes:

  • Banco de dados de origem: um conjunto de réplicas autogerenciadas do MongoDB em execução em três instâncias do Compute Engine
  • Banco de dados de destino: um cluster totalmente gerenciado do MongoDB
  • Serviço de migração: uma configuração da migração em tempo real do Atlas para migrar dados da origem para o destino

Neste tutorial, é usado um conjunto de réplicas autogerenciado do MongoDB nas instâncias do Compute Engine, mas é possível implantar um conjunto de réplicas do MongoDB de origem em um data center local ou outro ambiente de nuvem.

A migração em tempo real do Atlas é compatível com uma abordagem de migração de banco de dados com inatividade zero. Durante a migração do conjunto de réplicas do MongoDB de origem, seus aplicativos ainda podem acessar os bancos de dados de origem sem nenhum impacto. Após o carregamento inicial, a migração em tempo real do Atlas migra as alterações à medida que elas ocorrem.

Para executar a transição do banco de dados de origem para o cluster de destino após a migração do conjunto de dados inicial, siga as seguintes etapas:

  1. Suspenda o acesso de gravação ao banco de dados de origem.
  2. Aguarde até que a migração em tempo real do Atlas capture as alterações restantes e aplique-as ao banco de dados de destino.
  3. Execute a transição na migração em tempo real do Atlas.
  4. Interrompa o banco de dados de origem.

Depois que todos os dados forem migrados, a migração em tempo real do Atlas notificará você sobre a linha de status de progresso na interface do usuário. Neste ponto, a migração de dados está concluída, e os sistemas de aplicativos podem começar a acessar o cluster de destino como o novo sistema de registro.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

Para concluir este tutorial, não é possível usar o nível gratuito do MongoDB Atlas. Os tipos de máquina disponíveis no nível gratuito não são compatíveis com a migração em tempo real do Atlas. O tipo de máquina mínimo exigido (M10, no momento da redação deste documento) tem um custo de serviço por hora no MongoDB Atlas. Para gerar uma estimativa de preço, acesse Preços do MongoDB Atlas, clique em Google Cloud Platform e siga as instruções. Se você implementar essa migração na produção, recomendamos que use a versão hospedada regular do MongoDB Atlas.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

  1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Como criar um conjunto autogerenciado de réplicas do MongoDB

Primeiro, instale o conjunto de réplicas do MongoDB no Google Cloud. Esse banco de dados serve como seu banco de dados de origem. Em seguida, verifique se o banco de dados de origem atende a todas as condições prévias necessárias.

Depois de concluir a verificação das condições prévias, é necessário ativar a autenticação e reiniciar a instância de origem do MongoDB. Por fim, para testar a migração, adicione um conjunto de dados de amostra à instância do MongoDB de origem que é migrada para o banco de dados de destino.

Instalar o conjunto de réplicas do MongoDB

  1. No Google Cloud Marketplace, acesse a instalação do conjunto de réplicas do MongoDB no Compute Engine. No momento da redação deste artigo, a versão atual é o MongoDB 4.0.

    Acesse o MongoDB no Cloud Marketplace

  2. Clique em Iniciar. Como várias APIs do Google Cloud estão ativadas, o processo de inicialização pode demorar um pouco.

    Em caso de permissões para vários projetos, uma lista de projetos será exibida. Selecione o projeto para a instalação do MongoDB.

    Um conjunto de réplicas do MongoDB é implantado em um conjunto de instâncias do Compute Engine, de acordo com um modelo do Deployment Manager.

  3. Aceite todas as configurações padrão.

  4. Clique em Implantar.

  5. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

  6. Use ssh para fazer login na instância do Compute Engine que executa o MongoDB principal:

    gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
    

    Substitua:

    • MONGODB_VM_NAME: o nome da réplica principal do conjunto de réplicas do MongoDB
    • PROJECT_ID: o nome do ID do projeto do Google Cloud
    • ZONE_OF_VM: a zona em que sua instância de máquina virtual (VM, na sigla em inglês) está

      Para mais informações, consulte Geografia e regiões.

    Se uma chave SSH for gerada, o sistema solicitará uma senha longa. Se você não quiser fornecer uma senha longa, pressione Enter. Se você fornecer uma, anote-a caso precise dela futuramente.

    Se não for possível se conectar usando o Cloud Shell, clique em SSH para uma VM de nível de servidores no Deployment Manager.

  7. Inicie o shell mongo:

    mongo
    
  8. Liste os bancos de dados atuais:

    show dbs
    

    A resposta será semelhante a:

    admin   0.000GB
    config  0.000GB
    local   0.000GB
    

    Mantenha o shell mongo aberto para os próximos comandos.

Você criou e acessou seu conjunto de réplicas do MongoDB e confirmou que ele está operacional.

Verificar as condições prévias do banco de dados de origem

A migração em tempo real do Atlas exige que o conjunto de réplicas do MongoDB de origem atenda a critérios de configuração específicos ou condições prévias. As verificações são descritas na Visão geral da migração do Atlas e na Documentação do Atlas. Os comandos a seguir são derivados desses recursos. Depois de verificar essas condições prévias e fazer as alterações necessárias, o banco de dados de origem exige outras configurações e uma reinicialização.

Para verificar se todas as condições prévias foram atendidas, faça o seguinte:

  1. No shell mongo, verifique se a versão do MongoDB é 2.6 ou posterior. Em uma instância de banco de dados de produção, abra o shell mongo, conecte-se ao servidor MongoDB usando uma conexão SSH e, em seguida, execute esse comando para determinar a versão.

    db.version()
    

    A saída exibe a versão. Se sua versão for anterior à 2.6, deverá seguir as instruções de upgrade.

  2. Verifique se a implantação atual é um conjunto de réplicas do MongoDB:

    rs.status()
    

    A saída é um status do conjunto de réplicas do MongoDB. A saída a seguir mostra que uma instância do MongoDB foi iniciada sem a ativação do conjunto de réplicas do MongoDB.

    {
        "ok" : 0,
        "errmsg" : "not running with --replSet",
        "code" : 76,
        "codeName" : "NoReplicationEnabled"
    }
    

    Nesse caso, interrompa e reinicie a instância do MongoDB com o conjunto de réplicas do MongoDB ativado. Se você tiver uma instância independente do MongoDB, faça upgrade da instância do MongoDB para um conjunto de réplicas do MongoDB.

  3. Verifique se a autenticação está ativada no cluster de origem fazendo login:

    mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
    

    Substitua:

    • YOUR_ADMIN_USERNAME: o nome de usuário do administrador da implantação

    O conjunto de réplicas do MongoDB criado anteriormente não tem autenticação ativada.

    Se a autenticação não estiver ativada, deverá seguir as instruções para ativar a autenticação. Este é um comando de exemplo para ativar a autenticação, com um exemplo de nome de usuário e senha:

    use admin
    db.createUser(
      {
        user: "myUserAdmin",
        pwd: "myUserAdminPassword",
        roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ]
      }
    )
    

    Depois que a autenticação for ativada, será necessário o papel clusterMonitor do MongoDB para executar o rs.status(). O comando anterior especifica esse papel.

  4. Verifique se o usuário administrador tem os papéis apropriados atribuídos à versão do conjunto de réplicas do MongoDB. Para ver uma lista de papéis que correspondem a uma versão específica, consulte a discussão sobre segurança do cluster de origem na documentação da migração em tempo real do Atlas.

    use admin
    db.getUser("YOUR_ADMIN_USERNAME")
    

    O nome de usuário deve ser colocado entre aspas.

  5. (Opcional) Se a implantação do MongoDB for baseada em uma versão anterior à 4.2, ela conterá índices com chaves que excedem o limite de chave de índice de 1.024 bytes. Nesse caso, defina o parâmetro do servidor do MongoDB failIndexKeyTooLong como falso antes de iniciar o procedimento de migração em tempo real do Atlas.

Ativar a autenticação e reiniciar o conjunto de réplicas do MongoDB

Para ativar a autenticação, os arquivos de chave são necessários, além da criação de um administrador. As etapas a seguir mostram como criar arquivos de chave manualmente. Em um ambiente de produção, considere usar scripts para automatizar o processo.

  1. No Cloud Shell, crie um arquivo de chave:

    openssl rand -base64 756 > PATH_TO_KEY_FILE
    

    Substitua:

    • PATH_TO_KEY_FILE: o local onde sua chave SSH está armazenada, por exemplo, /etc/mongo-key
  2. Ative a autorização para cada uma das três VMs:

    1. Copie o arquivo de chave para a VM:

      gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM
      

      Substitua:

      • NAME_OF_THE_VM: o nome de uma das VMs que executam uma réplica do conjunto de réplicas
      • ZONE_OF_VM: a zona do Google Cloud em que a VM reside, mencionada em NAME_OF_THE_VM
    2. Use ssh para fazer login na VM e alterar o proprietário, bem como as permissões de acesso do arquivo de chave:

      sudo chown mongodb:mongodb PATH_TO_KEY_FILE
      
      sudo chmod 400 PATH_TO_KEY_FILE
      
    3. No editor de texto de sua preferência, abra o arquivo mongod.conf no modo de edição. Se quiser gravar as alterações, talvez seja necessário usar o comando sudo para iniciar o editor de texto.

    4. Edite a seção security da seguinte maneira:

      security:
        authorization: enabled
        keyFile: PATH_TO_KEY_FILE
      
    5. Reiniciar a réplica:

      sudo service mongod restart
      
  3. Verifique se é possível fazer login no conjunto principal de réplicas do MongoDB:

    mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
    

Inserir dados de amostra

Nas etapas a seguir, insira dados de amostra no banco de dados de origem e verifique se os documentos foram inseridos com êxito:

  1. No Cloud Shell, use ssh para se conectar à instância principal do Compute Engine do MongoDB:

    gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
    

    Poderá ser necessário fornecer a senha longa para a chave SSH.

  2. Iniciar o shell mongo:

    mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
    

    Forneça a senha que você especificou quando criou o nome de usuário do administrador.

  3. Criar um banco de dados:

    use migration
    
  4. Criar uma coleção:

    db.createCollection("source")
    
  5. Verificar se a coleção está vazia:

    db.source.count()
    
  6. Adicionar os cinco documentos a seguir como o conjunto de dados inicial:

    db.source.insert({"document_number": 1})
    db.source.insert({"document_number": 2})
    db.source.insert({"document_number": 3})
    db.source.insert({"document_number": 4})
    db.source.insert({"document_number": 5})
    

    A saída para cada um desses comandos é semelhante à seguinte:

    WriteResult({ "nInserted" : 1 })
    
  7. Verifique se você adicionou os cinco documentos à migração da coleção. O resultado deve ser cinco.

    db.source.count()
    

Depois que a migração do banco de dados é configurada e iniciada, esses documentos são migrados para o cluster de destino no MongoDB Atlas.

Como criar um cluster no MongoDB Atlas

No MongoDB Atlas, cluster é conjunto de réplicas do MongoDB. Se você não tiver um cluster configurado como banco de dados de destino, siga as etapas nesta seção. Essas etapas são baseadas na documentação do MongoDB. Se você já tiver um cluster configurado como banco de dados de destino, poderá ignorar esta seção.

  1. No Cloud Marketplace, acesse a página MongoDB Atlas: instalação de nível gratuito.

    Acessar o MongoDB Atlas no Marketplace

  2. Clique em Acessar o site do MongoDB para se inscrever.

  3. Clique em Iniciar seu primeiro cluster.

  4. Preencha as informações necessárias e clique em Primeiros passos gratuitos. Observe as informações que você forneceu.

  5. Clique em Opções de configuração avançadas.

  6. Em Provedor e região do Cloud, selecione Google Cloud Platform e Iowa (us-central1).

  7. Clique na guia Nível do cluster e selecione M10.

  8. Clique na guia Outras configurações, selecione MongoDB 4.0 ou MongoDB 4.2 e desative o backup.

  9. Clique em Criar cluster.

    Aguarde até que a criação do cluster seja concluída. O nome do projeto é Project 0 (com um espaço em branco) e o nome do cluster é Cluster0 (sem o espaço em branco).

O cluster de destino está configurado e em execução no MongoDB Atlas.

Como testar o failover do cluster do MongoDB Atlas

Após a conclusão da migração, o cluster no MongoDB Atlas executa uma reinicialização contínua. Cada um dos membros do cluster é reiniciado por vez. Para garantir que esse processo funcione, teste o failover seguindo as etapas na documentação do MongoDB.

Como iniciar a migração em tempo real

Para migrar os dados da origem para o banco de dados de destino, faça o seguinte:

  1. Faça login no MongoDB Atlas.

  2. Acesse a página Clusters e selecione o cluster para o qual você quer migrar.

  3. No painel do cluster de destino (Cluster 0), clique no botão de reticências .

  4. Selecione Migrar dados para este cluster.

  5. Na janela exibida, revise as informações. Quando estiver pronto para migrar, clique em Estou pronto para migrar.

    Uma janela com instruções de migração de dados é exibida. Os endereços IP listados precisam ser capazes de acessar o conjunto de réplicas do MongoDB. Se você não tiver criado uma regra de firewall para esses endereços, use o Cloud Shell para adicionar uma regra de firewall com base neste comando de exemplo:

    gcloud compute firewall-rules create "allow-mongodb-atlas" --allow=tcp:27027 --source-ranges="35.170.231.208/32,3.92.230.111/32,3.94.238.78/32,54.84.208.96/32" --direction=INGRESS
    
  6. No campo Nome do host: porta do conjunto principal de réplicas, insira o endereço IP e a porta do conjunto principal de réplicas do MongoDB, por exemplo, IP_ADDRESS:PORT_FOR_PRIMARY.

    1. Para determinar a instância principal, execute o seguinte comando no shell mongo em qualquer instância em execução no projeto do Google Cloud:

      rs.isMaster().primary

    2. Para pesquisar o endereço IP externo correspondente, acesse a página Instâncias de VM do Compute Engine. A porta padrão do MongoDB é 27017.

  7. Digite o nome de usuário e a senha de administrador do seu conjunto de réplicas do MongoDB.

    Mantenha os valores padrão de todas as outras configurações.

  8. Clique em Validar e, em seguida, siga um destes procedimentos:

    • Se a validação for bem-sucedida, clique em Iniciar migração.
    • Caso contrário, solucione o problema usando as instruções fornecidas. Por exemplo, se o MongoDB Atlas não puder se conectar ao conjunto de réplicas do MongoDB, ele fornecerá os endereços IP dos quais o MongoDB Atlas está tentando se conectar. Para esses endereços, adicione uma regra de firewall que permita o tráfego TCP na porta 27017 para os servidores do conjunto de réplicas do MongoDB.

    A tela do MongoDB Atlas mostra o progresso realizado. Aguarde a mensagem Sincronização inicial concluída na barra de progresso.

O carregamento inicial do conjunto de réplicas do MongoDB foi concluído. O próximo passo é verificar se o carregamento inicial foi bem-sucedido.

Após a conclusão da migração inicial, o MongoDB Atlas fornece uma estimativa do número de horas restantes até que você precise fazer a transição para o cluster de destino. Você também pode receber um e-mail do MongoDB com o número de horas restantes, a capacidade de estender esse tempo e um aviso de que a migração será cancelada, caso uma transição final não seja feita dentro de um determinado período.

Como verificar a migração do banco de dados

É importante projetar e implementar uma estratégia de verificação de migração de banco de dados para confirmar se a migração foi bem-sucedida. Embora a estratégia de verificação específica dependa do seu caso de uso individual, recomendamos que você realize estas verificações:

  • Verificação de preenchimento. Verifique se o conjunto de documentos inicial foi migrado dos bancos de dados de origem (carregamento inicial).
  • Verificação dinâmica. Verifique se as alterações nos bancos de dados de origem estão sendo transferidas para os bancos de dados de destino (migração contínua).

Primeiro, verifique se o carregamento inicial foi bem-sucedido:

  1. No MongoDB Atlas, clique em Clusters.

  2. Clique em Coleções.

  3. Verifique se um banco de dados denominado migrations existe e se a coleção denominada source tem cinco documentos.

Em seguida, verifique se as alterações em andamento nos bancos de dados de origem são refletidas nos bancos de dados de destino:

  1. No Cloud Shell, use ssh para fazer login na VM principal do conjunto de réplicas do MongoDB de origem.

  2. Inicie o shell mongo. mongo

  3. Inserir outro documento:

    use migration
    db.source.insert({"document_number": 6})
    
  4. Na página Coleções do MongoDB Atlas da coleção de migração, clique em Atualizar para verificar que um documento foi adicionado à coleção source.

Você verificou que todos os dados originais e todas as alterações em andamento na origem foram migrados automaticamente para o destino pela migração em tempo real do Atlas.

Como testar o cluster de destino do Atlas

Em um ambiente de produção, os testes são fundamentais. É necessário testar aplicativos que acessam bancos de dados de destino para garantir que eles funcionem corretamente. Esta seção discute várias estratégias de teste.

Testar aplicativos com um banco de dados de destino durante uma migração

Conforme demonstrado na seção anterior, é possível realizar testes de aplicativos durante uma migração de banco de dados em andamento. Essa abordagem pode funcionar se os aplicativos não alterarem o destino de modo que ele entre em conflito com os dados migrados dos bancos de dados de origem. Essa abordagem pode ser uma opção dependendo do seu ambiente e das dependências. Se o aplicativo de teste gravar dados no banco de dados de destino, ele poderá entrar em conflito com a migração em andamento.

Testar aplicativos com um banco de dados de destino temporário

Se não for possível testar os aplicativos durante uma migração do banco de dados de produção, migre os dados para os bancos de dados de destino temporários usados apenas para testes e, em seguida, exclua os destinos de teste após uma migração de teste.

Para usar esse método, interrompa a migração de teste em algum momento (como se a migração do banco de dados fosse concluída) e teste os aplicativos nesses bancos de dados de teste. Após a conclusão do teste, exclua os bancos de dados de destino e inicie a migração do banco de dados de produção para migrar os dados para bancos de dados de destino permanentes. A vantagem dessa estratégia é que os bancos de dados de destino podem ser lidos e gravados porque são apenas para testes.

Testar aplicativos com um banco de dados de destino após a conclusão da migração

Se nenhuma dessas duas primeiras estratégias for viável, a estratégia restante será testar o aplicativo no banco de dados após a conclusão da migração. Depois que todos os dados estiverem nos bancos de dados de destino, teste os aplicativos antes de disponibilizá-los aos usuários. Se o teste incluir a gravação de dados, é importante que os dados de teste sejam gravados, e não os dados de produção, para evitar inconsistências de dados de produção. Os dados de teste precisam ser removidos após a conclusão dos testes para evitar inconsistências de dados ou dados desnecessários no banco de dados de destino.

Recomendamos que você faça o backup dos bancos de dados de destino antes de abri-los para acesso de produção por sistemas de aplicativos. Essa etapa ajuda a garantir que haja um ponto de partida consistente que você possa recriar, se necessário.

Como reduzir a réplica do MongoDB de origem definida para o cluster de destino

Depois de concluir todos os testes e verificar se as alterações em andamento são refletidas no banco de dados de destino, é possível planejar a transição.

Primeiro, é necessário interromper todas as alterações no banco de dados de origem para que a migração em tempo real do Atlas possa drenar as alterações ainda não migradas para o destino. Depois que todas as alterações forem capturadas no destino, você poderá iniciar o processo de transição da migração em tempo real do Atlas. Após a conclusão desse processo, é possível alternar os clientes da origem para os bancos de dados de destino.

  1. No MongoDB Atlas, clique em Clusters.

  2. No painel Cluster0, clique em Preparar-se para realizar a transição. Uma explicação passo a passo do processo de transição e uma string de conexão para o cluster de destino serão exibidas.

  3. Clique em Transferência.

    Quando a migração estiver concluída, a mensagem Migração de cluster realizada com sucesso! será exibida.

Você migrou com sucesso o conjunto de réplicas do MongoDB para um cluster do MongoDB Atlas.

Como preparar uma estratégia de substituição

Depois que uma transição é concluída, o cluster de destino é o sistema de registro. Os bancos de dados de origem estão desatualizados e serão removidos. No entanto, convém recorrer aos bancos de dados de origem em caso de falhas graves nos novos bancos de dados de destino. Por exemplo, uma falha pode ocorrer se a lógica de negócios em um aplicativo não for executada durante o teste e, posteriormente, não funcionar corretamente. Outra falha ocorre quando o comportamento de desempenho ou latência não corresponde aos bancos de dados de origem e causa erros.

Para evitar essas falhas, opte por manter os bancos de dados de origem originais atualizados com as alterações no banco de dados de destino. A migração em tempo real do Atlas não fornece um mecanismo de substituição. Para mais informações sobre estratégias de substituição, consulte Migração de banco de dados: conceitos e princípios (Parte 2).

Limpar

Excluir o projeto do Google Cloud

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto do Google Cloud criado para este tutorial.

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Pausar ou encerrar o cluster do MongoDB Atlas

Para evitar cobranças adicionais para o cluster do MongoDB Atlas, é necessário pausar ou encerrar o cluster. Para mais informações sobre implicações de faturamento, consulte Pausar ou encerrar um cluster.

A seguir