Casos de uso de preferencia de lectura

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

El siguiente documento explica casos de uso comunes para varios modos de preferencia de lectura, así como contraindicaciones que describen cuándo no debe cambiar la preferencia de lectura predeterminada primary.

Modos de preferencia de lectura

Modo de preferencia de lectura	Descripción
`primary`	Modo por defecto. Todas las operaciones se leen del actual set de réplicas primario. Las transacciones distribuidas que contienen operaciones de lectura deben usar la preferencia de lectura `primary`. Todas las operaciones en una transacción dada deben dirigirse al mismo nodo.
`primaryPreferred`	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.
`secondary`	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.
`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. La preferencia de lectura `secondaryPreferred` admite lecturas protegidas en clústeres fragmentados.
`nearest`	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 opción de la cadena de conexión`localThresholdMS` La opción de preferencia de lectura maxStalenessSeconds Cualquier lista de conjuntos de etiquetasespecificada La preferencia de lectura `nearest` admite lecturas cubiertas en clústeres fragmentados y habilita la opción de lectura cubierta de forma predeterminada.

Indicaciones para utilizar la preferencia de lectura no primaria

Los siguientes son casos de uso comunes para utilizarprimary modos de preferencia de lectura distintos de:

Ejecutar operaciones de sistema que no afectan la aplicación front-end.
Nota
Las preferencias de lectura no son relevantes para las conexiones directas a una sola instancia. Sin embargo, para realizar operaciones de lectura en una conexión directa a un miembro secundario de un conjunto de réplicas, debe establecer una preferencia de lectura,mongod como secundaria.
Proporcionar lecturas locales para aplicaciones distribuidas geográficamente.
Si tiene servidores de aplicaciones en varios centros de datos, puede considerar tener un conjunto de réplicas distribuido geográficamente y usar una preferencia de lectura no principal nearest o. Esto permite al cliente leer desde los miembros con menor latencia, en lugar de leer siempre desde el principal.
Mantener la disponibilidad durante una conmutación por error.
Utilice si desea que una aplicación lea desde primaryPreferred el servidor principal en circunstancias normales, pero permita lecturas obsoletas desde los servidores secundarios cuando el servidor principal no esté disponible.

Contraindicaciones para la preferencia de lectura no primaria

En general,no secondary utilice y para proporcionar capacidad adicional para lecturas,secondaryPreferred porque:

Todos los miembros de una réplica tienen un tráfico de escritura aproximadamente equivalente; como resultado, los secundarios atenderán las lecturas aproximadamente a la misma velocidad que los principales.
La replicación es asincrónica y existe un cierto retraso entre una operación de escritura exitosa y su replicación a los secundarios. Leer desde un secundario puede devolver datos obsoletos; leer desde diferentes secundarios puede resultar en lecturas no monótonas.
Nota
Los clientes pueden utilizar sesiones de cliente y garantías de consistencia causal para asegurar lecturas monótonas.
La distribución de operaciones de lectura a los secundarios puede comprometer la disponibilidad si alguno de los miembros del conjunto deja de estar disponible, ya que los miembros restantes del conjunto deberán poder manejar todas las solicitudes de la aplicación.

La fragmentación aumenta la capacidad de lectura y escritura al distribuir las operaciones de lectura y escritura entre un grupo de máquinas y, a menudo, es una mejor estrategia para agregar capacidad.

Consulte Algoritmo de selección de servidor para obtener más información sobre la aplicación interna de las preferencias de lectura.

Maximizar la consistencia

Para evitar lecturas obsoletas, utilice la preferencia de primary lectura "majority" readConcern y. Si la lectura principal no está disponible, por ejemplo, durante elecciones o cuando la mayoría del conjunto de réplicas no es accesible, las operaciones de lectura que utilizan la preferencia de lectura generan un error o una primary excepción.

En algunas circunstancias, es posible que un conjunto de réplicas tenga temporalmente dos primarios; sin embargo, solo uno primario será capaz de confirmar escrituras con la "majority" preocupación de escritura.

Una partición de red parcial puede segregar un servidor principal (P old) en una partición con una minoría de nodos, mientras que el otro lado de la partición contiene la mayoría de los nodos. La partición con la mayoría elegirá un nuevo servidor principal (P new), pero durante un breve periodo, el servidor principal antiguoP ( old) puede seguir realizando operaciones de lectura y escritura, ya que aún no ha detectado que solo puede ver una minoría de nodos en el conjunto de réplicas. Durante este periodo, si el servidor principalP _antiguo ( old) sigue siendo visible para los clientes como servidor principal, las lecturas de este servidor principal pueden reflejar datos obsoletos.
Un servidor principal (P antiguo) puede dejar de responder, lo que activará una elección y se podrá elegir un nuevo servidor principal ( nuevo), que realizaráP lecturas y escrituras. Si el servidor principal que noP responde ( antiguo) vuelve a responder, dos servidores principales estarán visibles durante un breve periodo. Este breve periodo finalizará cuando P _antiguo deje de funcionar. Sin embargo, durante este breve periodo, los clientes podrían leer del servidor principal antiguo P antiguo, lo que puede proporcionar datos obsoletos.

Para aumentar la consistencia, puede deshabilitar la conmutación por error automática; sin embargo, deshabilitar la conmutación por error automática sacrifica la disponibilidad.

Maximizar disponibilidad

Para permitir operaciones de lectura siempre que sea posible, utilice. Si primaryPreferred hay un primario, obtendrá lecturas consistentes [], pero si no1 hay primario, podrá consultar los secundarios. Sin embargo, al usar este modo de lectura, considere la situación descrita en secondary vs..secondaryPreferred

[1] En algunas circunstancias, dos nodos de un conjunto de réplicas pueden creer temporalmente que son el nodo principal, pero como máximo, uno de ellos podrá completar escrituras con un problema { w: "majority" } de escritura de. El nodo que puede completar { w: "majority" } escrituras es el nodo principal actual, y el otro nodo es un nodo principal anterior que aún no ha reconocido su degradación, generalmente debido a una partición de red. Cuando esto ocurre, los clientes que se conectan al nodo principal anterior pueden observar datos obsoletos a pesar de haber solicitado la preferencia de lectura, y las nuevas escrituras en el nodo principal anterior eventualmente se primary revertirán.

Minimizar la latencia

Para leer siempre desde un nodo de baja latencia, usenearest. El controlador omongosleerá desde el miembro más cercano y desde aquellos que estén a no más de 15 milisegundos [2] de distancia del miembro más cercano.

nearest no garantiza la consistencia. Si el miembro más cercano a su servidor de aplicaciones es un secundario con cierto retraso en la replicación, las consultas podrían devolver datos obsoletos. solo refleja la distancia de la red y no la carga de E/S ni de la nearest CPU.

[2]	Este umbral es configurable. Consulte `localPingThresholdMs` para `mongos` o la documentación del controlador para obtener la configuración adecuada.

Consulta de miembros distribuidos geográficamente

Si los miembros de un conjunto de réplicas están distribuidos geográficamente, puede crear etiquetas de réplica que reflejen la ubicación de la instancia y luego configurar su aplicación para consultar a los miembros cercanos.

Por ejemplo, si los miembros de los centros de datos "este" y "oeste" están etiquetados {'dc': 'east'} como {'dc': 'west'} y, sus servidores de aplicaciones en el centro de datos este pueden leer de los miembros cercanos con la siguiente preferencia de lectura:

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

Aunque ya favorece a los miembros con baja latencia de red, incluir la etiqueta hace que la elección sea más nearest predecible.

`secondary` vs `secondaryPreferred`

Para consultas dedicadas específicas (p. ej., ETL, informes), puede transferir la carga de lectura de la consulta principal mediante el secondary modo de preferencia de lectura. En este caso, el secondary modo es preferible al secondaryPreferred modo, ya que presenta el secondaryPreferred riesgo de que se presente la siguiente situación: si ninguna de las consultas secundarias está disponible y su conjunto de réplicas tiene suficientes árbitros3 [] para evitar que la consulta principal se reduzca, esta recibirá todo el tráfico de los clientes. Si la consulta principal no puede gestionar esta carga, las consultas competirán con las escrituras. Por este motivo, utilice la preferencia de lectura secondary para distribuir estas consultas dedicadas específicas en lugar secondaryPreferred de.

[3]	En general, evite implementar árbitros en conjuntos de réplicas y utilice un número impar de nodos que contengan datos. Si debe implementar árbitros, evite implementar más de uno por conjunto de réplicas.

Volver

preferencia de lectura

Conjuntos de etiquetas