Explore Developer Center's New Chatbot! MongoDB AI Chatbot can be accessed at the top of your navigation to answer all your MongoDB questions.

Introducing MongoDB 8.0, the fastest MongoDB ever!
MongoDB Developer
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
Atlaschevron-right

Soluções de sincronização eficientes: Cluster-to-Cluster Sync e migração em produção para o Atlas

Fabio Ramohitaj5 min read • Published May 10, 2024 • Updated May 10, 2024
Atlas
Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Os desafios que surgem nos contextos empresariais modernos são cada vez mais complexos. Esses desafios vão desde a capacidade de minimizar o tempo de inatividade durante as migrações até a implantação de ferramentas eficientes para a transição de relational database para não relacionais, e da implementação de arquiteturas resilientes que garantem alta disponibilidade até a capacidade de dimensionamento horizontal, permitindo que grandes quantidades de dados sejam gerenciadas com eficiência e consultado.
Dois dos principais desafios, que serão abordados neste artigo, são:
  • A necessidade de criar infraestruturas de TI resilientes que possam garantir a continuidade dos negócios ou o mínimo de tempo de inatividade, mesmo em situações críticas, como a perda de um data center.
  • Realizar migrações de uma infraestrutura para outra sem comprometer as operações.
É nesse contexto que o MongoDB se destaca por oferecer soluções Inovadoras, como o MongoSync e a migração live.

Garantindo a continuidade dos negócios com o MongoSync: uma abordagem para recuperação de desastres

O MongoDB Atlas, com seus recursos e flexibilidade notável, oferece duas abordagens distintas para implementar estratégias de continuação de negócios. Essas duas estratégias são:
  • Criar um cluster com uma distribuição geográfica de nós.
  • A implementação de dois clusters em regiões diferentes sincronizadas via MongoSync.
Nesta seção, exploraremos o segundo ponto (ou seja, a implementação de dois clusters em regiões diferentes sincronizadas via MongoSync) em mais detalhes.
O que exatamente é o MongoSync? Para uma definição correta, podemos consultar a documentação oficial:
"O mongosync binário é o processo primário usado no Cluster-to-Cluster Sync. mongosync migra dados de um cluster para outro e pode manter os clusters em sincronização contínua."
Esta ferramenta realiza as seguintes operações:
  • Ele migra dados de um cluster para outro.
  • Ele mantém os clusters em sincronização contínua.
Vamos tornar isso mais concreto com um exemplo:
  • Inicialmente, a situação parece com esta para o cluster de produção e o cluster de recuperação de desastres:
