Menu Docs
Página inicial do Docs
/
Sincronização de Cluster-to-Cluster do MongoDB

Perguntas frequentes

Nesta página

  • Posso realizar leituras ou gravações em meu cluster de destino enquanto o mongosync estiver sincronizando?
  • O mongosync pode ser executado em seu próprio hardware?
  • Quais especificações de hardware o cluster de destino deve ter?
  • Devo aumentar o tamanho do oplog no cluster de origem?
  • Quais opções de string de conexão o mongosync permite?
  • Quais opções de segurança e autenticação são aceitas?
  • O mongosync reinicia automaticamente em caso de erro?
  • A origem ou o destino pode ser um conjunto de réplicas com árbitros?
  • E se eu ver um Aviso de Operação Lenta?
  • Devo interromper uma migração se os registros contiverem a palavra "erro" ou "falha"?
  • E se eu ver muitos erros de chave duplicados nos registros?
  • O que devo fazer se o mongosync retornar um erro fatal?
  • O mongosync suporta índices TTL?
  • Posso personalizar distribuições de chunks ao sincronizar com um cluster fragmentado?

Esta página fornece respostas para algumas perguntas frequentes que encontramos. Se você tiver outras dúvidas, entre em contato com o Suporte do MongoDB.

Você pode realizar leituras durante a sincronização a qualquer momento. No entanto, os dados que você lê são eventualmente consistentes. Para leituras consistentes, aguarde a confirmação da migração. Para saber mais, consulte Considerações para sincronização contínua.

Se você escrever em um namespace sincronizado antes de emitir um commit e enquanto canWrite estiver false, o comportamento será indefinido. Para garantir que você não escreva em nenhum namespace sincronizado, habilite o bloqueio de escrita.

Observação

As compilações de índice no cluster de destino são tratadas como gravações enquanto mongosync está sincronizando.

Para verificar o valor de canWrite, ligue para o ponto de extremidade da API de progresso .

Sim, o mongosync pode ser executado em seu próprio hardware. mongosync não precisa ser executado nos servidores que hospedam suas instâncias do MongoDB. Quando o mongosync é executado em seu próprio hardware, ele pode usar um sistema operacional (OS) diferente do sistema operacional nos clusters de origem ou destino.

Para a maioria das migrações, o cluster de destino deve ter especificações de hardware mais altas do que o cluster de origem, incluindo as seguintes propriedades:

  • CPU

  • Memória

  • Disk I/O

Estas especificações de hardware garantem que o cluster de destino possa lidar com mongosync gravações e que a sincronização possa acompanhar o volume de trabalho do cluster de origem.

O cluster de destino deve ter armazenamento em disco suficiente para acomodar o tamanho lógico dos dados que estão sendo migrados e as entradas de oplog de destino da sincronização inicial. Por exemplo, para migrar 10 GB de dados, o cluster de destino deve ter pelo menos 10 GB disponíveis para os dados e outro 10 GB para as entradas de oplog de inserção da sincronização inicial.

Para reduzir a sobrecarga das entradas de oplog de destino, você pode:

  • Use a configuração para reduzir o tamanho do oplog do cluster de oplogSizeMB destino.

  • Use a configuração para reduzir ou remover o período mínimo de retenção de oplog do cluster de oplogMinRetentionHours destino.

mongosync aplica operações em oplog no cluster de origem aos dados no cluster de destino. Quando as operações que mongosync não aplicaram rolem do oplog no cluster de origem, a sincronização falha e o mongosync sai.

Observação

mongosync não replica operações applyOps feitas no cluster de origem durante a sincronização com o cluster de destino.

Durante a sincronização inicial, mongosync pode aplicar operações em uma taxa mais lenta devido à cópia de documentos simultaneamente. Após a sincronização inicial, mongosync aplica alterações mais rapidamente e tem maior probabilidade de manter uma posição no oplog próxima às gravações em tempo real que ocorrem no cluster de origem.

