Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/

Sincronização de dados do conjunto de réplica

Nesta página

  • Sincronização inicial
  • Replicação

Para manter cópias atualizadas do conjunto de dados compartilhados, os membros secundários de um conjunto de réplicas sincronizam ou replicam dados de outros membros. O MongoDB usa duas formas de sincronização de dados: sincronização inicial, para preencher novos membros com o conjunto completo de dados, e replicação, para aplicar alterações contínuas a todo o conjunto de dados.

A sincronização inicial copia todos os dados de um membro do conjunto de réplicas para outro membro. Consulte Seleção inicial da fonte de sincronização para obter mais informações sobre os critérios de seleção da fonte de sincronização inicial.

Você pode especificar a fonte de sincronização inicial preferida usando o parâmetro initialSyncSourceReadPreference. Este parâmetro só pode ser especificado ao iniciar o mongod.

Ao executar uma sincronização inicial, o MongoDB:

  1. Clona todos os bancos de dados, exceto o banco de dados local. Para clonar, o mongod verifica cada collection em cada banco de dados de origem e insere todos os dados em suas próprias cópias dessas collections.

    Alterado na versão 3.4: A sincronização inicial cria todos os índices de collection à medida que os documentos são copiados para cada collection. Em versões anteriores do MongoDB, somente os índices _id são construídos durante este estágio.

    Alterado na versão 3.4: A sincronização inicial extrai registros de oplog recém-adicionados durante a cópia de dados. Certifique-se de que o membro de destino tenha espaço em disco suficiente no reconhecimento de data center local para armazenar temporariamente esses registros oplog durante esse estágio da cópia de dados.

  2. Aplica todas as alterações ao conjunto de dados. Utilizando o oplog da origem, o mongod atualiza seu conjunto de dados para refletir o estado atual do conjunto de réplicas.

    Quando a initial sync termina, o membro faz a transição de STARTUP2 para SECONDARY.

Para executar uma initial sync, consulte Sincronizar novamente um membro de um conjunto de réplicas autogerenciado.

Você deve executar uma initial sync em clusters que usam a opção de armazenamento SSD local de memória não livre (NVMe), inclusive se você estiver usando o auto-scaling do Atlas. Os clusters do Atlas NVMe são dimensionados automaticamente para o próximo nível superior quando 90% do espaço de armazenamento estiver cheio. Uma sincronização inicial leva mais tempo para ser concluída em comparação com sincronizações subsequentes e reduz o desempenho do primário do qual os dados são lidos.

Se um secundário executando a initial sync encontrar um erro de rede não transitório (i.e. persistente) durante o processo de sincronização, o secundário reinicia o processo de initial sync desde o início.

Um secundário que esteja executando a sincronização inicial pode tentar retomar o processo de sincronização se for interrompido por um transiente (ou seja, temporário) erro de rede, descarte de coleção ou renomeação de coleção.

Por padrão, o secundário tenta retomar a sincronização inicial por 24 horas. Você pode usar o parâmetro de servidor initialSyncTransientErrorRetryPeriodSeconds para controlar a quantidade de tempo que o secundário tenta retomar a sincronização inicial. Se o secundário não conseguir retomar com sucesso o processo de sincronização inicial durante o período de tempo configurado, ele seleciona uma nova fonte saudável do conjunto de réplicas e reinicia o processo de sincronização inicial do início.

O secundário tentará reiniciar a initial sync até 10 vezes antes de retornar um erro fatal.

A seleção da fonte de sincronização inicial depende do valor do parâmetro de inicialização do mongod initialSyncSourceReadPreference:

  • Para initialSyncSourceReadPreference definido como primary (padrão se chaining estiver desabilitado), selecione o primário como a fonte de sincronização. Se o primário não estiver disponível ou acessível, registre um erro e verifique periodicamente a disponibilidade do primário.

  • Para initialSyncSourceReadPreference definido como primaryPreferred (padrão para membros do conjunto de réplicas com direito a voto), tente selecionar o primário como a fonte de sincronização. Se o primário estiver indisponível ou inacessível, realize a seleção da fonte de sincronização dos membros restantes do conjunto de réplicas.

  • Para todos os outros modos de leitura suportados, realize a seleção de fonte de sincronização a partir dos membros do conjunto de réplicas.

Os membros que realizam a seleção da fonte de initial sync fazem duas passagens pela lista de todos os membros do conjunto de réplicas:

O nó aplica os seguintes critérios a cada nó do conjunto de réplicas ao fazer a primeira passagem para selecionar uma fonte de sincronização inicial:

  • A origem de sincronização deve estar no estado de replicação do PRIMARY ou SECONDARY.

  • A origem de sincronização deve ser online e acessível.

  • Se initialSyncSourceReadPreference for secondary ou secondaryPreferred, a fonte de sincronização deverá ser secundária.

  • A origem de sincronização deve ser visible.

  • A origem de sincronização deve estar dentro de 30 segundos da entrada de oplog mais recente no primário.

  • Se o nó builds indexes, a fonte de sincronização deve construir índices.

  • Se o nó votes nas eleições do conjunto de réplicas, a fonte de sincronização também deverá votar.

  • Se o nó não for um delayed member, a origem da sincronização não deve ser atrasada.

  • Se o nó é um delayed member, a origem de sincronização deve ter um atraso configurado mais curto.

  • A origem de sincronização deve ser mais rápida (ou seja, latência mais baixa) do que a melhor origem de sincronização atual.

Se nenhuma fonte de sincronização de candidatos permanecer após a primeira aprovação, o membro realizará uma segunda aprovação com critérios relaxados. Consulte Sync Source Selection (Second Pass).

O membro aplica os seguintes critérios a cada membro do conjunto de réplicas ao fazer a segunda passagem para selecionar uma fonte de sincronização inicial:

  • A origem de sincronização deve estar no estado de replicação do PRIMARY ou SECONDARY.

  • A origem de sincronização deve ser online e acessível.

  • Se initialSyncSourceReadPreference for secondary, a origem de sincronização deverá ser secundária.

  • Se o nó builds indexes, a fonte de sincronização deve construir índices.

  • A origem de sincronização deve ser mais rápida (ou seja, latência mais baixa) do que a melhor origem de sincronização atual.

Se o membro não puder selecionar uma fonte de initial sync após duas passagens, ele registrará um erro e aguardará 1 segundo antes de reiniciar o processo de seleção. O mongod secundário pode reiniciar o processo de seleção de fonte da initial sync até 10 vezes antes de sair com um erro.

Os membros secundários replicam os dados continuamente após a initial sync. Os membros secundários copiam o oplog de sua fonte de sincronização e aplicam essas operações em um processo assíncrono. [1]

Os secundários podem alterar automaticamente fonte de origem de sincronização, conforme necessário, com base nas alterações no tempo de ping e no estado da replicação de outros membros. Consulte Seleção da fonte de sincronização de replicação para obter mais informações sobre os critérios de seleção da fonte de sincronização.

[1] Os membros secundários de um conjunto de réplicas agora registram entradas de oplog que demoram mais do que o limite de operação lenta para serem aplicadas. Essas mensagens de atraso no oplog:
  • São registradas para os secundários no diagnostic log.
  • São registradas sob o componente REPL com o texto applied op: <oplog entry> took <num>ms.
  • Não dependem dos níveis de registro (seja no nível do sistema ou do componente)
  • Não dependem do nível de perfil.
  • São afetados por slowOpSampleRate.
O perfilador não captura entradas de oplog lentas.

A sincronização a partir de fontes envia um fluxo contínuo de entradas oplog para seus secundários de sincronização. A replicação de streaming reduz o atraso de replicação em redes de alta carga e alta latência. Ela também:

  • Reduz a desatualização das leituras de secundários.

  • Reduz o risco de perda de operações de gravação com w: 1 devido ao failover principal.

  • Reduz a latência nas operações de gravação com w: "majority" e w: > 1 (ou seja, qualquer problema de gravação que exija esperar pela replicação).

Use o parâmetro de inicialização oplogFetcherUsesExhaust para desabilitar a replicação de streaming e usar o comportamento de replicação mais antigo. Defina o parâmetro oplogFetcherUsesExhaust como false somente se houver restrições de recursos na sincronização da fonte ou para limitar o uso de largura de banda de rede do MongoDB para replicação.

O MongoDB aplica operações de gravação em lotes usando vários threads para melhorar a simultaneidade. O MongoDB agrupa lotes por ID de documento (WiredTiger) e aplica simultaneamente cada grupo de operações usando um thread diferente. O MongoDB sempre aplica operações de gravação a um determinado documento em sua ordem de gravação original.