Imagem de dois clusters: o primeiro já preenchido com dados, enquanto o segundo está vazio e esperando para ser preenchido. Os dois clusters estão localizados em datacenters diferentes
O estado atual do cluster principal ficaria assim:
1Atlas atlas-qsd40w-shard-0 [primary] test> show dbs
2admin               140.00 KiB
3config              276.00 KiB
4local               524.00 KiB
5sample_airbnb        52.09 MiB
6sample_analytics      9.44 MiB
7sample_geospatial     1.02 MiB
8sample_guides        40.00 KiB
9sample_mflix        109.01 MiB
10sample_restaurants    5.73 MiB
11sample_supplies     976.00 KiB
12sample_training      41.20 MiB
13sample_weatherdata    2.39 MiB
O backup usado para a recuperação após desastres ainda está em branco:
1Atlas atlas-lcu71y-shard-0 [primary] test> show dbs
2admin   172.00 KiB
3config  212.00 KiB
4local   584.00 KiB
Antes de prosseguir, é essencial instalar o binário mongosync . Se ainda não o tiver feito, você pode baixá-lo napágina de downloads. Os comandos descritos abaixo foram testados no sistema operacional CentOS 7 .
Vamos prosseguir com a configuração de mongosync definindo um arquivo de configuração e um serviço:
1vi /etc/mongosync.conf
Você pode copiar e colar a configuração atual neste arquivo utilizando as cadeias de conexão apropriadas. Você também pode testar com dois Atlas clusters, que devem ser de nível M10 ou superior. Para obter mais detalhes sobre como obter as cadeias de conexão do seu cluster Atlas, você pode consultar a documentação.
1cluster0: "mongodb+srv://test_u:test_p@cluster0.*****.mongodb.net/?retryWrites=true&w=majority"
2cluster1: "mongodb+srv://test_u:test_p@cluster1.*****.mongodb.net/?retryWrites=true&w=majority"
3logPath: "/data/log/mongosync"
4verbosity: "INFO"
Geralmente, esta etapa é executada em uma máquina Linux por administradores de sistema. Embora a etapa seja opcional, é recomendável implementá-la em um ambiente de produção.
Em seguida, você poderá criar um serviço chamado mongosync.service.
1vi /usr/lib/systemd/system/mongosync.service
É assim que seu arquivo de serviço deve ser parecido.
1 [Unit]
2Description=Cluster-to-Cluster Sync
3Documentation=https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/
4[Service]
5User=root
6Group=root
7ExecStart=/usr/local/bin/mongosync --config /etc/mongosync.conf
8[Install]
9WantedBy=multi-user.target
Recarregue todos os arquivos de unidade:
1systemctl daemon-reload
Agora, podemos iniciar o serviço: 
1systemctl start mongosync
Também podemos verificar se o serviço foi iniciado corretamente:
1systemctl status mongosync
Saída:
1mongosync.service - Cluster-to-Cluster Sync
2    Loaded: loaded (/usr/lib/systemd/system/mongosync.service; disabled; vendor preset: disabled)
3Active: active (running) since dom 2024-04-14 21:45:45 CEST; 4s ago
4 Docs: https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/
5Main PID: 1573 (mongosync)
6    CGroup: /system.slice/mongosync.service
7 └─1573 /usr/local/bin/mongosync --config /etc/mongosync.conf
8
9apr 14 21:45:45 mongosync.mongodb.int systemd[1]: Started Cluster-to-Cluster Sync.
Se um serviço não for criado e executado, de uma forma mais geral, você poderá iniciar o processo da seguinte maneira: mongosync --config mongosync.conf
Depois de iniciar o serviço, verifique se ele está no estado ocioso:
1curl localhost:27182/api/v1/progress -XGET | jq
Saída:
1  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2                                  Dload  Upload   Total   Spent    Left  Speed
3100 191 100 191 0 0 14384 0 --:--:-- --:--:-- --:--:-- 14692
4{
5 "progress": {
6 "state": "IDLE",
7 "canCommit": false,
8 "canWrite": false,
9 "info": null,
10 "lagTimeSeconds": null,
11 "collectionCopy": null,
12 "directionMapping": null,
13 "mongosyncID": "coordinator",
14 "coordinatorID": ""
15  }
16}
Podemos executar a sincronização:
1curl localhost:27182/api/v1/start -XPOST \
2--data '
3    {
4 "source": "cluster0",
5 "destination": "cluster1",
6 "reversible": true,
7 "enableUserWriteBlocking": true
8    } '
Saída:
1{"success":true}
Também podemos acompanhar o status da sincronização:
1curl localhost:27182/api/v1/progress -XGET | jq
Saída:
1  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2                                  Dload  Upload   Total   Spent    Left  Speed
3100 502 100 502 0 0 36001 0 --:--:-- --:--:-- --:--:-- 38615
4{
5 "progress": {
6 "state": "RUNNING",
7 "canCommit": false,
8 "canWrite": false,
9 "info": "collection copy",
10 "lagTimeSeconds": 54,
11 "collectionCopy": {
12 "estimatedTotalBytes": 390696597,
13 "estimatedCopiedBytes": 390696597
14    },
15 "directionMapping": {
16 "Source": "cluster0: cluster0.*****.mongodb.net",
17 "Destination": "cluster1: cluster1.*****.mongodb.net"
18    },
19 "mongosyncID": "coordinator",
20 "coordinatorID": "coordinator"
21  }
22}
23
24  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
25                                  Dload  Upload   Total   Spent    Left  Speed
26100 510 100 510 0 0 44270 0 --:--:-- --:--:-- --:--:-- 46363
27{
28 "progress": {
29 "state": "RUNNING",
30 "canCommit": true,
31 "canWrite": false,
32 "info": "change event application",
33 "lagTimeSeconds": 64,
34 "collectionCopy": {
35 "estimatedTotalBytes": 390696597,
36 "estimatedCopiedBytes": 390696597
37    },
38 "directionMapping": {
39 "Source": "cluster0: cluster0.*****.mongodb.net",
40 "Destination": "cluster1: cluster1.*****.mongodb.net"
41    },
42 "mongosyncID": "coordinator",
43 "coordinatorID": "coordinator"
44  }
45}
Neste momento, o ambiente de DR está alinhado com o ambiente de produção e também manterá a sincronização para as próximas operações: 
Imagem de dois clusters localizados em datacenters diferentes, alinhados e mantidos sincronizados via mongosync. O Mongosync é executado em um servidor local.
1Atlas atlas-qsd40w-shard-0 [primary] test> show dbs
2admin               140.00 KiB
3config              276.00 KiB
4local               524.00 KiB
5sample_airbnb        52.09 MiB
6sample_analytics      9.44 MiB
7sample_geospatial     1.02 MiB
8sample_guides        40.00 KiB
9sample_mflix        109.01 MiB
10sample_restaurants    5.73 MiB
11sample_supplies     976.00 KiB
12sample_training      41.20 MiB
13sample_weatherdata    2.39 MiB
E nosso segundo cluster agora está sincronizado com os seguintes dados.
1Atlas atlas-lcu71y-shard-0 [primary] test> show dbs
2admin                                172.00 KiB
3config                               380.00 KiB
4local                                427.22 MiB
5mongosync_reserved_for_internal_use  420.00 KiB
6sample_airbnb                         53.06 MiB
7sample_analytics                       9.55 MiB
8sample_geospatial                      1.40 MiB
9sample_guides                         40.00 KiB
10sample_mflix                         128.38 MiB
11sample_restaurants                     6.47 MiB
12sample_supplies                        1.03 MiB
13sample_training                       47.21 MiB
14sample_weatherdata                     2.61 MiB
Com base no que discutimos até agora, poderíamos fazer uma última pergunta como:
É possível aproveitar o ambiente de recuperação de desastres de alguma forma ou devemos apenas deixá-lo sincronizar?
Ao fazer as configuraçõesmongosyncapropriadas --- por exemplo, definindo a opção "buildIndexes" como falso e omitindo o parâmetro "enableUserWriteBlocking" (que é definido como false por padrão) -- podemos aproveitar a limitação em relação não sincronização de usuários e funções para criar usuários somente leitura. Fazemos isso de forma que nenhuma entrada possa ser inserida, garantindo assim consistência entre os clusters de origem e destino e nos permitindo usar o ambiente de recuperação de desastres para criar os índices apropriados que entrarão na otimização de queries lentas identificadas no ambiente de produção.

