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

Replicação

Nesta página

  • Redundância e disponibilidade de dados
  • Replicação no MongoDB
  • Replicação assíncrona
  • Failover automático
  • Ler operações
  • Transações
  • Fluxos de alterações
  • Recursos adicionais

Um conjunto de réplicas no MongoDB é conjunto de réplicas de processos mongod que mantém o mesmo conjunto de dados. Os conjuntos de réplica fornecem redundância e alta disponibilidade, e são a base para todas os sistemas de produção. Esta seção apresenta a replicação no MongoDB, bem como os componentes e a arquitetura dos conjuntos de réplicas. A seção também fornece tutoriais para tarefas comuns relacionadas a conjuntos de réplicas.

Você pode definirum conjunto de réplicas na IU para implantações hospedadas no MongoDB Atlas.

A replicação fornece redundância e aumenta a disponibilidade dos dados. Com várias cópias de dados em diferentes servidores de banco de dados, a replicação oferece um nível de tolerância a falhas contra a perda de um único servidor de banco de dados.

Em alguns casos, a replicação pode fornecer maior capacidade de leitura, pois os clientes podem enviar operações de leitura para servidores diferentes. A manutenção de cópias de dados em diferentes data centers pode aumentar a localidade e a disponibilidade dos dados para aplicativos distribuídos. Você também pode manter cópias adicionais para fins dedicados, como recuperação após desastres, relatórios ou backup.

Um conjunto de réplicas é um grupo de instâncias do mongod que mantém o mesmo conjunto de dados. Um conjunto de réplicas contém vários nós portadores de dados e, opcionalmente, um nó de árbitro. Dos nós portadores de dados, um e apenas um membro é considerado o primário, enquanto os outros nós são considerados nós secundários.

Aviso

Cada nó do conjunto de réplicas deve pertencer a um (e apenas um) conjunto de réplicas. Os nós do conjunto de réplicas não podem pertencer a mais de um conjunto de réplicas.

O nó primário recebe todas as operações de gravação. Um conjunto de réplicas pode ter apenas um primário capaz de confirmar gravações com a write concern { w: "majority" }; embora, em algumas circunstâncias, outra instância mongod possa transitoriamente também ser considero primário. [1] O primário registra todas as alterações a seus conjuntos de dados em seu log de operação, ou seja, oplog. Para obter mais informações sobre a operação do primário, consulte Primário do conjunto de réplicas.

Diagrama de roteamento padrão de leituras e gravações no principal.
clique para ampliar

Os secundários replicam o oplog do primário e aplicam as operações aos seus conjuntos de dados de forma que os conjuntos de dados dos secundários reflitam o conjunto de dados do primário. Se um primário não estiver disponível, um secundário elegível realizará uma eleição para se eleger um novo primário. Para obter mais informações sobre membros secundários, consulte Membros secundários do conjunto de réplicas.

Diagrama de um conjunto de réplicas de três membros com um principal e dois secundários.

Em algumas circunstâncias (como quando você tem um primário e um secundário, mas as restrições de custo proíbem a adição de outro secundário), você pode optar por adicionar uma mongod ao conjunto de réplicas como um árbitro. Um árbitro participa nas eleições, mas não detém dados (ou seja, não oferece redundância de dados). Para obter mais informações sobre árbitro, consulte Replica Set Arbiter.

Diagrama de um conjunto de réplicas que consiste em um primário, secundário e árbitro.

Um árbitro sempre será um árbitro, enquanto um primário pode renunciar e se tornar um secundário e um secundário pode se tornar o primário durante uma eleição.

Os secundários replicam o oplog da primária e aplicam as operações aos seus conjuntos de dados de forma assíncrona. Como os conjuntos de dados secundários refletem o conjunto de dados primário, o conjunto de réplicas pode continuar a funcionar apesar do fracasso de um ou mais membros.

Para obter mais informações sobre mecânica de replicação, consulte Replica Set Oplog e Replica Set Data Synchronization.

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.

Atraso de replicação é um atraso entre uma operação no primário e a aplicação dessa operação do oplog para o secundário. Um pequeno período de atraso pode ser aceitável, mas problemas significativos surgem à medida que o atraso de replicação cresce, incluindo a criação de pressão de cache no primário.

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.

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 majority enabled preocupação de leitura . Ou seja, o controle de fluxo ativado não terá efeito se o FCV não for 4.2 ou se a maioria das preocupação de leitura estiver desativada.

Com o controle de fluxo ativado, à medida que o atraso se aproxima do flowControlTargetLagSeconds, as gravações no primário precisam obter tíquetes antes de usar os bloqueios para aplicar as gravações. Ao limitar o número de tíquetes emitidos por segundo, o mecanismo de controle de fluxo tenta manter o atraso abaixo da meta.

