Ler casos de uso de preferências

Modos de preferência de leitura

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, use 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

Para sempre ler a partir de um nó de baixa latência, use nearest. O driver ou mongos fará a leitura a partir do membro mais próximo e daqueles que estiverem a no máximo 15 milissegundos [2] de distância do membro mais próximo.

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

Para queries dedicadas específicas (por exemplo, ETL, relatórios), é possível transferir a carga de leitura do primary usando o modo de read preference secondary. Para esse caso de uso, o modo secondary é preferível ao modo secondaryPreferred, pois secondaryPreferred arrisca a seguinte situação: se todos os secundários estiverem indisponíveis e seu conjunto de réplicas tiver arbiters [3] suficientes para evitar que o primary caia, o primary receberá todo o tráfego dos clientes. Se o primary não conseguir lidar com essa carga, as queries competirão com as escritas. Por esse motivo, use a read preference secondary para distribuir essas queries dedicadas específicas em vez de secondaryPreferred.