Un conjunto de réplicas en MongoDB es un grupo de mongodprocesos que mantienen el mismo conjunto de datos. Los conjuntos de réplicas proporcionan redundancia y alta disponibilidad, y son la base de todas las implementaciones de producción. Esta sección presenta la replicación en MongoDB, así como los componentes y la arquitectura de los conjuntos de réplicas. También incluye tutoriales para tareas comunes relacionadas con los conjuntos de réplicas.
Puede Implementar un conjunto de réplicas en la interfaz de usuario para implementaciones alojadas en MongoDB Atlas.
Redundancia y disponibilidad de datos
La replicación proporciona redundancia y aumenta la disponibilidad de datos. Con múltiples copias de datos en diferentes servidores de bases de datos, la replicación proporciona un nivel de tolerancia a fallos contra la pérdida de un solo servidor de bases de datos.
En algunos casos, la replicación puede ofrecer una mayor capacidad de lectura, ya que los clientes pueden enviar operaciones de lectura a diferentes servidores. Mantener copias de datos en diferentes centros de datos puede aumentar la localización y disponibilidad de datos para aplicaciones distribuidas. También se pueden mantener copias adicionales para fines específicos, como la recuperación ante desastres, la elaboración de reportes o copias de seguridad.
Replicación en MongoDB
Un set de réplicas es un grupo de mongod instancias que mantienen el mismo conjunto de datos. Un set de réplicas contiene varios nodos que almacenan datos y opcionalmente un nodo árbitro. De los nodos que contienen datos, un solo nodo y no más se considera el nodo primario, mientras que los otros nodos se consideran nodos secundarios.
Advertencia
Cada nodo de set de réplicas debe pertenecer a un único set de réplicas. Los nodos de un set de réplicas no pueden pertenecer a más de un set de réplicas.
El nodo primario recibe todas las operaciones de escritura. Un set de réplicas solo puede tener una instancia primaria capaz de confirmar escrituras con { w: "majority" } nivel de confirmación de escritura (write concern); aunque en algunas circunstancias, otra instancia de mongod puede creer transitoriamente que también es primaria. [1] El primario registra todos los cambios en sus conjuntos de datos en su operation log, es decir, oplog. Para obtener más información sobre la operación del nodo primario, consulte set de réplicas primario.
Los secundarios replican el oplog del primario y aplican las operaciones a sus conjuntos de datos de tal manera que los conjuntos de datos de los secundarios reflejen el conjunto de datos del primario. Si el primario no está disponible, un secundario elegible llevará a cabo una elección para elegirse como el nuevo primario. Para obtener más información sobre los miembros secundarios, consultar Miembros secundarios del set de réplicas.
En algunas circunstancias (como si tienes una primaria y una secundaria pero las restricciones de costo impiden añadir otra secundaria), puedes optar por añadir una mongod instancia a un set de réplicas como árbitro. Un árbitro participa en elecciones pero no almacena datos (es decir, no proporciona redundancia de datos). Para obtener más información sobre los árbitros, consulta árbitro de set de réplicas.
Un árbitro siempre será un árbitro, mientras que un nodo primario puede retirarse y convertirse en un nodo secundario, y un nodo secundario puede convertirse en el nodo primario durante una elección.
Replicación asíncrona
Los secundarios replican el oplog del primario y aplican las operaciones a sus conjuntos de datos de manera asincrónica. Al hacer que los conjuntos de datos de los secundarios reflejen el conjunto de datos de la primaria, el set de réplicas puede seguir funcionando a pesar de la falla de uno o más miembros.
Para obtener más información sobre la mecánica de la replicación, consulta Oplog del set de réplicas y Sincronización de datos del set de réplicas.
Operaciones lentas
Los miembros secundarios de un set de réplicas ahora registran entradas de oplog que tardan más que el umbral de una operación lenta en aplicarse. Estos mensajes lentos del oplog:
Se registran para los secundarios en el
diagnostic log.Se documentan en el registro bajo el componente
REPLcon el textoapplied op: <oplog entry> took <num>ms.No depende de los niveles de registro (ya sea a nivel del sistema o del componente)
No depende del nivel de perfil.
Se ven afectados por
slowOpSampleRate.
El perfilador no captura entradas lentas del oplog.
Atraso de la replicación y control de flujo
Atraso de la replicación es un retraso entre una operación en el primario y la aplicación de esa operación desde el oplog al secundario. Un pequeño período de retraso puede ser aceptable, pero surgen problemas significativos a medida que crece el atraso de la replicación, incluyendo la acumulación de presión en la caché del primario.
Los administradores pueden limitar la tasa a la que el primario aplica sus guardados con el objetivo de mantener el retraso de majority
committed por debajo de un valor máximo configurable flowControlTargetLagSeconds.
Por defecto, el control de flujo es enabled.
Con el control de flujo habilitado, a medida que el retraso se acerca a flowControlTargetLagSeconds, las escrituras en el primario deben obtener tickets antes de tomar bloqueos para aplicar las escrituras. Al limitar el número de tickets emitidos por segundo, el mecanismo de control de flujo intenta mantener el retraso por debajo del objetivo.
Para obtener más información, consultar Comprobar el atraso de la replicación y Control de flujo.
Conmutación por error automática
Cuando un primario no se comunica con los otros nodos del conjunto durante más tiempo que el período electionTimeoutMillis configurado (10 segundos por defecto), un secundario elegible convoca una elección para nominarse como el nuevo primario. El clúster intenta completar la elección de un nuevo primario y reanudar las operaciones normales.
El set de réplicas no puede procesar operaciones de guardar hasta que la elección se complete con éxito. El set de réplicas puede seguir sirviendo los query de lectura si dichos query están configurados para ejecutarse en los secundarios mientras el primario está desconectado.
La mediana de tiempo antes de que un clúster elija un nuevo primario no debería superar típicamente los 12 segundos, asumiendo el replica
configuration settings por defecto. Esto incluye el tiempo necesario para marcar el primario como no disponible y llamar y completar una elección. Puede ajustar este periodo de tiempo modificando la settings.electionTimeoutMillis opción de configuración de la replicación. Factores como la latencia de la red pueden extender el tiempo necesario para completar la elección de set de réplicas, lo que a su vez afecta la cantidad de tiempo que el clúster puede operar sin un primario. Estos factores dependen de la arquitectura particular del clúster.
Reducir la opción de configuración de electionTimeoutMillis de replicación desde el valor por defecto 10000 (10 segundos) puede causar una detección más rápida de una falla primaria. Sin embargo, el clúster puede llamar a elecciones con más frecuencia debido a factores como la latencia temporal de la red, incluso si el primario está por lo demás en buen estado. Esto puede ocasionar un aumento de los rollbacks para las operaciones de guardar : 1.
La lógica de conexión de la aplicación debe incluir tolerancia para las conmutaciones por error automáticas y las elecciones posteriores. Los controladores de MongoDB pueden detectar la pérdida del nodo principal y reintentar automáticamente ciertas operaciones de guardado una sola vez, proporcionando un manejo adicional incorporado para conmutaciones por error automáticas y elecciones:
Los controladores compatibles habilitan las Escrituras reintentables por defecto
MongoDB proporciona lecturas espejeadas para precalentar la caché de los nodos secundarios elegibles con los datos a los que se ha accedido más recientemente. Precalentar la caché de un nodo secundario puede ayudar a restaurar el rendimiento más rápidamente después de una elección.
Para obtener más información sobre el proceso de failover de MongoDB, consulta:
Operaciones de lectura
preferencia de lectura
Por defecto, los clientes leen del primario [1]; sin embargo, los clientes pueden especificar una preferencia de lectura para enviar operaciones de lectura a los secundarios.
La replicación asíncrona a los secundarios significa que las lecturas de los secundarios pueden devolver datos que no reflejan el estado de los datos en el 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.
Para obtener información sobre la lectura de Set de réplicas, consulta Preferencia de lectura.
Visibilidad de los datos
Dependiendo del nivel de consistencia de lectura, los clientes pueden ver los resultados de las escrituras antes de que las escrituras sean duraderas:
Independientemente del nivel de confirmación de escritura (write concern) de una escritura, otros clientes que utilicen el nivel de consistencia de lectura
"local"o"available"pueden ver el resultado de una operación de escritura antes de que el cliente emisor acuse recibo de la operación de escritura.Los clientes que utilizan
"local"o"available"como nivel de consistencia de lectura pueden leer datos que pueden ser posteriormente revertidos durante las conmutaciones por error del set de réplicas.
Para las operaciones en una transacción multi-documento, cuando una transacción se confirma, todos los cambios de datos realizados en la transacción se guardan y son visibles fuera de la transacción. Es decir, una transacción no realizará la confirmación de algunos de sus cambios mientras revierte otros.
Hasta que se produzca la confirmación de una transacción, los cambios de datos realizados en la transacción no son visibles fuera de la transacción.
Sin embargo, cuando una transacción se guarda en múltiples fragmentos, no todas las operaciones de lectura externas necesitan esperar a que el resultado de la transacción confirmada sea visible en todos los fragmentos. Por ejemplo, si se confirma una transacción y la escritura 1 es visible en el fragmento A, pero la escritura 2 aún no es visible en el fragmento B, una lectura externa con el nivel de consistencia de lectura "local" puede leer los resultados de la escritura 1 sin ver la escritura 2.
Para obtener más información sobre los aislamientos de lectura, la coherencia y la recencia para MongoDB, consultar Aislamiento de lectura, coherencia y recencia.
Lecturas espejeadas
Las lecturas espejeadas reducen el impacto de las elecciones primarias tras una interrupción del servicio o un mantenimiento planificado. Tras una conmutación por error en un set de réplicas, el secundario que pasa a ser el nuevo primario actualiza su caché a medida que llegan nuevos query. Mientras la caché se calienta, el rendimiento puede verse afectado.
Las lecturas espejeadas precalientan los cachés de los miembros secundarios del electable set de réplicas. Para precalentar las cachés de secundarias elegibles, el primario refleja una muestra de las operaciones admitidas que recibe a secundarias elegibles.
El tamaño del subconjunto de los nodos secundarios del set de réplicas electable que reciben lecturas espejeadas se puede configurar con el parámetro mirrorReads. Consulta Activa o desactiva el soporte para lecturas espejeadas para obtener más detalles.
Nota
Las lecturas espejeadas no afectan la respuesta del primario al cliente. Las lecturas de los espejos primarios a los secundarios son operaciones de "disparar y olvidar". El nodo primario no espera respuestas.
Lecturas espejeadas dirigidas
A partir de MongoDB 8.2, se pueden reflejar selectivamente las operaciones de lectura en servidores específicos que necesitan calentar sus cachés etiquetando los nodos para las lecturas espejeadas. A diferencia de las lecturas espejeadas generales, la duplicación de lectura dirigida permite dirigirse a nodos ocultos y reflejar desde nodos tanto primarios como secundarios.
Puedes configurar lecturas espejeadas dirigidas utilizando el campo targetedMirroring en el parámetro mirrorReads.
Operaciones compatibles
Las lecturas espejeadas admiten las siguientes operaciones:
findAndModify(Concretamente, el filtro se envía como una lectura espejeada)update(Concretamente, el filtro se envía como una lectura espejeada)
Habilitar/deshabilitar soporte para lecturas espejeadas
Las lecturas espejeadas están habilitadas por defecto y utilizan un sampling rate por defecto de 0.01. Para desactivar las lecturas espejeadas, configure el parámetro mirrorReads en {
samplingRate: 0.0 }:
db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.0 } } )
Con una tasa de muestreo mayor que 0.0, los espejos primarios admiten lecturas a un subconjunto de electable secundarios. Con una tasa de muestreo de 0.01, el primario refleja el uno por ciento de las lecturas soportadas que recibe a una selección de secundarios elegibles.
Por ejemplo, un set de réplicas que consta de un primario y dos secundarios elegibles. Si el primario recibe 1000 operaciones que se pueden reflejar y la tasa de muestreo es 0.01, el primario refleja alrededor de 10 lecturas compatibles a las secundarias elegibles. Cada secundario elegible recibe solo una fracción de las 10 lecturas. El primario envía cada lectura espejeada a una selección aleatoria y no vacía de secundarios elegibles.
Cambiar la tasa de muestreo para las lecturas espejeadas
Para cambiar la tasa de muestreo de las lecturas espejeadas, configura el parámetro mirrorReads a un número entre 0.0 y 1.0:
Una tasa de muestreo de
0.0desactiva las lecturas espejeadas.Una tasa de muestreo de un número entre
0.0y1.0hace que el primario reenvíe una muestra aleatoria de las lecturas admitidas a la tasa de muestreo especificada a los secundarios elegibles.Una tasa de muestras de
1.0hace que el primario reenvíe todas las lecturas compatibles a los secundarios elegibles.
Para obtener más detalles, consulte mirrorReads.
Métricas de lecturas espejeadas
El comando serverStatus y el método de shell db.serverStatus() devuelven métricas mirroredReads si se especifica el campo en la operación:
db.serverStatus( { mirroredReads: 1 } )
Transacciones
Las transacciones multi-documento están disponibles para sets de réplicas.
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.
Hasta que se produzca la confirmación de una transacción, los cambios de datos realizados en la transacción no son visibles fuera de la transacción.
Sin embargo, cuando una transacción se guarda en múltiples fragmentos, no todas las operaciones de lectura externas necesitan esperar a que el resultado de la transacción confirmada sea visible en todos los fragmentos. Por ejemplo, si se confirma una transacción y la escritura 1 es visible en el fragmento A, pero la escritura 2 aún no es visible en el fragmento B, una lectura externa con el nivel de consistencia de lectura "local" puede leer los resultados de la escritura 1 sin ver la escritura 2.
Flujos de cambio
Los flujos de cambios están disponibles para sets de réplicas y clústeres particionados. Los flujos de cambios permiten a las aplicaciones acceder a los cambios de datos en tiempo real sin la complejidad ni el riesgo de seguir el oplog. Las aplicaciones pueden usar flujos de cambios para suscribirse a todos los cambios de datos en una o varias colecciones.
Características adicionales
Los conjuntos de réplicas ofrecen varias opciones para satisfacer las necesidades de las aplicaciones. Por ejemplo, puede implementar un set de réplicas con miembros en múltiples centros de datos, o controlar el resultado de las elecciones ajustando el members[n].priority de algunos miembros. Los sets de réplicas también admiten miembros dedicados a funciones de reportes, recuperación ante desastres o copia de seguridad.
Consulta Miembros de prioridad 0 del set de réplicas, Miembros ocultos del set de réplicas y Miembros retrasados del set de réplicas para obtener más información.
| [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 operaciones de guardar con { w:
"majority" } nivel de confirmación de escritura (write concern). El nodo que puede completar { w: "majority" } escrituras es el primario actual, y el otro nodo es un primario anterior que aún no ha reconocido su degradación, típicamente debido a una partición de red. Cuando esto ocurre, los clientes que se conectan al antiguo primario pueden observar datos obsoletos a pesar de haber solicitado la preferencia de lectura primary, y las nuevas escrituras en el antiguo primario finalmente se revertirán. |