Um conjunto de réplicas no MongoDB é um grupo de mongod processos do 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 e os componentes e 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.
Redundância e disponibilidade de dados
A replicação fornece redundância e disponibilidade de dados, mantendo várias cópias de dados entre servidores de banco de dados para tolerar a perda de qualquer servidor único.
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 { w: "majority" } preocupação de gravação, 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 em seus conjuntos de dados em seu registro de operações, ou seja, o 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 selecionar um novo primário. Para obter mais informações sobre membros secundários, consulte Membros secundários do conjunto de réplicas.
Se as restrições de custo impedirem a adição de outro secundário, você poderá adicionar uma instância a mongod um conjunto de réplicas como árbitro. Um árbitro participa de eleições, mas não mantém os dados (ou seja, não fornece redundância de dados). Para obter mais informações sobre árbitro, consulte Replica Set Arbiter.
Um árbitro é sempre 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
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
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 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.
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.
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 10 de configurado ( segundos por padrão), um secundário elegível solicita uma eleição para se nomear como o novo primário.
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:
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.
As transações que contêm operações de leitura devem usar a preferência de leitura primary. Todas as operações em uma determinada transação devem ser roteadas para o mesmo nó.
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 ao pré-aquecer os caches dos electable membros secundários do conjunto de réplicas antes que ocorra um failover. O primary 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 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 um primário e dois secundários elegíveis. 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 uma seleção aleatória de secundários elegíveis.
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.0faz com que o primário encaminhe todas as leituras suportadas para os secundários selecionáveis.
Para detalhes, consulte mirrorReads.
Métricas de leituras espelhadas
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
A partir do MongoDB 4.0, estão disponíveis transações de vários documentos para conjuntos de réplica.
As transações que contêm operações de leitura devem usar a preferência de leitura primary. Todas as operações em uma determinada transação devem ser roteadas para o mesmo nó.
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. |