Se você antecipar a sincronização de um grande conjunto de dados ou se planeja pausar a sincronização por um longo período de tempo, poderá exceder a oplog window. Use a configuração oplogSizeMB para aumentar o tamanho do oplog no cluster de origem.

mongosync requer readConcern: "maioria" e writeConcern: "maioria".

Se o readConcern não for majority, mongosync retorna um erro:

Invalid URI option, read concern must be majority

Se o writeConcern não for majority, mongosync retorna um erro:

Invalid URI option, write concern must be majority

mongosync aceita todas as outras opções de connection string.

mongosync usa uma connection string padrão do MongoDB para se conectar aos clusters de origem e destino.

LDAP e X509 são suportados. Para obter as opções de autenticação disponíveis, consulte Autenticação em implementações autogerenciadas.

mongosync não reinicia automaticamente em caso de erro. No entanto, você pode escrever um script ou usar os gerenciadores de processos do seu sistema operacional, systemd por exemplo, para reiniciar o processo mongosync .

O binário mongosync não tem estado. Os metadados para reiniciar são armazenados no cluster de destino.

Uma operação mongosync pode ser retomada se mongosync ficar indisponível durante a sincronização. Quando o mongosync estiver disponível novamente, reinicie o processo do mongosync com os mesmos parâmetros. mongosync retoma a operação de onde parou quando mongosync ficou indisponível.

Observação

A partir de mongosync 1.7.3, mongosync pode levar pelo menos dois minutos para responder quando você retoma ou reinicia uma operação de sincronização. Durante esse tempo, qualquer chamada para o endpoint progress pode falhar. Se uma chamada progress falhar, é seguro tentar novamente.

Sim, o conjunto de réplicas pode ter árbitros. O conjunto de réplicas de origem deve ter mais de 2 nós não árbitros e você deve sincronizar a partir de um nó não árbitro. Use a connection string do cluster de origem para especificar uma preferência de leitura para um nó portador de dados não árbitro.

Os avisos de operação lenta podem ocorrer durante a sincronização inicial ou a aplicação de um evento de alteração quando há uma operação de leitura lenta no cluster de origem ou uma operação de gravação lenta no cluster de destino. O aviso pode indicar congestionamento de rede ou sobrecarga de recursos no cluster de origem ou destino.

Embora esses avisos não indiquem falhas em si mesmos, operações lentas podem causar erros de tempo limite de operação em mongosync e falhas de migração.

Se você ver avisos de operação lenta, verifique o uso da CPU, da memória e da rede nos clusters de origem e destino. Se os clusters estiverem subprovisionados para suas necessidades, considere atualizar o hardware do cluster.

Não, os logs que contêm a palavra "erro" ou "falha" mostram erros não fatais e não sinalizam que você precisa parar mongosync mais cedo. Esses logs não indicam que mongosync esteja falhando ou corrompendo os dados. Se ocorrer um erro fatal, mongosync interromperá a sincronização e gravará uma entrada de log fatal.

Erros de chave duplicados são uma parte normal do processo de sincronização. Esses erros podem ocorrer se:

  • Você insere um documento no cluster de origem após o início do mongosync . mongosync pode copiar diretamente o documento e aplicar redundantemente o evento de alteração de inserção para o documento posteriormente.

  • Você para e retoma mongosync. Isso pode levar a inserções duplicadas quando mongosync for reiniciado.

  • mongosync encontra um erro transitório e tenta novamente uma inserção que já pode ter sido bem-sucedida.

Um erro fatal indica um problema que deve ser corrigido e exige que a migração seja reiniciada. Depois de resolver o erro, exclua todos os dados migrados no cluster de destino, incluindo o banco de banco de dados mongosync_reserved_for_internal_use . Em seguida, reinicie o mongosync e inicie uma nova migração.

Cluster-to-Cluster Sync oferece suporte à sincronização de índices TTL do cluster de origem para o cluster de destino.

No, you can't configure mongosync to customize chunk distributions on a destination sharded cluster. mongosync samples each collection during initialization to determine how to distribute documents efficiently across the destination cluster’s shards after migration.

Voltar

0.9