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

Processo de sincronização inicial lógica

Ao executar uma initial sync lógica, o MongoDB:

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

2. Constrói todos os índices das collections conforme os documentos são copiados para cada collection.

3. 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 banco de banco de dados local para armazenar temporariamente esses registros oplog durante esse estágio da cópia de dados.

4. Aplica todas as alterações ao conjunto de dados. Usando o oplog do membro de 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 realizar uma sincronização inicial, consulte Ressincronizar um membro de um conjunto de réplicas autogerenciado.

Initial sync baseada em cópia de arquivos

Disponível apenas no MongoDB Enterprise.

A sincronização inicial baseada em cópia de arquivos executa o processo de sincronização inicial copiando e movendo arquivos no sistema de arquivos. Esse método de sincronização pode ser mais rápido do que a sincronização inicial.

Sincronização inicial em clusters NVMe

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

Tolerância a falhas

Se um membro de destino que executa a sincronização inicial encontrar um erro de rede persistente durante o processo de sincronização, o membro de destino reiniciará o processo de sincronização inicial desde o início.

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

Por padrão, o membro de destino tenta retomar a sincronização inicial por 24 horas. Você pode usar o parâmetro de servidor initialSyncTransientErrorRetryPeriodSeconds para controlar a quantidade de tempo em que o membro de destino tenta retomar a sincronização inicial. Se o membro de destino não puder retomar com êxito o processo de sincronização inicial durante o período de tempo configurado, ele selecionará um novo membro de origem íntegro do conjunto de réplicas e reiniciará o processo de sincronização inicial desde o início.

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

Seleção inicial da fonte de sincronização

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 chainingAllowed estiver desabilitado), selecione o primário como o membro de origem. 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 o membro de origem. Se o primário estiver indisponível ou inacessível, realize a seleção do membro de origem da sincronização dos membros restantes do conjunto de réplicas.

• Para todos os outros modos de leitura compatíveis, execute a seleção do nó de origem sincronizado a partir dos nós de destino.

Os membros que realizam a seleção inicial do membro de origem fazem duas passagens pela lista de todos os membros do conjunto de réplicas:

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

Oplog window

A oplog window deve ser longa o suficiente para que um membro de destino possa buscar quaisquer novas entradas do oplog que ocorram entre o início e o fim do Processo de initial sync lógica. Se a janela não for longa o suficiente, há o risco de que algumas entradas caiam do oplog antes que o membro de destino possa aplicá-las.

É recomendável dimensionar oplog para obter mais tempo para buscar novas entradas de oplog . Isso permite alterações que podem ocorrer durante as sincronizações iniciais.

Para obter mais informações, consulte Tamanho do oplog.

Replicação de streaming

Os membros de origem enviam um fluxo contínuo de entradas de oplog para seus membros de destino. A replicação de streaming atenua o atraso de replicação em redes de alta carga e alta latência. Isso 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 alguma restrição de recursos no membro de origem ou se você desejar limitar o uso da largura de banda da rede pelo MongoDB para replicação.

Replicação multithread

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.

Controle de fluxo

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

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

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

Seleção da fonte de sincronização de replicação

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

• Com o encadeamento habilitado (padrão), realize a seleção do membro de origem a partir dos membros de destino.

• Com o encadeamento desabilitado, selecione o principal como nó de origem. 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 do membro de origem da replicação fazem duas passagens pela lista de todos os membros do conjunto de réplicas:

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 um membro de origem pode ser alterado por hora é configurável com a definição do parâmetro maxNumSyncSourceChangesPerHour .