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 umconjunto de réplicas do 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 nós do conjunto de réplicas utilizam term e version para obter consenso sobre a configuração de réplica "mais recente". Quando os nós comparam documentos de configuração de réplicas, o documento de configuração com o term maior é considerado o "mais novo". Se term for o mesmo ou estiver ausente, o documento de configuração com o version maior será considerado o "mais novo".

term

Tipo: int

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

Um número de incremento 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 primário do conjunto de réplicas 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 o primário, em seguida, emite 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

O MongoDB suporta apenas protocolVersion: 1 e não suporta mais 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 algum nó votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir `writeConcernMajorityJournalDefault` como `false`. Se qualquer nó votante de um conjunto de réplicas utilizar o mecanismo de armazenamento na memória e o `writeConcernMajorityJournalDefault` for `true`, as operações de gravação do `"majority"` poderão falhar. Isso inclui operações que usam inerentemente a preocupação de gravação `"majority"`, como o comando `replSetStepDown`, ou vários métodos `mongosh` que, por padrão, usam a preocupação de gravação `"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 nó do conjunto de réplicas usar o storage engine na memória (com ou sem votação), mas o conjunto de réplicas tiver `writeConcernMajorityJournalDefault` definido como verdadeiro, o nó do conjunto de réplicas registrará 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 algum nó 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 nó do conjunto de réplicas usar o storage engine na memória (com ou sem votação), mas o conjunto de réplicas tiver `writeConcernMajorityJournalDefault` definido como verdadeiro, o nó do conjunto de réplicas registrará um aviso de inicialização. Você não pode executar transações em um cluster fragmentado que tenha um fragmento com `writeConcernMajorityJournalDefault` definido como `false` (como um fragmento com um nó votante que usa o mecanismo de armazenamento na memória).

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 algum nó votante de um conjunto de réplicas usar o mecanismo de armazenamento na memória, você deverá definir writeConcernMajorityJournalDefault como false.

Se qualquer nó votante de um conjunto de réplicas utilizar o mecanismo de armazenamento na memória e o writeConcernMajorityJournalDefault for true, as operações de gravação do "majority" poderão falhar. Isso inclui operações que usam inerentemente a preocupação de gravação "majority", como o comando replSetStepDown, ou vários métodos mongosh que, por padrão, usam a preocupação de gravação "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 nó do conjunto de réplicas usar o storage engine na memória (com ou sem votação), mas o conjunto de réplicas tiver writeConcernMajorityJournalDefault definido como verdadeiro, o nó do conjunto de réplicas registrará 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 algum nó 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 cluster fragmentado que tenha um fragmento com writeConcernMajorityJournalDefault definido como false (como um fragmento com um nó votante que usa o mecanismo de armazenamento na memória).

Dica

Veja também:

`members`

members

Tipo: array

Uma array de documentos de configuração de nós, um para cada nó 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 nó 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 nó.

Observação

Ao atualizar o objeto de configuração da réplica, acesse os nós do conjunto de réplicas na array members com o índice da array. O índice da array começa com 0. Não confunda esse valor de índice com o valor do campo members[n]._id em cada documento da 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 nós 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 utilizar o método rs.addArb() para adicionar um árbitro, o método define automaticamente members[n].arbiterOnly como true no nó adicionado.

members[n].buildIndexes

Opcional.

Tipo: booleano

Padrão: true

Um booleano que indica se o mongod cria índices nesse nó. Você só pode definir esse valor ao adicionar um nó a um conjunto de réplicas. Não é possível alterar o campo members[n].buildIndexes depois que o nó tiver sido adicionado ao conjunto. Para adicionar um nó, 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 essa instância para executar backups usando mongodumpe
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, o MongoDB retornará um erro ao tentar adicionar um nó 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 nós ocultos podem reconhecer operações de gravação emitidas com a preocupação de gravação. Nas operações de gravação emitidas com a preocupação de gravação "majority", o nó também deve ser um nó votante (p. ex., 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 nós sem direito a voto (ou seja, nós 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.
Nas operações de gravação, você pode criar uma preocupação de gravação personalizada usando 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 nós atrasados podem contribuir para o reconhecimento de operações de gravação emitidas com a preocupação de gravação. No entanto, eles não retornam a confirmação de gravação antes do valor de atraso configurado. Para operações de gravação emitidas com a preocupação de gravação "majority", o nó também deve ser um nó 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.

Nós com priority maior que 0 não podem ter 0 votes.

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

Os nós não votantes (ou seja, votes é 0) devem ter priority ou 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 versões anteriores, 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 nós secundários do conjunto de réplicas podem replicar dados de outros nós 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, você não pode especificar uma preocupação de gravação 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 de leitura ou gravação para um conjunto de réplicas ou cluster fragmentado.

settings.getLastErrorModes

Opcional.

Tipo: document

Um documento usado para definir uma preocupação de gravação personalizada por meio do uso de members[n].tags. A preocupação de gravação personalizada pode fornecer reconhecimento de data center.

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

O <number> se refere ao número de valores de tag diferentes necessários para satisfazer a preocupação de gravação. Por exemplo, o seguinte settings.getLastErrorModes define uma preocupação de gravação denominada datacenter que exige que a gravação se propague para dois nós 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 o primário de um conjunto de réplicas não está acessível. Essa configuração controla a sensibilidade ao failover ao usar protocolVersion: 1. Espera-se 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

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.

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 como -1 desativa a aquisição de catchup. Definir catchUpTimeoutMillis como 0 desativa o catchup do primário e, consequentemente, também o controle do catchup.

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éplicas e criado automaticamente durante rs.initiate() ou replSetInitiate. Você não pode alterar o replicaSetId.

Voltar

Referência de replicação

Versão do protocolo de conjunto de réplica