Ler casos de uso de preferências

Modos de preferência de leitura

• Para todos os modos, um membro está disponível quando responde às verificações de monitoramento periódicas do cliente, que confirmam que o membro está acessível pela rede e é capaz de responder às solicitações.

• Para todos os modos, exceto primary, um membro é elegível se satisfizer a opção maxStalenessSeconds da read preference e qualquer lista de conjunto de tags especificada.

• Para todos os modos, exceto primary, a opção de string de conexão localThresholdMS define o limite local que o cliente usa para calcular a janela de latência ao escolher entre os membros qualificados.

Indicações para usar preferência de leitura não primária

Confira a seguir casos de uso comuns para usar modos de read preference não primary:

• Execução de operações de sistemas que não afetam o aplicativo front-end.

  Observação

  As read preferences não são relevantes para conexões diretas com uma única instância do mongod. No entanto, para executar operações de leitura em uma conexão direta com um membro secundário de um conjunto de réplicas, é necessário definir uma read preference, como secundária.

• Fornecimento de leituras locais para aplicativos distribuídos geograficamente.

  Se você tiver servidores de aplicativos em vários centros de dados, considere ter um conjunto de réplicas distribuído geograficamente e usar uma preferência de leitura não primária ou nearest. Isso permite que o cliente leia a partir dos membros de menor latência, em vez de sempre ler a partir do principal.

• Como manter a disponibilidade durante um failover.

  Use primaryPreferred se quiser que um aplicativo leia a partir do primário em circunstâncias normais, mas permita leituras obsoletas dos secundários quando o primário não estiver disponível.

Contraindicações para Preferência de Leitura Não Primária

Em geral, não use secondary e secondaryPreferred para fornecer capacidade extra para leituras, porque:

• Todos os membros de uma réplica têm tráfego de gravação aproximadamente equivalente; com isso, os secundários servirão leituras aproximadamente na mesma taxa que o primário.

• A replicação é assíncrona e há algum atraso entre uma operação de gravação bem-sucedida e sua replicação para secundários. A leitura de um secundário pode retornar dados obsoletos; A leitura de diferentes secundários pode resultar em leituras não monotônicas.

  Observação

  Os clientes podem usar Sessões de cliente e garantias de consistência causal para garantir leituras monotônicas.

• A distribuição de operações de leitura para secundários pode comprometer a disponibilidade se qualquer membro do conjunto ficar indisponível porque os membros restantes do conjunto precisam ser capazes de lidar com todas as solicitações do aplicativo.

A fragmentação aumenta a capacidade de leitura e gravação ao distribuir as operações de leitura e gravação em um grupo de máquinas e, geralmente, é uma estratégia melhor para aumentar a capacidade.

Consulte Algoritmo de seleção de servidor para obter mais informações sobre a aplicação interna das preferências de leitura.

Maximizar a consistência

Para evitar leituras obsoletas, use primary preferência de leitura e "majority" readConcern. Se o primário não estiver disponível, por exemplo, durante as eleições ou quando a maioria do conjunto de réplicas não estiver acessível, as operações de leitura usando primary preferência de leitura produzirão um erro ou lançarão uma exceção.

Em algumas circunstâncias, pode ser possível que um conjunto de réplicas tenha temporariamente duas primárias; no entanto, apenas uma primária será capaz de confirmar gravações com a write concern "majority".

• Uma partição de rede parcial pode segregar uma primária (P _antigo) em uma partição com uma minoria dos nós, enquanto o outro lado da partição contém a maioria dos nós. A partição com a maioria elegerá uma nova primária (P _{nova), mas por um breve período, a primária antiga (P antigo) ainda pode continuar a servir leituras e gravações, pois ainda não detectou que só pode ver uma minoria de nós no conjunto de réplicas.Durante esse período, se a primária antiga (P antiga) ainda estiver visível para os clientes como principal, as leituras dessa primária podem refletir dados obsoletos.}

• uma primária (P _antiga) pode deixar de responder, o que desencadeará uma eleição e uma nova primária (P _{nova) poderá ser eleita, servindo leituras e gravações.Se a primária que não responde (P antiga) começar a responder novamente, duas primárias ficarão visíveis por um breve período.O breve período terminará quando P antiga parar de funcionar. No entanto, durante um breve período, os clientes podem ler a antiga primária P antiga, que pode fornecer dados obsoletos.}

Para aumentar a consistência, você pode desabilitar o failover automático; no entanto, desabilitar o failover automático sacrifica a disponibilidade.

Maximizar a disponibilidade

Para permitir operações de leitura, quando possível, utilize primaryPreferred. Quando houver um primary, você obterá leituras consistentes [1], mas se não houver um primary, você ainda poderá fazer uma query dos secundários. No entanto, ao usar esse modo de leitura , considere a situação descrita em secondary vs secondaryPreferred.

Minimizar a Latência

To always read from a low-latency node, use nearest. The driver or mongos will read from the nearest member and those no more than 15 milliseconds [2] further away than the nearest member.

nearest não garante consistência. Se o membro mais próximo do seu servidor de aplicativos for uma secundária com algum atraso de replicação, as consultas poderão retornar dados obsoletos. nearest reflete apenas a distância da rede e não reflete a carga de E/S ou CPU.

Consulta de Membros Distribuídos Geograficamente

Se os membros de um conjunto de réplicas estiverem geograficamente distribuídos, você poderá criar marcações de réplicas baseadas que reflitam a localização da instância e, então, configurar seu aplicativo para realizar consultas dos membros próximos.

Por exemplo, se os membros dos centros de dados "leste" e "oeste" estiverem marcados {'dc': 'east'} como e {'dc': 'west'}, seus servidores de aplicativos no centro de dados leste poderão ler de membros próximos com a seguinte preferência de leitura:

db.collection.find().readPref('nearest', [ { 'dc': 'east' } ])

Embora o nearest já favoreça membros com baixa latência de rede, incluir a tag torna a escolha mais previsível.

secondary vs secondaryPreferred

For specific dedicated queries (e.g. ETL, reporting), you may shift the read load from the primary by using the secondary read preference mode. For this use case, the secondary mode is preferable to the secondaryPreferred mode because secondaryPreferred risks the following situation: if all secondaries are unavailable and your replica set has enough arbiters [3] to prevent the primary from stepping down, then the primary will receive all traffic from the clients. If the primary is unable to handle this load, the queries will compete with the writes. For this reason, use read preference secondary to distribute these specific dedicated queries instead of secondaryPreferred.