mongosync Comportamento

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.

Clusters fragmentados

O Mongosync suporta replicação entre clusters fragmentados. Um único sistema do mongosync copia os dados de origem como partições, independentemente de qual fragmento armazena os dados. Em um sistema multi-mongosync, você executa uma instância mongosync para cada shard de origem. As instâncias replicam seus respectivos shards em paralelo durante a fase de aplicação do evento de alteração. No entanto, mongosync não preserva a configuração de fragmentação do cluster de origem.

db.adminCommand(
  { 
    setAllowMigrations: “<db>.<collection>”,
    allowMigrations: false
  }
)

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.

A partir de 1.20.0, você deve passar o sinalizador --enableCappedCollectionHandling ao iniciar o mongosync para permitir a criação de novas coleções limitadas durante uma migração.

• convertToCapped is not supported. If you run convertToCapped, mongosync exits with an error.

• cloneCollectionAsCapped nã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.

Bloqueio de gravação

mongosync gerencia o bloqueio de gravação nos clusters de origem e destino internamente com base em sua configuração de migração:

mongosync bloqueia gravações de origem depois de chamar /commit. As gravações de origem permanecem bloqueadas, a menos que a migração falhe com um erro gerenciado. Se o mongosync for encerrado inesperadamente durante a confirmação, você poderá desbloquear as gravações no cluster de origem manualmente, executando o seguinte comando:

db.adminCommand(
   {
      setUserWriteBlockMode: 1,
      global: false
   }
)

Para mais informações, consulte setUserWriteBlockMode.

mongosync bloqueia as gravações de destino depois de chamar /start. As gravações de destino permanecem bloqueadas até que canWrite esteja true na resposta /progress.

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.

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.

Construção contínua de índices

mongosync does not support rolling index builds during migration. To avoid building indexes in a rolling fashion during migration, use one of the following methods to ensure that your destination indexes match your source indexes:

• 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:

• __mdb_internal_mongosync

• Qualquer coisa que comece com __mdb_internal_mongosync_verifier

Descarte todos os bancos de dados de metadados após uma migração bem-sucedida.

Consistência

mongosync supports eventual consistency on the destination cluster. Read consistency is not guaranteed on the destination cluster until commit. Before committing, the source and destination clusters may differ at a given point in time. To learn more, see Mid-sync Considerations.

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.js collection.

• If you enable profiling, the system.profile collection 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.views collection.

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 cria coleções com novos UUIDs no cluster de destino. Não há relacionamento entre os UUIDs no cluster de origem e no cluster de destino. Se os aplicativos contiverem UUIDs embutidos em código (o que o MongoDB não recomenda), talvez seja necessário atualizar esses aplicativos antes que eles funcionem corretamente com o cluster migrado.

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

MongoDB Atlas and other cloud services store essential data in dedicated internal databases within your cluster. These databases start with __mdb_internal. Starting in 1.18, mongosync ignores all databases that start with __mdb_internal.

Otimizações de Construção de Índice

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.

For more information on DDL operations, see Pending DDL Operations and Transactions.

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 mongosync e os shards de destino

Para cada operação de gravação no cluster de origem, mongosync faz uma viagem de ida e volta ao servidor de destino. mongosync também faz solicitações de suporte para cada lote de operações de gravação replicadas. Quanto maior a latência, mais lenta será a sincronização.

Latência entre shards de destino

mongosync executa 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

mongosync uses "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.

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 o cluster de origem ou de destino falhar inesperadamente, você poderá recuperar a migração sem reiniciar do início. Depois que o cluster voltar a ficar online, reinicie o binário mongosync usando os mesmos parâmetros de string de conexão da migração original. mongosync lê seu estado armazenado do cluster de destino e retoma automaticamente a sincronização.

Para verificar se a sincronização foi retomada, chame o ponto de extremidade /progress e confirme se state retorna RUNNING.

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.