Este documento descreve como implantar a arquitetura em Usar a migração em tempo real do Atlas para migrar o MongoDB para o MongoDB Atlas.
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.
Arquitetura
O diagrama a seguir mostra a arquitetura de implantação criada neste documento:
No diagrama, 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. Para mais informações sobre a arquitetura, consulte Usar a migração em tempo real do Atlas para migrar o MongoDB para o 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.
Custos
A implantação dessa arquitetura usa os seguintes componentes faturáveis do Google Cloud:
Para implantar essa arquitetura, 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 e revise as informações de preços do Google Cloud. Se você implementar essa migração na produção, recomendamos que use a versão hospedada regular do MongoDB Atlas.
Ao concluir a implantação, exclua os recursos criados para evitar a continuidade do faturamento. Para mais informações, consulte Limpeza.
Antes de começar
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
Verifique se a cobrança está ativada para o seu projeto do Google Cloud. Saiba como verificar se o faturamento está ativado em um projeto.
Criar um conjunto autogerenciado de réplicas do MongoDB
Para iniciar a implantação, 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. Essa verificação ajuda você a se preparar para a migração em um ambiente de produção. Mesmo que uma réplica do MongoDB já exista no seu ambiente de produção, ainda será necessário verificar as condições prévias.
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
No Google Cloud Marketplace, acesse a instalação do conjunto de réplicas do MongoDB no Compute Engine.
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.
Aceite todas as configurações padrão.
Clique em Implantar.
No Console do Google Cloud, ative 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.
Use uma conexão SSH para fazer login na instância do Compute Engine que executa a instância principal do MongoDB:
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 MongoDBPROJECT_ID
: o nome do seu 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 senha longa, anote-a para referência futura.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.
Inicie o shell
mongo
:mongo
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 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. O conjunto de réplicas do MongoDB de origem instalado como parte desta implantação está em conformidade com a versão necessária, mas ainda é necessário verificar as condições prévias em um ambiente de produção. As verificações de condição prévia estão descritas na documentação do Atlas.
Para verificar se todas as condições prévias foram atendidas, faça o seguinte:
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 shellmongo
, 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.
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.
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 ors.status()
. O comando anterior especifica esse papel.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.
(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
comofalse
antes de iniciar o procedimento de migração em tempo real do Atlas.
Depois de verificar as condições prévias e fazer as alterações necessárias, você concluirá as configurações e reiniciará o banco de dados, que será descrito na próxima seção.
Ativar a autenticação e reiniciar o conjunto de réplicas do MongoDB
Para ativar a autenticação, crie um arquivo de chave e um administrador. Em um ambiente de produção, é possível usar scripts para automatizar o processo.
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
.
Ative a autorização para cada uma das três VMs:
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 emNAME_OF_THE_VM
.
Use uma conexão SSH para fazer login na VM e altere o proprietário e as permissões de acesso do arquivo de chave:
sudo chown mongodb:mongodb PATH_TO_KEY_FILE sudo chmod 400 PATH_TO_KEY_FILE
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 comandosudo
para iniciar o editor de texto.Edite a seção
security
do arquivomongod.conf
:security: authorization: enabled keyFile: PATH_TO_KEY_FILE
Reiniciar a réplica:
sudo service mongod restart
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:
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.
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.
Criar um banco de dados:
use migration
Criar uma coleção:
db.createCollection("source")
Verificar se a coleção está vazia:
db.source.count()
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 })
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.
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.
No Cloud Marketplace, acesse a página MongoDB Atlas: instalação de nível gratuito.
Clique em Acessar o site do MongoDB para se inscrever.
Clique em Iniciar seu primeiro cluster.
Preencha as informações necessárias e clique em Primeiros passos gratuitos. Observe as informações que você forneceu.
Clique em Opções de configuração avançadas.
Em Provedor e região do Cloud, selecione Google Cloud Platform e Iowa (us-central1).
Clique na guia Nível do cluster e selecione M10.
Clique na guia Outras configurações, selecione MongoDB 4.0 ou MongoDB 4.2 e desative o backup.
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.
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.
Iniciar a migração em tempo real
Para migrar os dados da origem para o banco de dados de destino, faça o seguinte:
Faça login no MongoDB Atlas.
Acesse a página Clusters e selecione o cluster para o qual você quer migrar.
No painel do cluster de destino (
Cluster 0
), clique em .Selecione Migrar dados para este cluster.
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 no seguinte 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
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
.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
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
.
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.
Clique em Validar e, em seguida, siga um destes procedimentos:
- Se a validação for bem-sucedida, clique em Iniciar migração.
- Se a validação falhar, 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 da validação. 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.
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:
No MongoDB Atlas, clique em Clusters.
Clique em Coleções.
Verifique se um banco de dados denominado
migrations
existe e se a coleção denominadasource
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:
No Cloud Shell, use uma conexão SSH para fazer login na VM principal do conjunto de réplicas do MongoDB de origem.
Iniciar o shell
mongo
:mongo
Inserir outro documento:
use migration db.source.insert({"document_number": 6})
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 a migração em tempo real do Atlas migrou automaticamente todos os dados originais da origem e as alterações contínuas para a origem.
Testar o cluster de destino do Atlas
Em um ambiente de produção, é importante 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 das estratégias anteriores for viável, teste 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. Para evitar inconsistências de dados ou dados supérfluos no banco de dados de destino, os dados de teste precisam ser removidos após a conclusão dos testes.
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.
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.
No MongoDB Atlas, clique em Clusters.
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.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.
Preparar uma estratégia substituta
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 pode ocorrer 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).
Limpeza
As seções a seguir explicam como evitar cobranças futuras pelo projeto do Google Cloud e pelos recursos do MongoDB usados nessa implantação.
Excluir o projeto do Google Cloud
Para evitar cobranças na sua conta do Google Cloud pelos recursos usados nessa implantação, exclua o projeto do Google Cloud.
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- 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
- Confira o conteúdo de migração de dados do Google Cloud.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.