Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB

Configuração do conjunto de réplica

Nesta página

Exemplo de documento de configuração do conjunto de réplica

Campos de configuração do conjunto de réplicas

Você pode acessar a configuração de um conjunto de réplica utilizando o método rs.conf() ou o comando replSetGetConfig.

Para modificar a configuração de um conjunto de réplica, utilize o método rs.reconfig(), passando um documento de configuração para o método. Consulte rs.reconfig() para mais informações.

Aviso

Evite reconfigurar conjuntos de réplicas que contenham membros de diferentes versões do MongoDB, pois as regras de validação podem diferir entre as versões do MongoDB.

Exemplo de documento de configuração do conjunto de réplica

O documento a seguir fornece uma representação de um documento de configuração de conjunto de réplica. A configuração do seu conjunto de réplicas pode incluir somente um subconjunto dessas configurações:

{
  _id: <string>,
  version: <int>,
  term: <int>,
  protocolVersion: <number>,
  writeConcernMajorityJournalDefault: <boolean>,
  configsvr: <boolean>,
  members: [
    {
      _id: <int>,
      host: <string>,
      arbiterOnly: <boolean>,
      buildIndexes: <boolean>,
      hidden: <boolean>,
      priority: <number>,
      tags: <document>,
      secondaryDelaySecs: <int>,
      votes: <number>
    },
    ...
  ],
  settings: {
    chainingAllowed : <boolean>,
    heartbeatIntervalMillis : <int>,
    heartbeatTimeoutSecs: <int>,
    electionTimeoutMillis : <int>,
    catchUpTimeoutMillis : <int>,
    getLastErrorModes : <document>,
    getLastErrorDefaults : <document>,
    replicaSetId: <ObjectId>
  }
}

Campos de configuração do conjunto de réplicas

_id

Tipo: string

O nome do conjunto de réplicas.

_id deve ser idêntico ao replication.replSetName ou ao valor de --replSet especificado para mongod na linha de comando.

Dica

Consulte:

replSetName ou --replSet para informações sobre como configurar o nome do conjunto de réplicas.

version

Tipo: int

Um número incremental usado para distinguir as revisões do documento de configuração do conjunto de réplicas das iterações anteriores da configuração.

Os membros do conjunto de réplica utilizam term e version para obter consenso sobre a configuração de réplica "mais recente". Quando os membros comparam documentos de configuração de réplica, o documento de configuração com um term maior é considerado o "mais novo". Se o term for o mesmo ou ausente, o documento de configuração com o version maior será considerado "mais novo".

term

Tipo: int

Disponível apenas com featureCompatibilityVersion (fCV) "4.4" ou versão posterior.

Um número incremental usado para distinguir as revisões do documento de configuração do conjunto de réplicas das iterações anteriores da configuração. O term de um documento de configuração corresponde ao termo do conjunto de réplica primário que executou a reconfiguração. O primário aumenta seu termo cada vez que avança após vencer uma eleição. O primário ignora o campo term se definido explicitamente na operação replSetReconfig .

A emissão de uma reconfiguração de força remove o campo term . Quando as edições primário primárias replSetReconfig sem força, ela define o term para seu próprio termo.

configsvr

Tipo: booleano

Padrão: false

Indica se o conjunto de réplica é utilizado para servidores de configuração de um cluster fragmentado. Configure para true se o conjunto de réplica for para servidores de configuração do cluster fragmentado.

protocolVersion

Tipo: número

Padrão: 1

A partir da versão 4.0, o MongoDB oferece suporte apenas protocolVersion: 1 e não oferece mais suporte protocolVersion: 0.

Dica

Veja também:

Versão do protocolo de conjunto de réplica

writeConcernMajorityJournalDefault

Tipo: booleano

Padrão: true

Determina o comportamento de { w: "majority" } write concern se a write concern não especificar explicitamente a opção de diário j.

A tabela a seguir lista os valores writeConcernMajorityJournalDefault e o comportamento { w: "majority" } associado:

