Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

rs.reconfig()

Nesta página

  • Definição
  • Comportamento
  • Exemplos
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 se conectar aoprimário do conjunto de réplicas.

Importante

Método mongosh

Esta página documenta um método mongosh. Esta não é a documentação de comandos de banco de dados nem drivers específicos de linguagem, como 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.

O método rs.reconfig() tem a seguinte sintaxe:

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

configuração, configuraçã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 ou indesejado, incluindo a reversão de "majority" gravações confirmadas.

inteiro

Opcional

Especifica um limite de tempo cumulativo em milissegundos para processar a operação rs.reconfig(). Por padrão, o rs.reconfig() espera indefinidamente que a configuração da réplica propague para a maioria dos membros do conjunto de réplica.

Para reconfigurar um conjunto de réplicas existente, primeiro recupere a configuração atual com rs.conf(), modifique o documento de configuração conforme o necessário e, em seguida, passe o documento modificado para rs.reconfig().

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

A partir do MongoDB 5.0, você deve definir explicitamente a preocupação de gravação padrão global antes de tentar reconfigurar um conjunto de réplicas com uma configuração que altere a preocupação de gravação padrão implícita. Para definir a preocupação de escrita padrão global, utilize o comando setDefaultRWConcern.

O campo term é definido pelo membro primário do conjunto de réplicas. O primário ignora o campo term se definido explicitamente na operação rs.reconfig().

rs.reconfig() por padrão permite adicionar ou remover não mais do que 1 voting membros de cada vez. Por exemplo, uma nova configuração pode fazer, no máximo, uma das seguintes alterações no 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.

Para adicionar ou remover vários membros votantes, emita uma série de operações rs.reconfig() para adicionar ou remover um membro de cada vez.

A emissão de uma reconfiguração forçada instala imediatamente a nova configuração, mesmo que ela adicione ou remova vários membros votantes. A reconfiguração forçada pode causar um comportamento inesperado, como a reversão das operações de gravação confirmadas pelo "majority".

rs.reconfig() aguarda até que a maioria dos membros votantes do conjunto de réplicas instale a nova configuração de réplica antes de retornar sucesso. Um membro votante é qualquer membro do conjunto de réplicas em que members[n].votes é 1, incluindo árbitros.

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.

A configuração "atual" refere-se à configuração de réplica em uso pelo primário no momento em rs.reconfig() é emitido.

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.

Se a operação tiver sido emitida com um limite de maxTimeMS e a operação exceder o limite enquanto espera, a operação retornará um erro e descartará a nova configuração. O limite é cumulativo e não é redefinido após prosseguir para a próxima fase.

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

A configuração "nova" refere-se à configuração de réplica especificada para rs.reconfig().

O primário instala e começa a usar a nova configuração de réplica antes de propagar a configuração para os membros restantes do conjunto de réplicas. A operação aguarda apenas que a maioria dos membros votantes instale a nova configuração e não requer a espera para que a nova configuração seja confirmada.

Se a operação foi emitida com um limite maxTimeMS e a operação exceder o limite durante a espera, a operação retornará um erro , mas continuará usando e propagando a nova configuração.

A emissão de uma reconfiguração forçada instala imediatamente a nova configuração, independentemente do status de compromisso da configuração anterior. A reconfiguração forçada pode causar um comportamento inesperado, como a reversão das operações de gravação confirmadas pelo "majority".

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() obtém um bloqueio especial mutuamente exclusivo para evitar que mais de uma operação rs.reconfig() ocorra ao mesmo tempo.

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.

O método rs.reconfig() shell pode acionar o primário atual diminua em algumas situações. A redução do primário aciona uma eleição para selecionar um novo primário:

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.

O uso de rs.reconfig() para remover um membro do conjunto de réplicas não descarta automaticamente as conexões de saída abertas de outros membros do conjunto de réplicas para o membro removido.

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 }.

  • Se um nó existente tiver um campo newlyAdded, o uso de rs.reconfig() para alterar a configuração não removerá o campo newlyAdded. O campo newlyAdded será anexado à configuração fornecida pelo usuário.

  • 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" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "mongodb0.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 2000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
}
}

A seguinte sequência de operações atualiza a members[n].priority do segundo membro. As operações são emitidas por meio de uma sessão mongosh que está conectada ao primário.

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. A última declaração chama o método rs.reconfig() com o cfg modificado para inicializar esta nova configuração. Após a reconfiguração bem-sucedida, a configuração do conjunto de réplicas será semelhante à seguinte:

{
"_id" : "rs0",
"version" : 2,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "mongodb0.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(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.

A seguinte sequência de operações atualiza o settings.heartbeatTimeoutSecs do agrupamento para 15. As operações são emitidas por meio de uma sessão que está conectada ao mongosh primário.

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

Dica

Veja também:

Voltar

rs.printSecondaryReplicationInfo