Para obter mais informações, consulte Verificar o sinalizador de replicação e o controle de fluxo.

Quando um primário não se comunica com os outros membros do set por mais do que o período electionTimeoutMillis configurado (10 segundos por padrão), um secundário elegível solicita uma eleição para se nomear como o novo primário. O cluster tenta concluir a eleição de um novo primário e retomar as operações normais.

Diagrama de uma eleição de um novo primário. Em um conjunto de réplicas de três membros com dois secundários, o primário se torna inacessível. A perda de uma primária desencadeia uma eleição em que um dos secundários se torna o novo primário.
clique para ampliar

O conjunto de réplicas não pode processar operações de gravação até que a eleição seja concluída com sucesso. O conjunto de réplicas pode continuar servindo read queries se essas queries estiverem configuradas para run on secundários enquanto a primário estiver offline.

O tempo médio antes de um cluster eleger um novo primário normalmente não deve exceder 12 segundos, considerando replica configuration settings padrão. Isso inclui o tempo necessário para marcar o primário como indisponível e convocar e concluir uma eleição. Você pode ajustar esse período modificando a opção de configuração de replicação settings.electionTimeoutMillis. Fatores como a latência da rede podem prolongar o tempo necessário para que as eleições de conjuntos de réplicas sejam concluídas, o que, por sua vez, afeta o tempo em que o cluster pode operar sem um primário. Esses fatores dependem da arquitetura específica de seus clusters.

Reduzir a opção de configuração de replicação do electionTimeoutMillis a partir do padrão 10000 (10 segundos) pode resultar em detecção mais rápida de falha primária. No entanto, o cluster pode convocar eleições com mais frequência devido a fatores como latência temporária da rede, mesmo que o primário esteja saudável. Isso pode resultar em mais rollbacks para operações de gravação w : 1.

A lógica de conexão do seu aplicativo deve incluir tolerância para failovers automáticos e as eleições subsequentes. Os drivers do MongoDB podem detectar a perda do primário e repetir automaticamente determinadas operações de gravação uma única vez, fornecendo tratamento adicional integrado de failovers e eleições automáticas:

Drivers compatíveis permitem gravações repetíveis por padrão

O MongoDB fornece leituras espelhadas para pré-aquecer o cache dos membros secundários elegíveis com os dados acessados mais recentemente. O pré-aquecimento do cache de um secundário pode ajudar a restaurar o desempenho mais rapidamente após uma eleição.

Para saber mais sobre o processo de failover do MongoDB, consulte:

Por padrão, os clientes leem a partir do primário [1]; No entanto, os clientes podem especificar uma preferência de leitura para enviar operações de leitura para secundários.

Diagrama de um aplicativo que usa preferência de leitura secundária.
clique para ampliar

Asynchronous replication para os secundários significa que as leituras dos secundários podem retornar dados que não refletem o estado dos dados no primário.

Transações distribuídas que contêm operações de leitura devem usar a read preference primary. Todas as operações em uma determinada transação devem ser roteadas para o mesmo membro.

Para obter informações sobre como ler a partir de conjuntos de réplica, consulte Preferência de leitura.

Dependendo do read concern, os clientes podem ver os resultados das escritas antes que elas sejam duráveis:

  • Independentemente da write concern, outros clientes que usam a read concern podem ver o resultado de uma operação de gravação antes que a operação de gravação seja reconhecida pelo cliente "local" "available" emissor.

  • Os clientes que usam a read concern "local" ou "available" podem ler dados que podem ser revertidos posteriormente durante failovers de conjuntos de réplicas.

Para operações em uma transação de vários documentos, quando uma transação é confirmada, todas as alterações de dados feitas na transação são salvas e ficam visíveis fora da transação. Ou seja, uma transação não confirmará algumas de suas alterações enquanto reverte outras.

Até que uma transação seja confirmada, as alterações de dados feitas na transação não serão visíveis fora da transação.

No entanto, quando uma transação é gravada em vários fragmentos, nem todas as operações de leitura externas precisam esperar que o resultado da transação confirmada fique visível nos fragmentos. Por exemplo, se uma transação estiver comprometida e escrever 1 estiver visível no fragmento A, mas escrever 2 ainda não estiver visível no fragmento B, uma leitura externa em questão de leitura "local" poderá ler os resultados da escrita 1 sem ver a escrita 2.

Para obter mais informações sobre isolamentos de leitura, consistência e recência para o MongoDB, consulte Isolamento de leitura, consistência e recência.

As leituras espelhadas reduzem o impacto das eleições primárias após uma interrupção ou manutenção planejada. Após um failover em um conjunto de réplicas, o secundário que assume como o novo primário atualiza seu cache à medida que novas queries chegam. Enquanto o cache está aquecendo o desempenho pode ser afetado.