Valor	`{ w: "majority" }` Comportamento
true	O MongoDB reconhece a operação de gravação após a maioria dos membros votantes ter escrito no diário em disco. Importante Todos os membros votantes do conjunto de réplicas devem ser executados com registro no diário quando `writeConcernMajorityJournalDefault` estiver `true`. Se qualquer membro votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir `writeConcernMajorityJournalDefault` como `false`. Se qualquer membro de votação de um conjunto de réplica utilizar o mecanismo de armazenamento in-memory e o `writeConcernMajorityJournalDefault` for `true`, as operações de gravação do `"majority"` poderão falhar. Isso inclui operações que usam inerentemente a write concern `"majority"` , como o comando `replSetStepDown` , ou vários métodos `mongosh` que, por padrão, usam a write concern `"majority"` , como métodos de gerenciamento de usuários e métodos de gerenciamento de funções. A partir da versão 4.2 (e 4.0.13 e 3.6.14 ), se um membro do conjunto de réplicas utilizar o mecanismo de armazenamento in-memory (votação ou não), mas o conjunto de réplicas tiver `writeConcernMajorityJournalDefault` definido como verdadeiro, o membro do conjunto de réplicas registra um aviso de inicialização.
false	O MongoDB reconhece a operação de gravação depois que a maioria dos membros votantes aplicou a operação na memória. Aviso Se qualquer membro votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir `writeConcernMajorityJournalDefault` como `false`. A partir da versão 4.2 (e 4.0.13 e 3.6.14 ), se um membro do conjunto de réplicas utilizar o mecanismo de armazenamento in-memory (votação ou não), mas o conjunto de réplicas tiver `writeConcernMajorityJournalDefault` definido como verdadeiro, o membro do conjunto de réplicas registra um aviso de inicialização. Você não pode executar transações em um acluster fragmentado que tenha um shard com `writeConcernMajorityJournalDefault` configurado para `false` (como um shard com um nó votante que utilize o mecanismo de armazenamento in-memory).

Valor

{ w: "majority" } Comportamento

true

O MongoDB reconhece a operação de gravação após a maioria dos membros votantes ter escrito no diário em disco.

Importante

Todos os membros votantes do conjunto de réplicas devem ser executados com registro no diário quando writeConcernMajorityJournalDefault estiver true.

Se qualquer membro votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir writeConcernMajorityJournalDefault como false.

Se qualquer membro de votação de um conjunto de réplica utilizar o mecanismo de armazenamento in-memory e o writeConcernMajorityJournalDefault for true, as operações de gravação do "majority" poderão falhar. Isso inclui operações que usam inerentemente a write concern "majority" , como o comando replSetStepDown , ou vários métodos mongosh que, por padrão, usam a write concern "majority" , como métodos de gerenciamento de usuários e métodos de gerenciamento de funções.

A partir da versão 4.2 (e 4.0.13 e 3.6.14 ), se um membro do conjunto de réplicas utilizar o mecanismo de armazenamento in-memory (votação ou não), mas o conjunto de réplicas tiver writeConcernMajorityJournalDefault definido como verdadeiro, o membro do conjunto de réplicas registra um aviso de inicialização.

false

O MongoDB reconhece a operação de gravação depois que a maioria dos membros votantes aplicou a operação na memória.

Aviso

Se qualquer membro votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir writeConcernMajorityJournalDefault como false.

Você não pode executar transações em um acluster fragmentado que tenha um shard com writeConcernMajorityJournalDefault configurado para false (como um shard com um nó votante que utilize o mecanismo de armazenamento in-memory).

Dica

Veja também:

`members`

members

Tipo: array

Uma array de documentos de configuração de membros, um para cada membro do conjunto de réplicas. A array members é uma array indexada a zero.

Cada documento de configuração específico do membro pode conter os seguintes campos:

members[n]._id

Tipo: inteiro

Um identificador inteiro para o membro no conjunto de réplica, único entre todos os membros.

A partir do MongoDB 5.0, os valores podem ser qualquer valor inteiro maior ou igual a 0. Anteriormente, esse valor era limitado a um inteiro entre 0 e 255 inclusive.

Cada membro do conjunto de réplicas deve ter um único _id. Evite reutilizar valores do _id mesmo que nenhuma entrada do members[n] esteja utilizando este _id na configuração atual.

Após configurar, você não poderá alterar o _id de um membro.

Observação

Ao atualizar o objeto de configuração da réplica, acesse os membros do conjunto de réplicas na array members com o índice da array. O índice da array começa com 0. Não confunda este valor de índice com o valor do campo members[n]._id em cada documento na array members .