Migração ao vivo para o Atlas: minimizando o tempo de inatividade

A migração live é uma ferramenta que permite aos usuários realizar migrações para o MongoDB Atlas e, mais especificamente, conforme mencionado pela documentação oficial, é um processo que usa mongosync como ferramenta de migração de dados subjacente, permitindo migrações live mais rápidas com menos tempo de inatividade se ambas as os clusters de origem e destino estão executando o MongoDB 6.0.8 ou posterior.
Então, qual é o valor agregado desta ferramenta em comparação com mongosync?
Ele traz duas vantagens:
  • É possível evitar a necessidade de provisionar e configurar um servidor para hospedar mongosync.
  • Você pode migrar de versões anteriores, conforme indicado no caminho de migração.
Imagem representando a migração de um cluster de produção local para o MongoDB Atlas.

Conclusão

Como vimos, essas ferramentas, com os devidos cuidados, nos permitem atingir nossos objetivos e, ao mesmo tempo, nos proporcionam uma certa flexibilidade. 
Independentemente da solução que será usada para migração e/ou sincronização, você poderá entrar em contato com o suporte do MongoDB, que o ajudará a identificar a melhor estratégia para resolver essa tarefa com sucesso.
Se você tiver dúvidas ou comentários, pode nos encontrar na Comunidade de Desenvolvedores do MongoDB!
Principais comentários nos fóruns
Avatar do Comentarista do Fórum
usmaan_rangrezUsmaan Rangrez2 months ago

Quando o DC estiver completamente inativo,
Se eu escrever em DR,
como esses dados serão sincronizados com o DC?
Eu tinha o mongosync instalado em DC.

Veja mais nos fóruns

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Relacionado
Artigo

Análise de queries – Parte 1: conheça suas queries


Jan 05, 2024 | 6 min read
Artigo

Audio Find - Atlas Vector Search para áudio


Sep 09, 2024 | 11 min read
Tutorial

Descubra seu Airbnb ideal: implementando um Spring Boot e Atlas Search com o driver Kotlin Sync


Oct 02, 2024 | 8 min read
Início rápido

Construindo pipelines RAG com haystack e MongoDB Atlas


Sep 18, 2024 | 4 min read
Sumário