Docs Menu
Docs Home
/ /

preferencia de lectura

La preferencia de lectura describe cómo los clientes MongoDB enrutan las operaciones de lectura a los miembros de una conjunto de réplicas.

Operaciones de lectura en un set de réplicas. La preferencia de lectura por defecto dirige la lectura al primario. La preferencia de lectura de ``nearest`` dirige la lectura al nodo más cercano.
haga clic para ampliar

Por defecto, una aplicación dirige sus operaciones de lectura al nodo primario de un set de réplicas (es decir, el modo de preferencia de lectura “primario”). Sin embargo, los clientes pueden especificar una preferencia de lectura para enviar operaciones de lectura a los secundarios.

La preferencia de lectura consiste en Modo de preferencia de lectura y, opcionalmente, una lista de conjuntos de etiquetas, la opción maxStalenessSeconds y la opción de lectura con cobertura. Esta opción está disponible para clústeres fragmentados para lecturas que no utilizan...primary preferencia de lectura.

La siguiente tabla enumera un breve resumen de los modos de preferencia de lectura:

Nota

Los modos deprimary preferencia de lectura que no son admiten lecturas protegidas en clústeres fragmentados.

Modo de preferencia de lectura
Descripción

Modo por defecto. Todas las operaciones se leen del actual set de réplicas primario.

Las transacciones que contienen operaciones de lectura deben usar la preferencia de primary lectura. Todas las operaciones de una transacción deben dirigirse al mismo miembro.

En la mayoría de las situaciones, las operaciones leen desde el primario, pero si no está disponible, las operaciones leen desde los nodos secundarios.

La preferencia de lectura primaryPreferred admite lecturas protegidas en clústeres fragmentados.

Todas las operaciones leen de los miembros secundarios del set de réplicas.

La preferencia de lectura secondary admite lecturas protegidas en clústeres fragmentados.

Las operaciones suelen leer datos de los nodos secundarios del set de réplicas. Si el set de réplicas tiene solo un único miembro primario y ningún otro miembro, las operaciones leen datos del nodo primario.

La preferencia de lectura secondaryPreferred admite lecturas protegidas en clústeres fragmentados.

Las operaciones se leen de un nodo elegible al azar del set de réplicas, independientemente de si ese nodo es primario o secundario, según un umbral de latencia específico. La operación considera lo siguiente al calcular la latencia:

La preferencia de lectura nearest admite lecturas cubiertas en clústeres fragmentados y habilita la opción de lectura cubierta de forma predeterminada.

Para obtener una descripción detallada de los modos de preferencia de lectura, consulta Modos de preferencia de lectura.

Tip

  • Todos los modos de preferencia de lectura excepto primary pueden devolver datos obsoletos porque los secundarios replican operaciones del primario en un proceso asincrónico. [1] Asegúrese de que la aplicación pueda tolerar datos obsoletos si se decide utilizar una moda no primary.

  • La preferencia de lectura no afecta la visibilidad de los datos; es decir, los clientes pueden ver los resultados de las escrituras antes de que sean reconocidos o se hayan propagado a la mayoría de los miembros del set de réplicas. Para obtener más detalles, consulta el Lectura, coherencia y actualidad de la lectura.

  • La preferencia de lectura no afecta a la coherencia causal. Las garantías de coherencia causal proporcionadas por las sesiones con coherencia causal para operaciones de lectura con un nivel de consistencia de lectura "majority" y operaciones de escritura con un nivel de confirmación de escritura "majority" se mantienen en todos los nodos de la implementación de MongoDB.

Advertencia

Las lecturas secundarias en un clúster fragmentado con migraciones pueden perder documentos

Las lecturas secundarias de larga duración en un clúster fragmentado pueden perder documentos si se están produciendo migraciones.

Antes de eliminar un fragmento durante la migración, MongoDB espera a que las consultas en curso que lo involucran se completen en el nodo principal del fragmento y luego espera orphanCleanupDelaySecs segundos adicionales. Las consultas que se ejecutaron inicialmente en un nodo principal, pero que continúan después de que este haya pasado a un nodo secundario, se tratarán como si se hubieran ejecutado inicialmente en un nodo secundario. Es decir, el servidor solo espera orphanDelayCleanupSecs si no hay consultas dirigidas al fragmento en el nodo principal actual.

Las consultas que tienen como objetivo el fragmento y se ejecutan en recursos secundarios pueden perder documentos si estas consultas tardan más de orphanCleanupDelaySecs.

primary

Todas las operaciones de lectura utilizan únicamente el primario del set de réplicas actual. [1] Este es el modo de lectura por defecto. Si el primario no está disponible, las operaciones de lectura producen un error o lanzan una excepción.

La primary moda de preferencia de lectura no es compatible con las modas de preferencia de lectura que utilizan listas de conjuntos de etiquetas o maxStalenessSeconds. Si especificas listas de conjuntos de etiquetas o un valor de maxStalenessSeconds con primary, el driver producirá un error.