members[n].host

Tipo: string

O nome do host e, se especificado, o número da porta do membro configurado.

O nome do host deve ser resolvido para cada host no conjunto de réplica.

Aviso

members[n].host não pode conter um valor que produza localhost ou a interface local, a menos que todos os membros do conjunto estejam em hosts que produzam localhost.

members[n].arbiterOnly

Opcional.

Tipo: booleano

Padrão: false

Um booleano que identifica um árbitro. Um valor de true indica que o membro é um árbitro.

Ao rs.addArb() o método para adicionar um árbitro, o método true members[n].arbiterOnly para o membro adicionado.

Para as seguintes versões do MongoDB, o pv1 aumenta a probabilidade de reversões do w:1 em comparação com o pv0 (não mais suportado no MongoDB 4.0+) para conjuntos de réplicas com árbitros:

MongoDB 3.4.1
MongoDB 3.4.0
MongoDB 3.2.11 Ou anterior

Consulte Versão do protocolo de conjunto de réplicas

members[n].buildIndexes

Opcional.

Tipo: booleano

Padrão: true

Um booleano que indica se o mongod cria índices nesse membro. Você só pode definir esse valor ao adicionar um membro a um conjunto de réplicas. Não é possível alterar members[n].buildIndexes campo depois que o membro tiver sido adicionado ao conjunto. Para adicionar um membro, consulte rs.add() e rs.reconfig().

Não configure para false para instâncias do mongod que recebem queries de clientes.

Configurar buildIndexes para false pode ser útil se todas as seguintes condições forem verdadeiras:

você só está usando esta instância para executar backups usando mongodump e
este membro não receberá queries e
a criação e a manutenção de índices sobrecarregam o sistema hospedeiro.

Mesmo se definido como false, os secundários criarão índices no campo _id para facilitar as operações necessárias para replicação.

Aviso

Se você definir members[n].buildIndexes como false, também deverá definir members[n].priority como 0. Se members[n].priority não for 0, MongoDB retornará um erro ao tentar adicionar um membro com members[n].buildIndexes igual a false.

Para garantir que o membro não receba nenhuma query, você deve criar todas as instâncias que não construam índices ocultos.

Outros segundários não podem replicar de um membro onde members[n].buildIndexes é falso.

members[n].hidden

Opcional.

Tipo: booleano

Padrão: false

Quando este valor é true, o conjunto de réplica oculta esta instância e não inclui o membro na saída de db.hello() ou hello. Isso evita operações de leitura (ou seja, queries) de chegar a esse host por meio de preferência de leiturasecundária.

Os membros ocultos podem reconhecer operações de gravação emitidas com o Write Concern. Para operações de gravação emitidas com "majority" write concern, o membro também deve ser um membro votante (ou seja, votes é maior que 0).

Dica

Veja também:

Membros ocultos do conjunto de réplicas

members[n].priority

Opcional.

Tipo: Número entre 0 e 1000 para primário/secundário; 0 ou 1 para árbitros.

Padrão: 1.0 para primário/secundário; 0 para árbitros.

Um número que indica a probabilidade relativa de um membro do conjunto de réplicas se tornar o primário.

Para aumentar a probabilidade de um membro se tornar o principal, especifique um valor priority maior para este membro.
Para diminuir a probabilidade de um membro se tornar o primário, especifique um valor menor de priority para esse membro.

Alterar a prioridade de um membro aciona uma ou mais eleições. O algoritmo de eleição faz o melhor esforço possível para eleger o membro de maior prioridade como primário. No entanto, um membro de prioridade mais baixa pode se tornar o primário mesmo que um secundário de prioridade mais alta esteja disponível.

Se um membro de menor prioridade se tornar o primário, o servidor continuará convocando eleições periodicamente até que o membro do conjunto de réplicas de maior prioridade seja o primário. A frequência com que as eleições ocorrem depende da diferença de prioridade entre o membro eleito e o membro de maior prioridade.

Um membro com prioridade de 0 não pode se tornar o principal.

Os membros sem direito a voto (ou seja, membros que têm votes definido como 0) devem ter uma prioridade de 0.

Dica

Veja também:

members[n].tags

