Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

rs.reconfig() (método mongosh)

rs.reconfig( configuration, { options } )

Reconfigura um conjunto de réplica existente, substituindo a configuração do conjunto de réplica existente. Para executar o método, você deve conectar-se ao primário do replica set.

Importante

Método mongosh

This page documents a mongosh method. This is not the documentation for database commands or language-specific drivers, such as Node.js.

Para o comando do banco de dados, consulte o comando replSetReconfig.

Para drivers de API do MongoDB, consulte a documentação do driver do MongoDB específica da linguagem.

The rs.reconfig() method has the following syntax:

rs.reconfig(
<configuration>,
{
"force" : <boolean>,
"maxTimeMS" : <int>
}
)
Parâmetro
Tipo
Descrição

documento

Um documento que especifica a configuração de um conjunto de réplicas.

booleano

Opcional

Especifique true para forçar os membros do conjunto de réplica disponíveis a aceitar a nova configuração. O padrão é false.

A reconfiguração forçada pode resultar em comportamento inesperado, incluindo a reversão de "majority" gravações confirmadas.

inteiro

Opcional

Specifies a cumulative time limit in milliseconds for processing the rs.reconfig() operation. By default, rs.reconfig() waits indefinitely for the replica configuration to propagate to a majority of replica set members.

To reconfigure an existing replica set, first retrieve the current configuration with rs.conf(), modify the configuration document as needed, and then pass the modified document to rs.reconfig().

O parâmetro force permite que um comando de reconfiguração seja emitido para um nó não primário.

Esse método está disponível em implantações hospedadas nos seguintes ambientes:

  • MongoDB Enterprise: a versão autogerenciada e baseada em assinatura do MongoDB

  • MongoDB Community: uma versão com código disponível, de uso gratuito e autogerenciada do MongoDB

Você deve definir explicitamente o padrão global write concern antes de tentar reconfigurar um conjunto de réplicas com uma configuração que alteraria o write concern padrão implícito. Para definir a write concern padrão global, utilize o comando setDefaultRWConcern.

The term field is set by the primary replica set member. The primary ignores the term field if set explicitly in the rs.reconfig() operation.

rs.reconfig() by default allows adding or removing no more than 1 voting member at a time. For example, a new configuration can make at most one of the following changes to the cluster membership:

  • Adicionando um novo membro do conjunto de réplica de votação.

  • Removendo um membro do conjunto de réplica de votação existente.

  • Modificando o votes para um membro do conjunto de réplica existente.

To add or remove multiple voting members, issue a series of rs.reconfig() operations to add or remove one member at a time.

Issuing a force reconfiguration immediately installs the new configuration even if it adds or removes multiple voting members. Force reconfiguration can cause unexpected behavior, such as the rollback of "majority" committed write operations.

rs.reconfig() waits until a majority of voting replica set members install the new replica configuration before returning success. A voting member is any replica set member where members[n].votes is 1, including arbiters.

Os membros do conjunto de réplicas propagam sua configuração de réplica por meio de pulsações. Sempre que um membro descobre uma configuração com umversion e termsuperiores, ele instala a nova configuração. O processo de reconfiguração tem duas fases distintas de espera:

1) Aguarde que a configuração atual seja comprometida antes de instalar a nova configuração.

The "current" configuration refers to the replica configuration in use by the primary at the time rs.reconfig() is issued.

Uma configuração é confirmada quando:

  • A maioria dos membros do conjunto de réplica de votação instalou a configuração atual e

  • Todas as gravações que foram "majority" confirmadas na configuração anterior também foram replicadas para uma maioria na configuração atual.

Normalmente, a configuração atual já foi instalada na maioria dos membros do conjunto de réplica de votação. No entanto, a maioria das gravações confirmadas na configuração anterior pode não ser confirmada na configuração atual. Delayed membros ou membros que são lagging behind os principais podem aumentar o tempo gasto nessa fase.

If the operation was issued with a maxTimeMS limit and the operation exceeds the limit while waiting, the operation returns an error and discard the new configuration. The limit is cumulative and does not reset after proceeding to the next phase.

2) Aguarde a maioria dos membros votantes na nova configuração instalar a nova configuração.

The "new" configuration refers to the replica configuration specified to rs.reconfig().

The primary installs and begins using the new replica configuration before propagating the configuration to the remaining replica set members. The operation only waits for a majority of voting members to install the new configuration, and does not require waiting for the new configuration to be committed.

If the operation was issued with a maxTimeMS limit and the operation exceeds the limit while waiting, the operation returns an error but continues using and propagating the new configuration.

Issuing a force reconfiguration immediately installs the new configuration regardless of the commitment status of the previous configuration. Force reconfiguration can cause unexpected behavior, such as the rollback of "majority" committed write operations.

