MongoDB
Explica cómo read preference selecciona primary o secondaries, sus modos, tags y trade-offs de consistencia, latencia y distribución de carga.
Read preference determina qué miembros de un replica set pueden atender una lectura. No define qué estado es visible —eso pertenece a read concern— y tampoco garantiza que leer de secondaries mejore rendimiento.
read preference
→ primary o secondaries elegibles
read concern
→ garantía de visibilidadTodas las lecturas van al primary. Es el valor más sencillo para operaciones read-after-write y evita staleness causado por replication lag.
Prefiere primary y usa secondary si el primary no está disponible. Puede cambiar la frescura durante incidentes, por lo que la aplicación debe tolerar esa degradación.
Solo utiliza secondaries elegibles. Si ninguno está disponible, la operación falla aunque el primary esté saludable.
Prefiere secondaries y usa primary como fallback. Es común en analytics tolerante a retraso, pero debe medirse.
Selecciona miembros elegibles basándose en la ventana de latencia observada, no en distancia geográfica literal ni en frescura. Puede elegir un secondary atrasado.
const reports = db.collection('orders').withReadPreference('secondaryPreferred');
const cursor = reports.find({
businessId,
confirmedAt: { $gte: start, $lt: end }
});La API exacta depende de la versión del driver y del nivel donde se configure: cliente, database, collection, session u operación.
Los secondaries aplican el oplog de forma asíncrona.
write confirmado en primary
→ secondary todavía no lo aplica
→ lectura secondary devuelve versión anteriorreadConcern: 'majority' evita datos no majority-committed, pero no hace que un secondary alcance inmediatamente al primary.
Flujo problemático:
crear orden en primary
→ leer con secondaryPreferred
→ orden no aparece todavíaOpciones:
_id con una política más estricta.Los replica set members pueden tener tags. Una read preference puede seleccionar nodos por región o función:
{
mode: 'secondary',
tagSets: [
{ region: 'south-america' }
]
}Esto sirve para localidad o reporting, pero una región completa puede quedar sin miembros elegibles. Diseña fallbacks y prueba fallos.
Opciones de max staleness permiten descartar secondaries demasiado atrasados bajo restricciones y mínimos dependientes de versión. No sustituyen monitoreo del lag ni garantizan cero staleness.
Mover reportes a secondaries puede proteger parcialmente el primary, pero también:
Para analytics pesado considera una réplica dedicada, data lake o colección materializada.
Las transacciones tienen restricciones sobre read preference; normalmente necesitan primary. Verifica driver y servidor antes de configurar preferencias globales que interfieran con sesiones transaccionales.
El driver mantiene una descripción de topología y selecciona servidores dentro de una latency window. “Nearest” no garantiza siempre el nodo con menor tiempo de respuesta para cada request ni considera carga de la query.
primary suele ser la opción segura.
secondaryPreferred puede ser aceptable si se documenta staleness.
Puede dirigirse a un secondary apropiado para reducir impacto, pero debe conservar consistencia y capacidad de replicación.
Evita datos atrasados cuando puedan permitir o denegar acciones incorrectamente.
primary produce error.primaryPreferred cambia de semántica durante failover.secondary falla si no hay secondary elegible.Read preference es routing, no una garantía de consistencia ni una optimización automática. Secondaries pueden descargar algunas lecturas, pero añaden staleness y carga operacional. El modo debe elegirse por caso de uso, junto con read concern, sessions, topología y tolerancia a fallos.
Sessions y causal consistency.