Las transacciones que contienen operaciones de lectura deben usar la preferencia de primary lectura. Todas las operaciones de una transacción deben dirigirse al mismo miembro.

primaryPreferred

En la mayoría de las situaciones, las operaciones leen desde el nodo primario del conjunto. Sin embargo, si el primario no está disponible, como sucede en situaciones failover, las operaciones leen de los nodos secundarios que satisfacen las listas de conjunto de etiquetas y maxStalenessSeconds de preferencia de lectura.

Cuando la preferencia de lecturaprimaryPreferred incluye un valor maxStalenessSeconds y no hay un primario desde el cual leer, el cliente estima cuán obsoleto está cada secundario al comparar su última escritura con la del secundario que tiene la escritura más reciente. El cliente entonces dirige la operación de lectura a un secundario cuya demora estimada es menor o igual a maxStalenessSeconds.

Cuando la preferencia de lectura incluye una lista de conjuntos de etiquetas (un arreglo de conjuntos de etiquetas) y no hay un primario desde el cual leer, el cliente intenta encontrar nodos secundarios con etiquetas coincidentes (probando los conjuntos de etiquetas en orden hasta encontrar una coincidencia). Si se encuentran secundarios coincidentes, el cliente selecciona un secundario aleatorio del grupo más cercano de secundarios coincidentes. Si ningún secundario tiene etiquetas coincidentes, se produce un error en la operación de lectura.

Cuando la preferencia de lectura incluye un valor maxStalenessSeconds y una lista de conjuntos de etiquetas, el cliente filtra primero por obsolescencia y luego por las etiquetas especificadas.

Las operaciones de lectura que usen el modo primaryPreferred pueden devolver datos obsoletos. Usa la opción maxStalenessSeconds para evitar leer de los secundarios que el cliente estima que están demasiado desactualizados.

Nota

La preferencia de lectura primaryPreferred admite lecturas protegidas en clústeres fragmentados.

secondary

Las operaciones leen únicamente de los nodos secundarios del conjunto. Si no hay secundarios disponibles, esta operación de lectura produce un error o una excepción.

La mayoría de los sets de réplicas tienen al menos un secundario, pero hay situaciones en las que puede no haber ningún secundario disponible. Por ejemplo, un set de réplicas con un primario, un secundario y un árbitro puede no tener secundarios si un nodo está en el estado Recuperando o no disponible.

Cuando la preferencia de lectura secondary incluye un valor de maxStalenessSeconds, el cliente estima qué tan desactualizado está cada secundario en comparación con la última escritura del secundario con la del primario. El cliente entonces dirige la operación de lectura a un secundario cuya demora estimada es menor o igual a maxStalenessSeconds. Si no hay un primario, el cliente usa el secundario con la escritura más reciente para la comparación.

Cuando la preferencia de lectura incluye una lista de conjuntos de etiquetas (un arreglo de conjuntos de etiquetas), el cliente intenta encontrar nodos secundarios con etiquetas coincidentes (probando los conjuntos de etiquetas en orden hasta que se encuentra una coincidencia). Si se encuentran secundarios coincidentes, el cliente selecciona un secundario aleatorio del grupo más cercano de secundarios coincidentes. Si ningún secundario tiene etiquetas coincidentes, se produce un error en la operación de lectura.

Cuando la preferencia de lectura incluye un valor maxStalenessSeconds y una lista de conjuntos de etiquetas, el cliente filtra primero por obsolescencia y luego por las etiquetas especificadas.

Las operaciones de lectura que usen el modo secondary pueden devolver datos obsoletos. Usa la opción maxStalenessSeconds para evitar leer de los secundarios que el cliente estima que están demasiado desactualizados.

Nota

La preferencia de lectura secondary admite lecturas protegidas en clústeres fragmentados.

secondaryPreferred

Las operaciones suelen leer datos de los nodos secundarios del set de réplicas. Si el set de réplicas tiene solo un único miembro primario y ningún otro miembro, las operaciones leen datos del nodo primario.

Cuando la preferencia de lectura secondaryPreferred incluye un valor de maxStalenessSeconds, el cliente estima qué tan desactualizado está cada secundario en comparación con la última escritura del secundario con la del primario. El cliente entonces dirige la operación de lectura a un secundario cuya demora estimada es menor o igual a maxStalenessSeconds. Si no hay un primario, el cliente usa el secundario con la escritura más reciente para la comparación. Si no hay secundarios con un retardo estimado menor o igual a maxStalenessSeconds, el cliente dirige la operación de lectura al primario del set de réplicas.

Cuando la preferencia de lectura incluye una lista de conjuntos de etiquetas (un arreglo de conjuntos de etiquetas), el cliente intenta encontrar nodos secundarios con etiquetas coincidentes (probando los conjuntos de etiquetas en orden hasta que se encuentra una coincidencia). Si se encuentran secundarios coincidentes, el cliente selecciona un secundario aleatorio del grupo más cercano de secundarios coincidentes. Si ninguno de los secundarios tiene etiquetas coincidentes, el cliente ignora las etiquetas y lee del primario.

