Arbiter do conjunto de réplicas
Nesta página
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 de eleições para primários, mas não tem uma cópia do conjunto de dados e não pode se tornar um primário.
Um arbiter tem exatamente 1 voto na eleição. Por padrão, um arbiter 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
O uso de uma arquitetura PSA (primary-secondary-arbiter) para fragmentos em um cluster fragmentado pode causar uma perda de disponibilidade se um secundário portador de dados não estiver disponível. Um cluster PSA é diferente de um conjunto típico de réplicas: em um cluster fragmentado fragmentado, os shards executam operações de preocupação de gravação w: majority 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.
Considerações sobre a versão
Os árbitros não são compatíveis com as versões rápidas trimestrais. Se a sua implantação incluir árbitros, utilize somente versões do LTS.
Problemas de desempenho em conjuntos de réplicas do PSA
Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:
A preocupação de gravação
"majority"pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como mitigar esses problemas, consulte Atenuar problemas de desempenho com um conjunto de réplicas de PSA autogerenciado.Se você estiver usando um
"majority"padrão global e o write concern for menor do que o tamanho da maioria, suas consultas poderão retornar dados obsoletos (não totalmente replicados).
Chaves de fragmento, transações e árbitros
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.
Preocupações com vários arbiters
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
Segurança
Autenticação
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.
Comunicação
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.
Exemplo
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:
