El siguiente documento explica los casos de uso comunes de diversos
modos de preferencia de lectura, así como
contraindicaciones que indican cuándo no se debe cambiar la preferencia de lectura respecto al valor por defecto primary.
Modos de preferencia de lectura
Modo de preferencia de lectura | Descripción |
|---|---|
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 | |
Todas las operaciones leen de los miembros secundarios del set de réplicas. La preferencia de lectura | |
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 | |
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 |
Indicaciones para usar 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,
mongodcomo secundaria.Proporcionar lecturas locales para aplicaciones distribuidas geográficamente.
Si tiene servidores de aplicaciones en múltiples centros de datos, puede que considere tener un conjunto de réplicas distribuidas geográficamente y usar una preferencia de lectura no principal o
nearest. Esto permite que el cliente lea de los nodos con la menor latencia, en lugar de leer siempre del primario.Mantener la disponibilidad durante una conmutación por error.
Utilice si desea que una aplicación lea desde
primaryPreferredel 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 utilice secondary y secondaryPreferred para proporcionar capacidad adicional para lecturas, 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 asíncrona y hay cierto grado de retraso entre una operación de escritura exitosa y su replicación a los secundarios. La lectura de un secundario puede devolver datos obsoletos; leer de diferentes secundarias puede resultar en lecturas no monótonas.
Nota
Los clientes pueden utilizar sesiones de cliente y garantías de coherencia causal para asegurar lecturas monótonas.
Distribuir las operaciones de lectura a secundarios puede comprometer la disponibilidad si algún nodo del conjunto queda indisponible, ya que los nodos restantes del conjunto deberán poder gestionar todas las solicitudes de la aplicación.
El particionado aumenta la capacidad de lectura y escritura distribuyendo las operaciones de lectura y escritura en un grupo de máquinas, y a menudo es una mejor estrategia para aumentar la capacidad.
Consulta Algoritmo de selección del servidor para obtener más información sobre la aplicación interna de las preferencias de lectura.
Maximizar la consistencia
Para evitar lecturas obsoletas, utiliza la preferencia de lectura primary y "majority" readConcern. Si el primario no está disponible, por ejemplo, durante elecciones o cuando la mayoría del set de réplicas no es accesible, las operaciones de lectura que usan la preferencia de lectura primary producen un error o generan una excepción.
En algunas circunstancias, es posible que un set de réplicas tenga temporalmente dos primarios; sin embargo, sólo un primario será capaz de confirmar escrituras con el nivel de confirmación de escritura (write concern) "majority".
Una partición de red parcial puede segregar un primario (
Pantiguo) en una partición con una minoría de los nodos, mientras que el otro lado de la partición contiene una mayoría de nodos. La partición con la mayoría elegirá un nuevo primario (Pnuevo), pero por un breve período, el antiguo primario (Pantiguo) aún podría continuar sirviendo lecturas y guardados, ya que aún no ha detectado que solo puede ver una minoría de nodos en el conjunto de réplicas. Durante este período, si el primario antiguo (Pantiguo) todavía es visible para los clientes como primario, las lecturas de este primario pueden reflejar datos obsoletos.Un primario (
Panterior) puede volverse insensible, lo que desencadenará una elección y se podrá elegir un nuevo primario (Pnuevo), que atenderá lecturas y escrituras. Si el primario que no responde (Pold) comienza a responder nuevamente, por un breve período serán visibles dos primarios. El breve periodo terminará cuandoPantiguo se retire. Sin embargo, durante el breve periodo, los clientes podrían leer del antiguo principalPold, lo que podría proporcionar datos obsoletos.
Para aumentar la coherencia, puedes deshabilitar el failover automático; sin embargo, deshabilitar el failover automático sacrifica disponibilidad.
Maximizar disponibilidad
Para permitir operaciones de lectura cuando sea posible, use primaryPreferred. Cuando haya un primario obtendrás lecturas coherentes [1], pero si no hay un primario aún puedes consultar secundarios. Sin embargo, cuando utilices este modo de lectura, considera la situación descrita en secondary frente a secondaryPreferred.
| [1] | En algunas circunstancias, dos nodos en un set de réplicas pueden creer transitoriamente que son el primario, pero como mucho, solo uno de ellos podrá completar escrituras con { w:
"majority" } nivel de confirmación de escritura (write concern). El nodo que puede completar escrituras { w: "majority" } es el primario actual, y el otro nodo es un primario 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 primario anterior pueden observar datos obsoletos a pesar de haber solicitado la preferencia de lectura primary, y las nuevas escrituras al primario anterior eventualmente se revertirán. |
Reducir la latencia
Para siempre leer desde un nodo de baja latencia, use nearest. El controlador o mongos leerá del nodo más cercano y de aquellos que no se encuentran a más de 15 milisegundos [2] de distancia del nodo más cercano.
nearest no garantiza la coherencia. Si el nodo más cercano a tu servidor de aplicaciones es secundario y tiene un cierto atraso de la replicación, las queries pueden devolver datos obsoletos. nearest sólo refleja la distancia de red y no refleja la carga de I/O o CPU.
| [2] | Este umbral se puede configurar. Consulta localPingThresholdMs para mongos o la documentación del driver para la configuración adecuada. |
Consulta de miembros distribuidos geográficamente
Si los miembros de un set de réplicas están distribuidos geográficamente, puede crear etiquetas de réplicas que reflejen la ubicación de la instancia y luego configurar su aplicación para query a los miembros cercanos.
Por ejemplo, si los miembros de los centros de datos del "este" y del "oeste" están etiquetados {'dc': 'east'} y {'dc': 'west'}, sus servidores de aplicaciones en el centro de datos del este pueden leer de miembros cercanos con la siguiente preferencia de lectura:
db.collection.find().readPref('nearest', [ { 'dc': 'east' } ])
Aunque nearest ya favorece a los nodos con baja latencia de red, incluir la etiqueta hace que la elección sea más predecible.
secondary vs secondaryPreferred
Para consultas específicas dedicadas (por ejemplo, ETL, reporte), puede desplazar la carga de lectura desde la primaria utilizando el modo de preferencia de lectura secondary. Para este caso de uso, el modo secondary es preferible al modo secondaryPreferred porque secondaryPreferred corre el riesgo de la siguiente situación: si todas las réplicas secundarias no están disponibles y tu set de réplicas tiene suficientes árbitros [3] para evitar que la primaria haga el paso hacia abajo, entonces la primaria recibirá todo el tráfico de los clientes. Si el primario no puede gestionar esta carga, las consultas competirán con las escrituras. Por esta razón, utiliza la preferencia de lectura secondary para distribuir estas consultas dedicadas específicas en lugar de secondaryPreferred.
| [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. |