readPreference
Nesta página
A preferência de leitura descreve como os clientes MongoDB direcionam as operações de leitura para os membros de um conjunto de réplicas.
Por padrão, um aplicativo direciona suas operações de leitura para o nó primário em um conjunto de réplicas (ou seja, modo de read preference "primary"). Mas os clientes podem especificar uma read preference para enviar operações de leitura para secundários.
A preferência de leitura consiste no modo de preferência de leitura e, como opção, em uma lista de conjuntos de tags e na opção maxStalenessSeconds.
Modos de preferência de leitura
A tabela a seguir resume os 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 utilizar a preferência de leitura | |
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. | |
Todas as operações são lidas a partir dos nós secundários do conjunto de réplica. | |
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. | |
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:
|
Para obter uma descrição detalhada dos modos de preferência de leitura, consulte Modos de preferência de leitura.
Comportamento
Todos os modos de preferência de leitura, exceto
primary
, podem retornar dados obsoletos porque os secundários replicam as operações do primário em um processo assíncrono. [1] Certifique-se de que seu aplicativo possa tolerar dados obsoletos se você optar por usar um modo não-primary
.A preferência de leitura não afeta a visibilidade dos dados, ou seja, os clientes podem ver os resultados das gravações antes que elas sejam reconhecidas ou propagadas para a maioria dos membros do conjunto de réplicas. Para obter detalhes, consulte Isolamento de leitura, consistência e recência.
A read preference não afeta a consistência causal. As garantias de consistência causal fornecidas por sessões causalmente consistentes para operações de leitura com read concern
"majority"
e operações de gravação com write concern"majority"
são mantidas em todos os membros da implantação do MongoDB.
Aviso
Leituras secundárias em um cluster fragmentado com migrações podem perder documentos
As leituras secundárias de longa duração em um cluster fragmentado podem perder documentos se estiverem ocorrendo migrações.
Antes de excluir um fragmento durante a migração do fragmento, o MongoDB espera que orphanCleanupDelaySecs
ou que as queries em andamento envolvendo o fragmento sejam concluídas no fragmento primário, o que for mais longo. As queries que foram executadas inicialmente em um nó primário, mas continuam após o nó passar para um secundário, serão tratadas como se tivessem sido executadas inicialmente em um secundário. Ou seja, o servidor só espera por orphanDelayCleanupSecs
se não houver queries direcionadas à parte do primário atual.
As queries que têm como alvo a parte e são executadas em réplicas secundárias podem perder documentos se levarem mais de orphanCleanupDelaySecs
.
Modos de preferência de leitura
primary
Todas as operações de leitura usam somente o conjunto de réplicas primário atual. [1] Este é o modo de leitura padrão. Se o primário não estiver disponível, as operações de leitura produzem um erro ou geram uma exceção.
O modo de preferência de leitura
primary
não é compatível com modos de preferência de leitura que utilizam listas de conjuntos de tags ou maxStalenessSeconds. Se você especificar listas de conjuntos de tags ou um valormaxStalenessSeconds
comprimary
, o driver produzirá um erro.Transações distribuídas que contêm operações de leitura devem utilizar a preferência de leitura
primary
. Todas as operações em uma determinada transação devem ser roteadas para o mesmo membro.
primaryPreferred
Na maioria das situações, as operações são lidas do nó primário do conjunto. No entanto, se o primário não estiver disponível, como é o caso em situações de failover, as operações são lidas de nós secundários que satisfazem as read preferences de
maxStalenessSeconds
e as listas de conjuntos de tags.Quando a preferência de leitura
primaryPreferred
inclui um valor de maxStalenessSeconds e não há nenhum primário do qual ler, o cliente estima o quão obsoleto cada secundário está comparando a última gravação do secundário com a do secundário com a gravação mais recente. Em seguida, o cliente direcionará a operação de leitura para um secundário cujo atraso estimado seja menor ou igual amaxStalenessSeconds
.Quando a read preference inclui uma lista de conjuntos de tags (um array de conjuntos de tags) e não há um primary do qual ler, o cliente tenta encontrar membros secundários com tags correspondentes (tentando os conjuntos de tags em ordem até encontrar uma correspondência). Quando são encontrados secundários correspondentes, o cliente seleciona um secundário aleatório do grupo mais próximo de secundários correspondentes. Se nenhum secundário tiver tags correspondentes, a operação de leitura produz um erro.
Quando a read preference inclui um valor
maxStalenessSeconds
e uma lista de conjuntos de tags, o cliente filtra primeiro por obsolescência e, em seguida, pelas tags especificadas.As operações de leitura utilizando o modo
primaryPreferred
podem retornar dados obsoletos. Use a opçãomaxStalenessSeconds
para evitar a leitura de secundários que o cliente estima estarem excessivamente obsoletos.
secondary
As operações são lidas somente dos membros secundários do conjunto. Se nenhum secundário estiver disponível, essa operação de leitura produz um erro ou exceção.
A maioria dos conjuntos de réplicas tem pelo menos um secundário, mas há situações em que pode não haver um secundário disponível. Por exemplo, um conjunto de réplicas com um primary, um secundário e um arbiter pode não ter nenhum secundário se um membro estiver em estado de recuperação ou indisponível.
Quando a preferência de leitura
secondary
inclui um valor maxStalenessSeconds, o cliente estima a obsolescência de cada secundário comparando a última gravação do secundário com a do primário. Em seguida, o cliente direcionará a operação de leitura para um secundário cujo atraso estimado seja menor ou igual amaxStalenessSeconds
. Se não houver um primário, o cliente usará o secundário com a gravação mais recente para comparar.Quando a read preference inclui uma lista de conjuntos de tags (um array de conjuntos de tags), o cliente tenta encontrar membros secundários com tags correspondentes (tentando os conjuntos de tags em ordem até encontrar uma correspondência). Quando são encontrados secundários correspondentes, o cliente seleciona um secundário aleatório do grupo mais próximo de secundários correspondentes. Se nenhum secundário tiver tags correspondentes, a operação de leitura produz um erro.
Quando a read preference inclui um valor
maxStalenessSeconds
e uma lista de conjuntos de tags, o cliente filtra primeiro por obsolescência e, em seguida, pelas tags especificadas.As operações de leitura utilizando o modo
secondary
podem retornar dados obsoletos. Use a opçãomaxStalenessSeconds
para evitar a leitura de secundários que o cliente estima estarem excessivamente obsoletos.
secondaryPreferred
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.
Quando a preferência de leitura
secondaryPreferred
inclui um valor maxStalenessSeconds, o cliente estima a obsolescência de cada secundário comparando a última gravação do secundário com a do primário. Em seguida, o cliente direcionará a operação de leitura para um secundário cujo atraso estimado é menor ou igual amaxStalenessSeconds
. Se não houver um primário, o cliente usará o secundário com a gravação mais recente para a comparação. Se não houver secundários com atraso estimado menor ou igual amaxStalenessSeconds
, o cliente direcionará a operação de leitura para o primário do conjunto de réplicas.Quando a read preference inclui uma lista de conjuntos de tags (um array de conjuntos de tags), o cliente tenta encontrar membros secundários com tags correspondentes (tentando os conjuntos de tags em ordem até encontrar uma correspondência). Quando são encontrados secundários correspondentes, o cliente seleciona um secundário aleatório do grupo mais próximo de secundários correspondentes. Se nenhum secundário tiver tags correspondentes, o cliente ignora as tags e leituras do primary.
Quando a read preference inclui um valor
maxStalenessSeconds
e uma lista de conjuntos de tags, o cliente filtra primeiro por obsolescência e, em seguida, pelas tags especificadas.As operações de leitura utilizando o modo
secondaryPreferred
podem retornar dados obsoletos. Use a opçãomaxStalenessSeconds
para evitar a leitura de secundários que o cliente estima estarem excessivamente obsoletos.
nearest
O driver lê de um membro cuja latência de rede recai dentro da janela de latência aceitável. As leituras no modo
nearest
não consideram se um membro é um primário ou secundário ao rotear operações de leitura: primários e secundários são tratados de forma equivalente.Defina esse modo para minimizar o efeito da latência de rede nas operações de leitura sem preferência por dados atuais ou obsoletos.
Quando a read preference inclui um valor maxStalenessSeconds, o cliente estima o quanto cada secundário está obsoleto comparando a última gravação do secundário com a do primary, se disponível, ou com o secundário com a gravação mais recente se não houver nenhum primary. Em seguida, o cliente filtra qualquer secundário cuja defasagem estimada seja maior que
maxStalenessSeconds
e direciona aleatoriamente a leitura para um membro restante (primary ou secundário) cuja latência de rede esteja dentro da janela de latência aceitável.Se você especificar uma lista de conjuntos de tags, o cliente tentará encontrar um membro do conjunto de réplicas que corresponda às listas de conjuntos de tags especificadas e direcionará as leituras para um membro arbitrário do grupo mais próximo.
Quando a read preference inclui um valor
maxStalenessSeconds
e uma lista de conjuntos de tags, o cliente filtra primeiro por obsolescência e, em seguida, pelas tags especificadas. Das instânciasmongod
restantes, o cliente direciona aleatoriamente a leitura para uma instância que esteja dentro da janela de latência aceitável. A documentação da seleção de membro da read preference descreve o processo em detalhes.As operações de leitura utilizando o modo
nearest
podem retornar dados obsoletos. Use a opçãomaxStalenessSeconds
para evitar a leitura de secundários que o cliente estima estarem excessivamente obsoletos.
Dica
Veja também:
Para saber mais sobre casos de uso de configurações específicas de preferências de leitura, consulte Casos de uso de preferências de leitura.
Configurar read preference
Ao usar um driver do MongoDB, é possível especificar a preferência de leitura usando a API de preferência de leitura do driver. Consulte a documentação da API do driver. Você também pode definir a preferência de leitura ao se conectar ao conjunto de réplicas ou ao cluster fragmentado. Por exemplo,consulte string de conexão.
Para uma determinada preferência de leitura, os drivers MongoDB usam a mesma lógica de seleção de membros.
Ao usar mongosh
, consulte cursor.readPref()
e Mongo.setReadPref()
.
Read preference e transações
Transações distribuídas que contêm operações de leitura devem utilizar a preferência de leitura primary
. Todas as operações em uma determinada transação devem ser roteadas para o mesmo membro.
Considerações adicionais
Considere os seguintes pontos ao usar os estágios $merge
ou $out
em um pipeline de agregação:
A partir do MongoDB 5.0, os pipelines com um estágio
$merge
poderão ser executados em nós secundários do conjunto de réplicas se todos os nós do cluster tiverem a featureCompatibilityVersion definida como5.0
ou superior e a preferência de leitura permitir leituras secundárias.nas versões anteriores do MongoDB , os pipelines com estágios
$out
ou$merge
sempre são executados no nó principal, e a preferência de leitura não é considerada.
Para as operações mapReduce
, somente as operações "inline" mapReduce
que não gravam dados são compatíveis com a read preference. Caso contrário, as operações mapReduce
serão executadas no nó primário.
[1] | (1, 2) Em algumas circunstâncias, dois nós em um conjunto de réplicas podem acreditar transitoriamente que são os primários, mas, no máximo, um deles poderá concluir as gravações com preocupação de gravação { w:
"majority" } . O nó que pode concluir gravações { w: "majority" } é o primário atual, e o outro nó é um antigo primário que ainda não reconheceu seu rebaixamento, geralmente devido a uma partição de rede. Quando isso ocorre, os clientes que se conectam ao antigo primário podem observar dados obsoletos, apesar de terem solicitado a preferência de leitura primary , e novas gravações no antigo primário acabarão sendo revertidas. |