O binário mongosync é o processo primário usado no Mongosync. mongosync migra dados de um cluster para outro.
Para uma visão geral do processo mongosync, consulte Sobre mongosync.
Para começar a utilizar o mongosync, consulte o Guia de Início Rápido.
Para obter informações mais detalhadas, consulte a página Instalação ou Conexão mongosync que melhor se adequa à sua situação.
Isenção de responsabilidade do verificador incorporado
A partir de 1.9, mongosync inclui um verificador incorporado para realizar uma série de verificações em todas as collections suportadas no cluster de destino para confirmar que foi bem-sucedido na transferência de documentos do cluster de origem para o de destino.
Quando você inicia o processo de mongosync, ele fornece o seguinte termo de responsabilidade:
Embedded verification is enabled by default. Verification checks for data consistency between the source and destination clusters. Verification will cause mongosync to fail if any inconsistencies are detected, but it does not check for all possible data inconsistencies. Please see the documentation at https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/current/reference/verification/embedded for more details. Verification requires approximately 0.5 GB of memory per 1 million documents on the source cluster and will fail if insufficient memory is available. Accepting this disclaimer indicates that you understand the limitations and memory requirements for this tool. To skip this disclaimer prompt, use –-acceptDisclaimer. To disable the embedded verifier, specify 'verification: false' when starting mongosync. Please see https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/current/reference/verification/ for alternative verification methods. Do you want to continue? (y/n):
Se você já leu e aceitou o aviso de exclusão, você pode iniciar mongosync com a opção para ignorar esta --acceptDisclaimer notificação.
Configurações
Independência do Cluster
mongosync sincroniza dados de coleta entre um cluster de origem e um cluster de destino. mongosync não sincroniza usuários ou funções. Como resultado, você pode criar usuários com permissões de acesso diferentes em cada cluster.
Arquivo de configuração
As opções para mongosync podem ser definidas em um arquivo de configuração YAML. Use a opção --config . Por exemplo:
mongosync --config /etc/mongosync.conf
Para obter informações sobre as configurações disponíveis, consulte Configuração.
Tipos de cluster e coleção
Clusters fragmentados
O Mongosync suporta replicação entre clusters fragmentados. mongosync replica shards individuais em paralelo do cluster de origem para o cluster de destino. No entanto, o mongosync não preserva a configuração de fragmentação do cluster de origem.
Importante
You must always disable the balancer on a sharded destination cluster by using balancerStop. After stopping the balancer, wait fifteen minutes before starting mongosync. This gives the cluster time to finish any in-progress chunk migrations.
Se o cluster de origem ou destino for um cluster fragmentado e você não estiver executando mongosync o com filtragem de namespace, será necessário desabilitar o balanceador do cluster de origem executando o balancerStop comando e aguardando 15 minutos para que o comando seja concluído.
Se o cluster de origem ou destino for um cluster fragmentado e você estiver executando mongosync com filtragem de namespace , poderá habilitar globalmente o balanceador do cluster de origem, mas deverá desativá-lo para todas as collections dentro do filtro de namespace . Consulte Desativar o Balanceador para Coleções na Sincronização Filtrada. Você também pode desabilitar totalmente o balanceador do cluster de origem.
During migration, do not run the moveChunk or moveRange commands. If you have enabled the source cluster's balancer, but disabled it for collections within the namespace filter, do not run shardCollection on collections within the namespace filter. If you run shardCollection on collections within the namespace filter during the migration, mongosync returns an error and stops, which requires you to start the migration from scratch.
Desativação automática do balanceador
A partir da versão 1.17, mongosync desativa o balanceador nos clusters de origem e destino durante a inicialização se detectar que os balancers não estão desabilitados.
Isso se aplica somente durante a inicialização. Se mongosync detectar que algum dos balanceador está ativado após o início da migração, mongosync falhará.
Depois de desativar o balanceador, mongosync aguarda 15 minutos para garantir que as migrações de chunk em andamento sejam concluídas antes de continuar com a migração.
Se a migração não for reversível e mongosync desabilitar o balanceador de origem ou destino durante a inicialização, após um commit bem-sucedido mongosync reativará o(s) balanceador(s) que ele(s) desativou. Se a migração for reversível, mongosync não reativará nenhum balancer para evitar que os usuários esperem 15 minutos.
IMPORTANT: If mongosync disables the balancer for either cluster and then fails before commit, you must re-enable the balancer(s) manually by using the balancerStart database command if you do not plan to run mongosync again.
Desativando o balanceador para coleções na sincronização filtrada
Se você estiver utilizando um filtro de namespace e quiser habilitar o balanceador do cluster de origem para collections fora do filtro de namespace, siga estas instruções antes de iniciar o mongosync.
Habilite o balanceador para o cluster de origem.
Before starting mongosync with a namespace filter, enable the balancer for the source cluster by running the sh.startBalancer() method in mongosh.
Desative o balanceador para cada collection.
Disable the balancer for each collection within the namespace filter by running the setAllowMigrations command:
db.adminCommand( { setAllowMigrations: “<db>.<collection>”, allowMigrations: false } )
Execute o comando anterior para cada coleção dentro do filtro de namespace .
Importante
Se você habilitar o balanceador do cluster de origem, mas não usar um filtro de namespace , ou se não desabilitar o balanceador para todas as collections dentro do filtro de namespace , mongosync falhará.
Parte pré-divisão
Quando o mongosync sincroniza com um cluster de destino fragmentado, ele pré-divide os blocos para coleções fragmentadas no cluster de destino. Para cada collection fragmentada, mongosync tenta criar 90 chunks.
Distribuição de chunks
Importante
Even if the source cluster is balanced, mongosync doesn't ensure balance of the destination cluster. Because mongosync doesn't support the execution of sharding operations during migration, you must wait until it is safe to accept writes to rebalance the destination cluster. See Sharded Cluster Balancer for guidance on how to rebalance the cluster and sharded cluster limitations for information on sharded cluster limitations in mongosync.
mongosync não preserva a distribuição de chunks da origem para o destino, mesmo com várias instâncias mongosync. Não é possível reproduzir uma pré-divisão específica de blocos de um cluster de origem no cluster de destino.
A única configuração de fragmentação que o mongosync preserva do cluster de origem para o cluster de destino é a chave de fragmentação. Quando a migração for concluída, você poderá ativar o balanceador do cluster de destino que distribui documentos independentemente da distribuição do cluster de origem.
Primary shards
Quando você sincroniza com um cluster de destino fragmentado, o mongosync atribui um fragmento primário para cada banco de dados de dados por meio de um round-robin.
Aviso
Running movePrimary on the source or destination cluster during migration may result in a fatal error or require you to restart the migration from the start. For more information, see Sharded Clusters.
Cluster de Fragmentos de Configuração
A partir de 8.0, O MongoDB introduz suporte para clusters de shards de configuração, também conhecidos como clusters de servidor de configuração incorporados.
mongosync suporta sincronização de clusters fragmentados de servidor de configuração dedicado para clusters fragmentados de servidor de configuração incorporado e vice-versa. Além disso, o mongosync suporta sincronização de conjuntos de réplica para configuração de clusters fragmentados, mas não vice-versa.
Para saber mais sobre servidores de configuração incorporados, consulte Config Shard.
Vários clusters
Para sincronizar um cluster de origem com vários clusters de destino, use uma instância mongosync para cada cluster de destino. Para obter mais informações, consulte Limitações de clusters múltiplos.
Capped collections
A partir de 1.3.0, O Mongosync suporta capped collections com algumas limitações.
convertToCappedis not supported. If you runconvertToCapped,mongosyncexits with an error.cloneCollectionAsCappednão é suportado.
As coleções limitadas no cluster de origem funcionam normalmente durante a sincronização.
As coleções limitadas no cluster de destino apresentam alterações temporárias durante a sincronização:
Não há nenhum número máximo de documentos.
O tamanho máximo da coleção é 1PB.
mongosync restaura os valores originais para o número máximo de documentos e o tamanho máximo do documento durante o commit.
Leituras e escritas
Bloqueio de gravação
Por padrão, o mongosync habilita o bloqueio de gravação somente de destino no cluster de destino. mongosync desbloqueia gravações imediatamente antes do endpoint /progress relatar canWrite que true está. Você pode ativar explicitamente o bloqueio de gravação somente de destino usando o endpoint /start para enableUserWriteBlocking definir "destinationOnly" como.
Você pode ativar o bloqueio duplo de gravação. Se você habilitar o bloqueio duplo de gravação, mongosync bloqueará as gravações:
No cluster de destino durante a migração.
mongosyncdesbloqueia gravações imediatamente antes de definircanWritecomotrueNo cluster de origem, depois de chamar
/commit
Para ativar o bloqueio duplo de gravação, use /start para enableUserWriteBlocking definir "sourceAndDestination" como.
Você pode usar /start enableUserWriteBlocking para definir "none" como.
Você não pode ativar o bloqueio duplo de gravação ou desativar o bloqueio de gravação após o início da sincronização.
Se você quiser usar a sincronização reversa posteriormente, deverá ativar o bloqueio duplo de gravação ao mongosync iniciar.
Permissões de usuário
Para enableUserWriteBlocking definir, o mongosync usuário deve ter uma função que inclua os ActionTypes setUserWriteBlockMode bypassWriteBlockingMode e.
Observação
Ao enableUserWriteBlocking usar, as gravações são bloqueadas apenas para usuários que não possuem o ActionType . Os usuários que possuem esse ActionType podem realizar bypassWriteBlockingMode gravações.
Leituras permitidas
As operações de leitura no cluster de origem são sempre permitidas.
Quando os relatórios de endpoint /progress canWrite são true, os dados nos clusters de origem e destino são consistentes.
Gravações permitidas
Para ver em que estado mongosync está, chame o endpoint da API /progress. A saída /progress inclui um valor booleano, canWrite.
Quando
canWriteétrue, é seguro escrever no cluster de destino.Quando
canWriteforfalse, não escreva no cluster de destino.
Você pode gravar com segurança no cluster de origem enquanto mongosync estiver sincronizando. Não grave no cluster de destino a menos que canWrite seja true.
Preocupação de leitura e gravação
By default, mongosync sets the read concern level to "majority" for reads on the source cluster. For writes on the destination cluster, mongosync sets the write concern level to "majority" with j: true.
Para obter mais informações sobre a configuração e o comportamento da read concern e gravação, consulte read concern e write concern.
readPreference
mongosync requires the primary read preference when connecting to the source and destination clusters. For more information, see Read Preference Options.
Tratamento de índice legado
mongosync reescreve valores de índice legado , como 0 ou uma string vazia, para 1 no destino. mongosync também remove todas as opções de índice inválidas no destino.
Considerações durante a sincronização
mongosync replication is different from replication of data within a Replica Set. mongosync combines and reorders writes from the source to destination cluster during the sync, and also temporarily modifies various collection characteristics.
Como resultado, não é garantido que o destino corresponda ao cluster de origem em nenhum ponto enquanto a sincronização ainda estiver em execução, mesmo quando a sincronização estiver pausada. Para garantir que os clusters de destino e de origem correspondam antes de transferir, chame o endpoint de confirmação.
O relacionamento entre o cluster de origem e o destino termina após a confirmação, a menos que você use a funcionalidade inversa. Para obter informações sobre restrições de sincronização, consulte Limitações para limitações.
Importante
Até que você tenha chamado commit em mongosync e canWrite retorne true com êxito, as coleções migradas no cluster de destino não poderão ser usadas para aceitar tráfego de leitura ou gravação do aplicativo. Não use mongosync para manter clusters secundários para recuperação de desastre, análise ou outros casos de uso semelhantes.
Alterações temporárias nas características da coleção
mongosync altera temporariamente as seguintes características da coleção durante a sincronização. Os valores originais são restaurados durante o processo de confirmação.
Mudar | Descrição |
|---|---|
Unique Indexes | Os índices únicos no cluster de origem são sincronizados como índices não exclusivos no cluster de destino. |
TTL Indexes | A sincronização define |
Hidden Indexes | A sincronização replica índices ocultos como não ocultos. |
Bloqueio de gravação | Se você habilitar o bloqueio duplo de gravação,
To learn more, see Write Blocking. |
Capped collections | A sincronização define capped collections para o tamanho máximo permitido. |
Índices fictícios | Em alguns casos, a sincronização pode criar índices fictícios no destino para dar suporte a gravações em coleções fragmentadas ou coletadas. |
Construção contínua de índices
mongosync não oferece suporte a compilações de índice contínuo durante a migração. Para evitar a criação de índices de forma contínua durante a migração, use um dos métodos a seguir para garantir que seus índices de destino correspondam aos índices de origem:
Construa o índice na origem antes da migração.
Construa o índice na origem durante a migração com uma construção de índice padrão.
Construa o índice no destino após a migração.
mongosync Metadata
mongosync armazena seus metadados em um banco de dados ou vários bancos de dados durante a migração. Os bancos de dados de metadados podem ser nomeados como qualquer um dos seguintes:
mongosync_reserved_for_internal_useQualquer coisa que comece com
mongosync_internal_Qualquer coisa que comece com
mongosync_reserved_for_verification_
Você deve descartar todos os bancos de dados de metadados após uma migração bem-sucedida. Após descartar metadados, não é possível reverter a migração.
Clusters de Destino
Consistência
mongosync oferece suporte à consistência eventual no cluster de destino. A consistência de leitura não é garantida no cluster de destino até a confirmação. Antes de confirmar, os clusters de origem e destino podem ser diferentes em um determinado ponto . Para saber mais, consulte Considerações durante a sincronização.
Enquanto mongosync estiver sincronizando, mongosync pode reordenar ou combinar gravações à medida que as transmite da origem para o destino. Para um determinado documento, o número total de gravações pode ser diferente entre a origem e o destino.
As transações podem não aparecer atomicamente no cluster de destino. As retryable Writes podem não ser repetíveis no cluster de destino.
Criação de perfil
Se o perfil estiver habilitado em um banco de dados de origem, o MongoDB criará uma coleção especial denominada <db>.system.profile. Depois que a sincronização for concluída, o Mongosync não eliminará a coleção <db>.system.profile do destino, mesmo que o banco de dados de origem seja eliminado posteriormente. A coleção <db>.system.profile não alterará a precisão dos dados do usuário no destino.
Visualizações
Se um banco de dados com visualizações for descartado na origem, o destino poderá mostrar uma coleção system.views vazia nesse banco de dados. A coleção vazia system.views não alterará a precisão dos dados do usuário no destino.
Coleções do sistema
O Mongosync não replica coleções de sistemas para o cluster de destino.
If you issue a dropDatabase command on the source cluster, this change is not directly applied on the destination cluster. Instead, Mongosync drops user collections and views in the database on the destination cluster, but it does not drop system collections on that database.
Por exemplo, no cluster de destino:
The drop operation does not affect a user-created
system.jscollection.If you enable profiling, the
system.profilecollection remains.If you create views on the source cluster and then drop the database, replicating the drop removes the views, but leaves an empty
system.viewscollection.
Nesses casos, a replicação do dropDatabase remove todas as coleções criadas pelo usuário do banco de dados, mas deixa suas coleções do sistema no cluster de destino.
UUIDs
mongosync creates collections with new UUIDs on the destination cluster. There is no relationship between UUIDs on the source cluster and the destination cluster. If applications contain hard-coded UUIDs (which MongoDB does not recommend), you may need to update those applications before they work properly with the migrated cluster.
Classificação
mongosync insere documentos no cluster de destino em uma ordem indefinida que não preserva a ordem de classificação natural do cluster de origem. Se os aplicativos dependerem da ordem dos documentos, mas não tiverem um método de classificação definido, talvez seja necessário atualizar esses aplicativos para especificar a ordem de classificação esperada antes que os aplicativos funcionem corretamente com o cluster migrado.
Bancos de dados internos do MongoDB Atlas
O MongoDB Atlas e outros serviços de nuvem armazenam dados essenciais em bancos de dados internos dedicados dentro de seu cluster. Esses bancos de dados começam __mdb_internal com. A partir 1 de.,18 mongosync ignora todos os bancos de dados que começam __mdb_internal com.
Desempenho
Resiliência
mongosync é resiliente e consegue lidar com erros não fatais. Os logs que contêm a palavra "erro" ou "falha" não indicam que mongosync está falhando ou corrompendo os dados. Por exemplo, se ocorrer um erro de rede, o log mongosync poderá conter a palavra "erro", mas
mongosync ainda poderá concluir a sincronização. Caso uma sincronização não seja concluída, mongosync grava uma entrada de log fatal.
Operações em Linguagem de definição de dados (Data Definition Language ou DDL em inglês)
Using DDL operations (operations that act on collections or databases such as db.createCollection() and db.dropDatabase()) during sync increase the risk of migration failure and may negatively impact mongosync performance. For best performance, refrain from performing DDL operations on the source cluster while the sync is in progress.
Para obter mais informações sobre operações DDL, consulte Operações e transações DDL pendentes.
Latência de rede
Latência de rede ou longas distâncias físicas entre componentes de migração podem afetar negativamente a velocidade de sincronização.
- Latência entre
mongosynce os shards de destino - Para cada operação no cluster de origem, o
mongosyncfaz duas viagens de ida e volta até o servidor de destino. Quanto maior a latência, mais lenta a sincronização. - Latência entre shards de destino
mongosyncexecuta operações e atualiza seus próprios metadados em lotes em uma transação no cluster de destino. Isso pode resultar em transações entre fragmentos, que podem ser mais dispendiosas se os fragmentos estiverem distantes.- Latência entre os nós de qualquer conjunto de réplicas no cluster de origem ou destino
mongosyncuses"majority"writes and"majority"reads, which require acknowledgement from multiple nodes in a replica set, including shard-backing replica sets. If the majority of these nodes aren't in the same region, there will be negative performance implications.
Interrupções durante a sincronização
As considerações a seguir referem-se a interrupções durante o processo mongosync.
Erros e falhas
Se mongosync encontrar um erro ou ficar indisponível durante a sincronização, você poderá retomar sua operação mongosync de onde ela parou. O binário mongosync não tem estado e armazena os metadados para uma reinicialização no cluster de destino.
Para continuar a sincronização, reinicie o mongosync assim que ele ficar disponível novamente e use os mesmos parâmetros da sincronização interrompida. Depois de reiniciar mongosync, o processo é retomado de onde parou.
Disponibilidade do cluster
Se seu cluster de origem ou destino falhar inesperadamente, você poderá reiniciar com segurança mongosync de onde ele parou. Quando seu cluster estiver disponível novamente, reinicie o mongosync e use os mesmos parâmetros que a sincronização interrompida.
Sincronização pausada
Se mongosync o estiver no estado PAUSED, mongosync o não suporta as seguintes ações:
Atualizar a versão MongoDB do cluster de origem ou destino
Habilitando e desabilitando o balanceador
Você pode atualizar mongosync enquanto ele estiver no estado PAUSED.