Para verificar o status de compromisso da configuração atual da réplica, emita replSetGetConfig com o parâmetro commitmentStatus no conjunto de réplicas principal.

Para executar o método em sistemas que impõem controle de acesso, o usuário deve ter a ação de privilégio replSetConfigure no recurso de cluster. A função integrada clusterManager, disponível no banco de dados admin, fornece os privilégios necessários para esse comando.

rs.reconfig() obtains a special mutually exclusive lock to prevent more than one rs.reconfig() operation from occurring at the same time.

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.

The rs.reconfig() shell method can trigger the current primary to step down in some situations. Primary step-down triggers an election to select a new primary:

Quando o primário é interrompido, ele interrompe todas as gravações em andamento. Confira os detalhes em Comportamento.

O tempo médio antes de um cluster eleger um novo primário normalmente não deve exceder 12 segundos, assumindo replica configuration settingspadrão . Isso inclui o tempo necessário para marcar a primária como indisponível e convocar e concluir uma eleição. Você pode ajustar este período de tempo modificando a opção de configuração de replicação do 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.

Durante o processo de eleição, o cluster não pode aceitar operações de gravação até que eleja o novo primário.

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

Para reduzir ainda mais o impacto potencial em um cluster de produção, reconfigure somente durante os períodos de manutenção programados.

Aviso

O MongoDB não sincroniza uma reconfiguração forçada de conjunto de réplicas entre os conjuntos de réplicas em um cluster. O uso de { force: true } pode levar a uma reversão das gravações comprometidas pela maioria e a um cluster fragmentado inconsistente. Tenha cuidado ao usar essa opção.

Using rs.reconfig() to remove a replica set member does not automatically drop open outgoing connections from other replica set members to the removed member.

Por padrão, os membros do conjunto de réplicas aguardam 5 minutos antes de descartar conexões com o membro removido. Em conjuntos de réplicas fragmentadas, você pode modificar esse tempo limite usando o parâmetroShardingTaskExecutorPoolHostTimeoutMS server.

Para descartar imediatamente todas as conexões de saída do conjunto de réplicas para o nó removido, execute o comando administrativo dropConnections em cada nó restante no conjunto de réplicas:

db.adminCommand(
{
"dropConnections" : 1,
"hostAndPort" : [
"<hostname>:<port>"
]
}
)

Substitua <hostname> e <port> pelos do membro removido.

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.

Quando um novo nó de votação é adicionado a um conjunto de réplicas, replSetReconfig adicionará internamente um campo newlyAdded à configuração do nó. Os nós com o campo newlyAdded não contam para o número atual de nós de votação. Quando a sincronização inicial for concluída e o nó atingir o estado SECONDARY, o campo newlyAdded será automaticamente removido.

Observação

  • As configurações que tentam adicionar um campo chamado newlyAdded apresentarão erros mesmo se executadas com { force: true }.

  • If an existing node has a newlyAdded field, using rs.reconfig() to change the configuration will not remove the newlyAdded field. The newlyAdded field will be appended to the user provided configuration.

  • replSetGetConfig removerá todos os campos newlyAdded de saída. Se quiser ver quaisquer campos newlyAdded, você pode fazer a query da collection local.system.replset diretamente.

Um conjunto de réplica denominado rs0 tem a seguinte configuração:

{
"_id" : "rs0",
"version" : 1,
"protocolVersion" : Long(1),
"members" : [
{
"_id" : 0,
"host" : "mongodb0.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 2000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
}
}

The following sequence of operations updates the members[n].priority of the second member. The operations are issued through a mongosh session that is connected to the primary.

cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);
  1. A primeira declaração usa o método rs.conf() para recuperar um documento que contém a configuração atual para o conjunto de réplicas e define o documento como a variável local cfg.

  2. A segunda instrução define um valor members[n].priority para o segundo documento na array members. Para obter configurações adicionais, consulte as configurações do conjunto de réplicas.

    Para acessar o documento de configuração do membro no array, a instrução usa o índice de array e não o campo members[n]._id do membro do conjunto de réplicas.

  3. The last statement calls the rs.reconfig() method with the modified cfg to initialize this new configuration. Upon successful reconfiguration, the replica set configuration will resemble the following:

{
"_id" : "rs0",
"version" : 2,
"protocolVersion" : Long(1),
"members" : [
{
"_id" : 0,
"host" : "mongodb0.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : Long(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 2000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
}
}

Você também pode modificar o documento de settings do conjunto de réplicas do cluster. O documento settings contém opções de configuração que se aplicam a todo o conjunto de réplicas.

The following sequence of operations updates the settings.heartbeatTimeoutSecs of the cluster to 15. The operations are issued through a mongosh session that is connected to the primary.

cfg = rs.conf();
cfg.settings.heartbeatTimeoutSecs = 15;
rs.reconfig(cfg);