Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Replicação
Nesta página
Um conjunto de réplicas no MongoDB é um grupo de processos do mongod que mantém o mesmo conjunto de dados. Os conjuntos de réplicas oferecem redundância e alta disponibilidade e são a base para todos os sistemas de produção. Esta seção introduz 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 implementar um conjunto de réplicas na UI para sistemas hospedados no MongoDB Atlas.
Redundância e disponibilidade de dados
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.
Replicação no MongoDB
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.
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.
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.
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.
Replicação assíncrona
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.
Operações lentas
A partir da versão 4.2, membros secundários de um conjunto de réplicas podem extrapolar o limite de tempo para registrar entradas de oplog a serem aplicadas. Essas mensagens de atraso no oplog:
São registradas para os secundários no
diagnostic log.São registradas sob o componente
REPLcom o textoapplied 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 e controle de fluxo
Atraso de replicação é um atraso entre uma operação no primary 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.
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.
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.
Failover automático
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.
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, assumindo o padrão replica
configuration settings. Isso inclui o tempo necessário para marcar o primary como indisponível , chamar 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 primary. 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 de 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:
Ler operações
readPreference
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.
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.
Visibilidade de dados
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.
Leituras espelhadas
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é-aquecem os caches dos membros secundários do conjunto de réplicas electable . Para pré-aquecer os caches dos secundários elegíveis, o primário espelha uma amostra das operações suportadas 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.
Operações suportadas
As leituras espelhadas suportam as seguintes operações:
findAndModify(Especificamente, o filtro é enviado como uma leitura espelhada)update(Especificamente, o filtro é enviado como uma leitura espelhada)
Ativar/Desativar suporte para Leituras Espelhadas
As leituras espelhadas são habilitadas por padrão e usam um padrão sampling rate de 0.01. Para desabilitar leituras espelhadas, defina o parâmetro mirrorReads para {
samplingRate: 0.0 }:
db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.0 } } )
Com uma taxa de amostragem maior que 0.0, o primário 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.
Alterar a taxa de amostragem para leituras espelhadas
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.0desabilita leituras espelhadas.Uma taxa de amostragem de um número entre
0.0e1.0resulta 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.0resulta no primário que encaminha todas as leituras suportadas para os secundários elegíveis.
Para detalhes, consulte mirrorReads.
Métricas de leituras espelhadas
O comando serverStatus e o método de shell db.serverStatus() retornam mirroredReads métricas se você especificar o campo na operação:
db.serverStatus( { mirroredReads: 1 } )
Transações
A partir do MongoDB 4.0, estão disponíveis transações de vários documentos para conjuntos de réplica.
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.
Fluxos de alterações
A partir do MongoDB 3.6, alterar fluxos estão disponíveis para conjuntos de réplica e clusters fragmentados. Os fluxos de alterações 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.
Recursos adicionais
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. |