Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Ler casos de uso de preferências
Nesta página
O documento a seguir explica casos de uso comuns para vários modos de read preference , bem como contraindicações descrevendo quando você não deve alterar a read preference do primary padrão.
Modos de preferência de leitura
Modo de preferência de leitura | Descrição |
|---|---|
Modo padrão. Todas as operações são lidas a partir do conjunto de réplicas atual principal. Transações distribuídas que contêm operações de leitura devem usar a read preference | |
Na maioria das situações, as operações são lidas a partir do principal, mas se estiverem indisponíveis, as operações são lidas de nós secundários. Preferência de leitura | |
Todas as operações são lidas a partir dos nós secundários do conjunto de réplica. Preferência de leitura | |
Operações normalmente leem dados de nós secundários do conjunto de réplica. Se o conjunto de réplica tiver somente um único nó primário e nenhum outro nó, as operações lerão os dados do nó primário. Preferência de leitura | |
As operações lidas de um nó aleatório qualificado do conjunto de réplicas, independentemente de esse nó ser primário ou secundário, com base em um limite de latência especificado. A operação considera o seguinte ao calcular latência:
A 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
primaryPreferredse quiser que um aplicativo leia 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.
Alterado na versão 3.6: A partir do MongoDB 3.6, 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 (
Pantigo) 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 (Pnova), mas por um breve período, a primária antiga (Pantigo) 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 (Pantiga) ainda estiver visível para os clientes como principal, as leituras dessa primária podem refletir dados obsoletos.uma primária (
Pantiga) pode deixar de responder, o que desencadeará uma eleição e uma nova primária (Pnova) poderá ser eleita, servindo leituras e gravações.Se a primária que não responde (Pantiga) começar a responder novamente, duas primárias ficarão visíveis por um breve período.O breve período terminará quandoPantiga parar de funcionar. No entanto, durante um breve período, os clientes podem ler a antiga primáriaPantiga, 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.
| [1] | Em algumas circunstâncias, dois nós em um conjunto de réplicas podem acreditar transitoriamente que são os principais, mas, no máximo, um deles poderá concluir as gravações com { w:
"majority" } preocupação de gravação. O nó que pode completar { w: "majority" } gravações é o primary atual, e o outro nó é um antigo primary que ainda não reconheceu seu rebaixamento, normalmente devido a uma partição de rede. Quando isso ocorre, os clientes que se conectam ao primário anterior podem observar dados obsoletos apesar de terem solicitado preferência de leitura primary, e novas gravações no primário anterior eventualmente serão revertidas. |
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.
| [2] | Este limite é configurável. Consulte localPingThresholdMs para mongos ou a documentação do driver para obter a configuração apropriada. |
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.
| [3] | Em geral, evite implantar árbitros em conjuntos de réplicas e, em vez disso, use um número ímpar de nós portadores de dados. Se você precisar implantar árbitros, evite implantar mais de um árbitro por conjunto de réplicas. |