Cuando la preferencia de lectura incluye un valor maxStalenessSeconds y una lista de conjuntos de etiquetas, el cliente filtra primero por obsolescencia y luego por las etiquetas especificadas.

Las operaciones de lectura que usen el modo secondaryPreferred pueden devolver datos obsoletos. Usa la opción maxStalenessSeconds para evitar leer de los secundarios que el cliente estima que están demasiado desactualizados.

Nota

La preferencia de lectura secondaryPreferred admite lecturas protegidas en clústeres fragmentados.

nearest

El driver lee de un nodo cuya latencia de red cae dentro de la ventana de latencia aceptable. Las lecturas en la moda nearest no consideran si un nodo es primario o secundario al enrutar las operaciones de lectura: los primarios y los secundarios se tratan de manera equivalente.

Configure este modo para minimizar el efecto de la latencia de la red en las operaciones de lectura sin preferencia por datos actuales u obsoletos.

Cuando la preferencia de lectura incluye un valor maxStalenessSeconds, el cliente estima cuán obsoleto es cada secundario mediante la comparación de la última escritura del secundario con la del primario, si está disponible, o la del secundario con la escritura más reciente si no hay un primario. A continuación, el cliente filtrará cualquier nodo secundario cuyo retardo estimado sea superior a maxStalenessSeconds y dirigirá aleatoriamente la lectura a un nodo restante (primario o secundario) cuya latencia de red se encuentre dentro de la ventana de latencia aceptable.

Si especifica una lista de conjuntos de etiquetas, el cliente intenta encontrar un nodo del set de réplicas que coincida con las listas de conjuntos de etiquetas especificadas y dirige las lecturas a un nodo arbitrario del grupo más cercano.

Cuando la preferencia de lectura incluye un valor maxStalenessSeconds y una lista de conjuntos de etiquetas, el cliente filtra primero por obsolescencia y luego por las etiquetas especificadas. De las instancias de mongod restantes, el cliente dirige aleatoriamente la lectura a una instancia que esté dentro de la ventana de latencia aceptable. La documentación sobre la selección de miembros de preferencia de lectura describe el proceso en detalle.

Las operaciones de lectura que usen el modo nearest pueden devolver datos obsoletos. Usa la opción maxStalenessSeconds para evitar leer de los secundarios que el cliente estima que están demasiado desactualizados.

Nota

La preferencia nearest de lectura, de manera predeterminada, especifica el uso de lecturas protegidas para lecturas en un clúster fragmentado.

Tip

Para aprender sobre casos de uso para configuraciones específicas de preferencia de lectura, vea Casos de uso de preferencia de lectura.

Al usar un controlador MongoDB, puede especificar la preferencia de lectura mediante la API de preferencias de lectura del controlador. Consulte la documentación de la API del controlador. También puede configurar la preferencia de lectura (excepto la opción de lectura protegida) al conectarse al conjunto de réplicas o al clúster fragmentado. Para ver un ejemplo, consulte la cadena de conexión.

Para una preferencia de lectura determinada, los controladores de MongoDB utilizan la misma lógica de selección de miembros.

Al usar mongosh, consulta cursor.readPref() y Mongo.setReadPref().

Las transacciones que contienen operaciones de lectura deben usar la preferencia de primary lectura. Todas las operaciones de una transacción deben dirigirse al mismo miembro.

Tenga en cuenta los siguientes puntos al usar las etapas $merge o $out en un pipeline de agregación:

  • A partir de MongoDB 5.0, los pipelines con una etapa $merge pueden ejecutarse en nodos secundarios del set de réplicas si todos los nodos en el clúster tienen la featureCompatibilityVersion establecida en 5.0 o superior, y la preferencia de lectura permite lecturas secundarias.

    • $merge y $out se ejecutan en nodos secundarios, pero las operaciones de escritura se envían al nodo primario.

    • No todas las versiones de los drivers son compatibles con las operaciones $merge enviadas a los nodos secundarios. Para obtener más detalles, consulte la documentación del driver.

  • En versiones anteriores de MongoDB, los pipelines con etapas de $out o $merge siempre se ejecutan en el nodo primario y no se considera la preferencia de lectura.

Para las operaciones mapReduce, solo las operaciones mapReduce “en línea” que no escriben datos admiten la preferencia de lectura. De lo contrario, las operaciones mapReduce se ejecutan en el nodo primario.

[1](1, 2) En algunas circunstancias, dos nodos en un set de réplicas pueden transitoriamente creer que son el primario, pero como máximo, uno de ellos podrá completar las escrituras con nivel de confirmación de escritura { w: "majority" }. El nodo que puede completar { w: "majority" } escrituras es el primario actual, y el otro nodo es un antiguo primario que aún no ha reconocido su descenso de categoría, típicamente debido a una partición de red. Cuando esto ocurre, los clientes que se conectan al antiguo primario pueden observar la presencia de datos obsoletos a pesar de haber solicitado la preferencia de lectura primary, y las nuevas escrituras en el antiguo primario eventualmente se revertirán.

Volver

Nivel de confirmación de escritura

En esta página