Menu Docs

Arbiter do conjunto de réplicas

Em determinadas circunstâncias (p. ex., quando existe um primário e um secundário, mas restrições orçamentárias impedem o acréscimo de outro secundário), você pode incluir um árbitro ao seu conjunto de réplicas. Um árbitro participa nas eleições do primário, mas não possui uma cópia do conjunto de dados e não pode se tornar o primário.

Um árbitro tem exatamente 1 voto eleitoral. Por padrão, um árbitro tem prioridade 0.

Importante

Não execute um árbitro em sistemas que também hospedem os membros principais ou secundários do conjunto de réplicas.

Aviso

Usar uma arquitetura de primário-secundário-árbitro (PSA) para fragmentos em um cluster fragmentado pode causar perda de disponibilidade se um secundário contendo dados não estiver disponível. Um cluster PSA difere de um conjunto de réplicas típico: em um cluster fragmentado, os fragmentos realizam w: majority operações de preocupação de gravação que não podem ser concluídas se os membros restantes do cluster necessários para confirmar uma operação tiverem um árbitro.

Para adicionar um árbitro, consulte Adicionar um árbitro a um conjunto de réplicas autogerenciadas.

Os arbiters não são suportados com rapid releases trimestrais. Se seu sistema incluir arbiters, use somente versões LTS.

Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:

Você não pode alterar uma chave de shard usando uma transação se o conjunto de réplicas tiver um árbitro. Os árbitros não podem participar das operações de dados necessárias para transações com vários shards.

As transações cujas operações de gravação abrangem vários fragmentos gerarão o erro e serão abortadas se qualquer operação de transação ler ou gravar em um fragmento que contenha um árbitro.

Use um único arbiter para evitar problemas com a consistência dos dados. Vários arbiters impedem o uso confiável da write concern majoritária.

Para garantir que uma gravação persistirá após a falha de um nó primary, a maioria das write concerns exigem a maioria dos nós para confirmar uma operação de gravação. Os arbiters não armazenam quaisquer dados, mas contribuem para o número de nós em um conjunto de réplicas. Quando um conjunto de réplicas tem vários arbiters, é menos provável que a maioria dos nós portadores de dados esteja disponível após uma falha no nó.

Aviso

Se um nó secundário ficar atrás do primary e o cluster for reconfigured, os votos de vários arbiters poderão eleger o nó que ficou para trás. O novo primary não terá as gravações não replicadas, embora as gravações possam ter sido confirmadas majoritariamente pela configuração antiga. O resultado é a perda de dados.

Para evitar esse cenário, use no máximo um único arbiter.

Novidades na versão 5.3.

A partir do MongoDB 5.3, o suporte para vários arbiters em um conjunto de réplicas vem desabilitado por padrão. Se você tentar adicionar vários arbiters a um conjunto de réplicas, o servidor retornará um erro:

MongoServerError: Multiple arbiters are not allowed unless all nodes
were started with --setParameter 'allowMultipleArbiters=true'

Para adicionar vários arbiters a um conjunto de réplicas utilizando o MongoDB 5.3 ou posterior, inicie cada nó com o parâmetro allowMultipleArbiters configurado como true:

mongod --setParameter allowMultipleArbiters=true

Ao executar com authorization, os arbiters trocam credenciais com outros membros do conjunto para autenticar. O MongoDB criptografa o processo de autenticação e sua troca de autenticação é criptograficamente segura.

Como os arbiters não armazenam dados, eles não possuem a tabela interna de mapeamentos de roles e usuários usada para autenticação. Assim, a única maneira de fazer login em um arbiter com autorização ativa é usar a exceção do localhost.

A única comunicação entre os arbiters e os outros membros do conjunto é: votos durante as eleições, batimentos cardíacos e dados de configuração. Essas trocas não são criptografadas.

No entanto, se o MongoDB deployment usar TLS/SSL, o MongoDB criptografará toda a comunicação entre os nós do conjunto de réplicas. Consulte Configurar mongod e mongos para TLS/SSL para mais informações.

Tal como acontece com todos os componentes do MongoDB, execute arbiters em ambientes de rede confiáveis.

Por exemplo, no seguinte conjunto de réplicas com dois membros portadores de dados (o primary e um secundário), um arbiter permite que o conjunto tenha um número ímpar de votos para desempatar:

Diagram of a replica set that consists of a primary, a secondary, and an arbiter.