Opcional.

Tipo: document

Padrão: nenhum

Um documento tags contém um campo de tag definido pelo usuário e pares de valores para o membro do conjunto de réplica.

{ "<tag1>": "<string1>", "<tag2>": "<string2>",... }

Para operações de leitura, você pode especificar um conjunto de tags na preferência de leitura para direcionar as operações para membros do conjunto de réplicas com as tags especificadas.
Para operações de gravação, você pode criar uma write concern personalizada utilizando settings.getLastErrorModes e settings.getLastErrorDefaults.

Para obter mais informações, consulte Configurar conjuntos de tags de conjunto de réplica.

members[n].secondaryDelaySecs

Opcional.

Tipo: inteiro

Padrão: 0

O número de segundos "atrás" do primário que esse membro do set deve "atrasar".

Use esta opção para criar membros atrasados. Membros atrasados mantêm uma cópia dos dados que reflete o estado dos dados em algum momento no passado.

Os membros atrasados podem contribuir para o reconhecimento de operações de gravação emitidas com o Write Concern. No entanto, eles retornam a confirmação de gravação não antes do valor de atraso configurado. Para operações de gravação emitidas com "majority" write concern, o membro também deve ser um membro votante (ou seja, votes é maior que 0).

Dica

Veja também:

Membros atrasados do conjunto de réplicas

members[n].votes

Opcional.

Tipo: inteiro

Padrão: 1

O número de votos que um servidor lançará em uma eleição de conjunto de réplica. O número de votos que cada membro tem é 1 ou 0, e árbitros sempre têm exatamente 1 voto.

Membros com priority maior que 0 não podem ter 0 votes.

Um conjunto de réplicas pode ter até 50 membros, mas apenas 7 membros votantes. Se você precisar de mais de 7 membros em um conjunto de réplicas, defina members[n].votes como 0 para os membros adicionais sem direito a voto.

Os membros sem direito a voto (ou seja, votes é 0) devem ter priority de 0.

A partir do MongoDB 5.0, um secundário recém-adicionado não conta como um membro votante e não pode ser eleito até que tenha atingido o estado SECONDARY.

Membros sem direito a voto não podem reconhecer as operações de gravação emitidas com a write concern "majority".

Dica

Veja também:

`settings`

settings

Opcional.

Tipo: document

Um documento que contém opções de configuração que se aplicam a todo o conjunto de réplicas.

O documento settings contém os seguintes campos:

settings.chainingAllowed

Opcional.

Tipo: booleano

Padrão: true

No MongoDB 5.0.1 e anterior, se settings.chainingAllowed for:

true, os membros secundários do conjunto de réplica podem replicar dados de outros membros secundários.
false, os membros secundários podem replicar os dados somente do principal.

A partir do MongoDB 5.0.2:

Os membros secundários do conjunto de réplicas podem replicar dados de outros membros secundários , mesmo que settings.chainingAllowed seja false.
Para substituir settings.chainingAllowed, defina o parâmetro do servidor enableOverrideClusterChainingSetting como true.
O padrão para enableOverrideClusterChainingSetting é false.

Dica

Veja também:

Gerenciar replicação encadeada

settings.getLastErrorDefaults

Opcional.

Tipo: document

Indisponível a partir do MongoDB 5.0.

Importante

A partir do MongoDB 5.0, não é possível especificar uma write concern padrão com settings.getLastErrorDefaults diferente do padrão { w: 1, wtimeout: 0 } . Em vez disso, use o comando setDefaultRWConcern para definir a configuração padrão de preocupação com leitura ou gravação para um conjunto de réplicas ou cluster fragmentado.

settings.getLastErrorModes

Opcional.

Tipo: document

Um documento usado para definir uma write concern personalizada por meio do uso de members[n].tags. A write concern personalizada pode fornecer conscientização do centro de dados.

{ getLastErrorModes: {
   <name of write concern> : { <tag1>: <number>, .... },
   ...
} }

O <number> se refere ao número de valores de tag diferentes necessários para satisfazer o write concern. Por exemplo, o seguinte settings.getLastErrorModes define uma write concern denominada datacenter que exige que a gravação propague para dois membros cujos valores de tag dc diferem.

{ getLastErrorModes: { datacenter: { "dc": 2 } } }