As leituras espelhadas pré-preparam os caches de membros do conjunto de réplicas electable. Para pré-preparar os caches dos secundários elegíveis, o primário espelha uma amostra das operações compatíveis que recebe para os secundários elegíveis.

O tamanho do subconjunto de membros do conjunto de réplica secundária do electable que recebem leituras espelhadas pode ser configurado com o parâmetro mirrorReads. Consulte Ativar/desativar suporte para leituras espelhadas para obter mais detalhes.

Observação

As leituras espelhadas não afetam a resposta da primary para o cliente. A leitura que o primary replica para os secundários são operações do tipo "fire-and-forget". A primary não espera por respostas.

As leituras espelhadas suportam as seguintes operações:

As leituras espelhadas são ativadas por padrão e usam um padrão sampling rate de 0.01. Para desabilitar leituras espelhadas, configure o parâmetro mirrorReads para { samplingRate: 0.0 }:

db.adminCommand( {
setParameter: 1,
mirrorReads: { samplingRate: 0.0 }
} )

Com uma taxa de amostragem maior que o primário 0.0, espelha as leituras suportadas para um subconjunto de electable secundários. Com uma taxa de amostragem de 0.01, o primário espelha um por cento das leituras suportadas que recebe em uma seleção de secundários elegíveis.

Por exemplo, considere um conjunto de réplicas que consiste em uma primário e duas secundárias eletivas. Se o primário receber 1000 operações que podem ser espelhadas e a taxa de amostragem for 0.01, o primário espelha cerca de 10 leituras suportadas para os secundários selecionáveis. Cada secundário elegível recebe apenas uma fração das 10 leituras. O primário envia cada leitura espelhada para uma seleção aleatória e não vazia de secundários eletivos.

Para alterar a taxa de amostragem para leituras espelhadas, configure o parâmetro mirrorReads para um número entre 0.0 e 1.0:

  • Uma taxa de amostragem de 0.0 desabilita leituras espelhadas.

  • Uma taxa de amostragem de um número entre 0.0 e 1.0 resulta no primário de uma amostra aleatória das leituras suportadas à taxa de amostragem especificada para secundários elegíveis.

  • Uma taxa de amostragem de 1.0 faz com que o primário encaminhe todas as leituras suportadas para os secundários selecionáveis.

Para detalhes, consulte mirrorReads.

O comando serverStatus e o método de shell db.serverStatus() retornam métricas mirroredReads se você especificar o campo na operação:

db.serverStatus( { mirroredReads: 1 } )

Transações multidocumento estão disponíveis para conjuntos de réplicas.

Transações distribuídas que contêm operações de leitura devem usar a read preference primary. Todas as operações em uma determinada transação devem ser roteadas para o mesmo membro.

Até que uma transação seja confirmada, as alterações de dados feitas na transação não serão visíveis fora da transação.

No entanto, quando uma transação é gravada em vários fragmentos, nem todas as operações de leitura externas precisam esperar que o resultado da transação confirmada fique visível nos fragmentos. Por exemplo, se uma transação estiver comprometida e escrever 1 estiver visível no fragmento A, mas escrever 2 ainda não estiver visível no fragmento B, uma leitura externa em questão de leitura "local" poderá ler os resultados da escrita 1 sem ver a escrita 2.

Os change streams estão disponíveis para conjuntos de réplicas e clusters fragmentados. Os change streams permitem que os aplicativos acessem alterações de dados em tempo real sem a complexidade e o risco de afetar o oplog. Os aplicativos podem usar change streams para assinar todas as alterações de dados em uma coleção ou coleções.

Os conjuntos de réplicas definem várias opções para atender às necessidades dos aplicativos. Por exemplo, você pode implantar um conjunto de réplicas com membros em vários data centers ou controlar o resultado das eleições ajustando o members[n].priority de alguns membros. Os conjuntos de replica também oferecem suporte a membros dedicados para reporting, recuperação de desastre ou backup.

Consulte Membros do conjunto de réplicas de prioridade 0, Membros do conjunto de réplicas ocultas e Membros do conjunto de réplicas atrasados para obter mais informações.

[1](1, 2) Em some circumstances, dois nós em um conjunto de réplicas podem acreditar transiently que são os primário , mas, no máximo, um deles poderá concluir as gravações com write concern { w: "majority" } . O nó que pode completar { w: "majority" } gravações é o primário atual e o outro nó é um antigo primário que ainda não reconheceu seu rebaixamento, normalmente devido a uma partição de rede. Quando isso ocorre, os clientes que se conectam ao antigo primário podem observar dados obsoletos, apesar de terem solicitado preferência de leitura primary, e novas gravações no antigo primário acabarão sendo revertidas.

Voltar

Referências de banco de dados