preferencia de lectura

Modos de preferencia de lectura

En la siguiente tabla, se resumen los modos de preferencia de lectura:

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

Comportamiento

• 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.

Modos de preferencia de lectura

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.

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.

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.

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.

Configurar la preferencia de lectura

Al usar un driver de MongoDB, puede especificar la preferencia de lectura mediante la API de preferencia de lectura del driver. Consulte la documentación de la API del driver. También puede establecer la preferencia de lectura cuando se conecte al set de réplicas o al clúster particionado. Para ver un ejemplo, consulte 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().

Preferencia de lectura y transacciones

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.

Consideraciones adicionales

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.