As operações de leitura destinadas a secundários e configuradas com um nível de read concern de "local" ou "majority" lêem a partir de um snapshot de WiredTiger dos dados se a leitura ocorrer em um secundário onde os lotes de replicação estejam sendo aplicados.

A leitura de um snapshot garante uma visão consistente dos dados e permite que a leitura ocorra simultaneamente com a replicação contínua, sem a necessidade de uma trava. Como resultado, as leituras secundárias que exigem esses níveis de read concern não precisam mais esperar pela aplicação dos lotes de replicação e podem ser tratadas à medida que são recebidas.

A partir do MongoDB 4.2, os administradores podem limitar a taxa na qual o primário aplica suas gravações com o objetivo de manter o atraso abaixo de um valor máximo majority committed configurável flowControlTargetLagSeconds.

Por padrão, o controle de fluxo é enabled.

Observação

Para que o controle de fluxo seja ativado, o conjunto de réplicas/cluster fragmentado deve ter: featureCompatibilityVersion (fCV) de 4.2 e preocupação de leitura majority enabled. Ou seja, o controle de fluxo ativado não terá efeito se fCV não for 4.2 ou se a maioria das preocupações de leitura estiver desativada.

Para obter mais informações, consulte Controle de fluxo.

A seleção da fonte de sincronização de replicação depende da configuração chaining do conjunto de réplicas:

  • Com o encadeamento habilitado (padrão), realize a seleção da fonte de sincronização a partir dos membros do conjunto de réplicas.

  • Com o encadeamento desabilitado, selecione o primário como fonte de sincronização. Se o primário não estiver disponível ou acessível, registre um erro e verifique periodicamente a disponibilidade do primário.

Os membros que realizam a seleção da fonte de sincronização de replicação fazem duas passagens pela lista de todos os membros do conjunto de réplicas:

O nó aplica os seguintes critérios a cada nó do conjunto de réplicas ao fazer a primeira passagem para selecionar uma fonte de sincronização de replicação:

  • A origem de sincronização deve estar no estado de replicação do PRIMARY ou SECONDARY.

  • A origem de sincronização deve ser online e acessível.

  • A origem de sincronização deve ter entradas de oplog mais recentes do que o nó (ou seja, a fonte de sincronização está à frente do nó).

  • A origem de sincronização deve ser visible.

  • A origem de sincronização deve estar dentro de 30 segundos da entrada de oplog mais recente no primário.

  • Se o nó builds indexes, a fonte de sincronização deve construir índices.

  • Se o nó votes nas eleições do conjunto de réplicas, a fonte de sincronização também deverá votar.

  • Se o nó não for um delayed member, a origem da sincronização não deve ser atrasada.

  • Se o nó é um delayed member, a origem de sincronização deve ter um atraso configurado mais curto.

  • A origem de sincronização deve ser mais rápida (ou seja, latência mais baixa) do que a melhor origem de sincronização atual.

Se nenhuma fonte de sincronização candidata permanecer após o primeiro passe, o nó fará um segundo passe com critérios mais flexíveis. Veja o Sync Source Selection (Second Pass).

O membro aplica os seguintes critérios a cada membro do conjunto de réplicas ao fazer a segunda passagem para selecionar uma fonte de sincronização de replicação:

  • A origem de sincronização deve estar no estado de replicação do PRIMARY ou SECONDARY.

  • A origem de sincronização deve ser online e acessível.

  • Se o nó builds indexes, a fonte de sincronização deve construir índices.

  • A origem de sincronização deve ser mais rápida (ou seja, latência mais baixa) do que a melhor origem de sincronização atual.

Se o membro não puder selecionar uma fonte de sincronização após duas passagens, ele registrará um erro e aguardará 1 segundo antes de reiniciar o processo de seleção.

O número de vezes que uma fonte pode ser alterada por hora é configurável com a definição do parâmetro maxNumSyncSourceChangesPerHour.

Observação

O parâmetro de inicialização initialSyncSourceReadPreference tem precedência sobre a configuração settings.chainingAllowed do conjunto de réplicas ao selecionar uma fonte de sincronização inicial. Depois que um membro do conjunto de réplicas executa com êxito a sincronização inicial, ele adia o valor de chainingAllowed ao selecionar uma fonte de sincronização de replicação.

Consulte Seleção da fonte da sincronização inicial para obter mais informações relacionadas.

Voltar

Oplog

Próximo

Membros do conjunto de réplicas