Para usar a write concern personalizada, passe o nome da write concern para a opçãow , por exemplo.

{ w: "datacenter" }

Consulte Configurar conjuntos de tags de conjunto de réplica para obter mais informações e exemplos.

settings.heartbeatTimeoutSecs

Opcional.

Tipo: int

Padrão: 10

Número de segundos que os membros do conjunto de réplica esperam por uma pulsação bem-sucedida uns dos outros. Se um membro não responder a tempo, outros membros marcarão o membro delinquente como inacessível.

settings.electionTimeoutMillis

Opcional.

Tipo: int

Padrão: 10000 (10 segundos)

O limite de tempo em milésimos de segundo para detectar quando um conjunto de réplica principal não está acessível. Essa configuração controla a sensibilidade ao failover ao usar protocolVersion: 1. Você pode esperar que o tempo limite de failover não exceda o valor de electionTimeoutMillis.

Considere o seguinte ao selecionar um valor:

Valores mais altos resultam em failovers mais lentos, mas diminuem a sensibilidade à lentidão ou irregularidade do nó primário ou da rede.
Valores mais baixos resultam em failover mais rápido, mas maior sensibilidade ao nó primário ou à lentidão ou à fragmentação da rede.

A configuração só se aplica ao usar protocolVersion: 1.

Observação

Quando você desiste de uma primário usando rs.stepDown() ou replSetStepDown sem definir o campo force como true, a primário reduzida indica um secundário elegível para convocar uma eleição imediatamente.

settings.catchUpTimeoutMillis

Opcional.

Tipo: int

Alterado na versão 3.6:

Padrão: -1, tempo de recuperação infinito.

Limite de tempo, em milésimos de segundo, para que um primário recém-eleito sincronize (recupere o atraso) com os outros membros do conjunto de réplicas que podem ter gravações mais recentes. Limites de tempo infinitos ou altos podem reduzir a quantidade de dados que os outros membros precisariam reverter após uma eleição, mas podem aumentar o tempo de failover.

A primário recém-eleita termina o período de recuperação mais cedo, uma vez que é totalmente alcançada com outros membros do conjunto. Durante o período de recuperação, um primário recém-eleito não está disponível para escritas de clientes. Use replSetAbortPrimaryCatchUp para abortar a recuperação e, em seguida, concluir a transição para a primária.

A configuração só se aplica ao usar protocolVersion: 1.

Observação

Para fazer downgrade de um conjunto de réplicas iniciado na versão 3.6 para 3.4, altere catchUpTimeoutMillis de -1 para um número positivo. Se esse valor não for alterado para um número positivo, os nós que estiverem executando a versão 3.4 não reiniciarão nem se juntarão ao conjunto de réplicas.

settings.catchUpTakeoverDelayMillis

Opcional.

Tipo: int

Padrão: 30000 (30 segundos)

Tempo, em milésimos de segundo, que um nó aguarda para iniciar uma catchup takeover após determinar que está à frente do primário atual. Durante um catchup takeover, o nó à frente do primário atual inicia uma eleição para se tornar o novo primário do conjunto de réplicas.

Depois que o nó que inicia a aquisição determina que está à frente do primário atual, ele espera o número especificado de milésimos de segundo e, em seguida, verifica o seguinte:

Ainda está à frente do current primário,
É o nó mais atualizado entre todos os nós disponíveis,
O primário atual está alcançando isso.

Depois de determinar que todas essas condições foram atendidas, o nodo que inicia a aquisição imediatamente concorre às eleições.

Para obter mais informações sobre as Eleições do Conjunto de Réplica, consulte Eleições do Conjunto de Réplica.

Observação

A definição de catchUpTakeoverDelayMillis para -1 desativa a aquisição de catchup. Setting catchUpTimeoutMillis para 0 desativa a primário catchup e, consequentemente, também catchup takeover.

settings.heartbeatIntervalMillis

Somente para uso interno.

A frequência em milésimos de segundo das batidas cardíacas.

settings.replicaSetId

Tipo: ObjectId

O ObjectId associado ao conjunto de réplica e criado automaticamente durante rs.initiate() ou replSetInitiate. Você não pode alterar o replicaSetId.

← Referência de replicação

Versão do protocolo de conjunto de réplica →