Arbiter do conjunto de réplicas
Nesta página
Em algumas circunstâncias (como quando você tem um primário e um secundário, mas as restrições de custo proíbem a adição de outro secundário), você pode optar por adicionar um árbitro ao seu conjunto de réplicas. Um árbitro participa de eleições para o primário, mas um árbitro 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.
Para adicionar um árbitro, consulte Adicionar um árbitro a um conjunto de réplicas autogerenciado.
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:
O write concern
"majority"pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como atenuar esses problemas, consulte Atenuar problemas de desempenho com um conjunto de réplicas 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 Shard, 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 arbiter. 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:
