Sincronización de datos de set de réplicas

Para mantener copias actualizadas del conjunto de datos compartidos, los miembros secundarios de un set de réplicas Sincronizar o replicar datos de otros miembros. MongoDB utiliza dos formas de sincronización de datos: la sincronización inicial para completar el conjunto de datos completo en los nuevos miembros y la replicación para aplicar los cambios continuos a todo el conjunto de datos.

Sincronización inicial

La sincronización inicial copia todos los datos de un nodo del set de réplicas a otro nodo. Ver Selección de fuente de sincronización inicial para obtener más información sobre los criterios de selección de la fuente de sincronización inicial.

La local La base de datos almacena los datos del registro de operaciones que utiliza el proceso de sincronización inicial. Asegúrese de que el miembro de destino tenga suficiente espacio en la local base de datos para almacenar los datos del registro de operaciones y completar el proceso de sincronización inicial.

Nota

Durante la sincronización inicial, MongoDB trunca el oplog en el nodo de destino. Este truncamiento del oplog puede afectar procesos, como los flujos de cambios, que dependen de los datos del oplog.

Puedes especificar la fuente de sincronización inicial preferida utilizando el parámetro initialSyncSourceReadPreference. Este parámetro solo puede especificarse al iniciar el mongod.

A partir de MongoDB 5.2, las sincronizaciones iniciales pueden ser lógicas o basadas en copias de archivos.

Nota

Desambiguación de la sincronización inicial basada en la nube

Para implementaciones autogestionadas, la sincronización inicial es el proceso que utiliza MongoDB para añadir un nodo nuevo a un set de réplicas. Esto es diferente de las sincronizaciones iniciales basadas en la nube disponibles en MongoDB Atlas, que aprovechan las capacidades nativas de su proveedor de nube para crear un snapshot de los datos del nodo de origen y su restauración en el nodo nuevo.

Proceso de sincronización inicial lógica

Cuando realizas una sincronización inicial lógica, MongoDB:

Clona todas las bases de datos excepto la base de datos local. Para clonar, el mongod escanea todas las colecciones en cada base de datos de origen e inserta todos los datos en sus propias copias de estas colecciones.
En paralelo con la clonación de datos, mongod construye todos los índices de colección mientras copia todos los documentos de cada colección.
Aplica registros de oplog que se almacenaron en búfer durante la copia de datos.
Aplica todos los cambios al conjunto de datos. Utilizando el oplog de la fuente, el mongod actualiza su conjunto de datos para reflejar el estado actual del set de réplicas.

Importante

Durante los pasos 1 y 2, el mongod recupera los registros oplog recién agregados y los almacena en una colección temporal en la base de datos local. Asegúrate de que el miembro de destino tenga suficiente espacio en disco en la base de datos local para almacenar temporalmente estos registros oplog durante la duración de esta etapa de copia de datos.
Durante los pasos 3 y 4, el nodo de sincronización comprueba la continuidad de las operaciones en el nodo de origen. Si se encuentra una interrupción, reinicia la sincronización inicial desde el principio. Para evitar esto, asegúrese de que el tamaño del registro de operaciones aprovisionado proporcione una ventana de registro de operaciones suficiente para cubrir el tiempo que tardan en completarse los pasos 3 y 4.

Cuando finaliza la sincronización inicial, el nodo pasa de STARTUP2 a SECONDARY.

Para realizar una sincronización inicial, consulte Resincronizar un Nodo de un Set de réplicas autogestionado.

Sincronización inicial basada en la copia de archivos

Disponible solamente en MongoDB Enterprise.

La sincronización inicial basada en la copia de archivos ejecuta el proceso de sincronización inicial al copiar y mover archivos en el sistema de archivos. Este método de sincronización puede ser más rápido que la sincronización inicial lógica.

Importante

La sincronización inicial basada en la copia de archivos puede generar recuentos inexactos

Después de que se complete la sincronización inicial basada en la copia de archivos, si ejecutas el método count() sin un predicado de query, el recuento de documentos devueltos puede ser inexacto.

Un método count sin un predicado de query se ve así: db.<collection>.count().

Para obtener más información, consulta Conteos inexactos sin predicado de query.

Activa la sincronización inicial basada en la copia de archivos

Para habilitar la sincronización inicial basada en la copia de archivos, configura el parámetro initialSyncMethod como fileCopyBased en el nodo de destino para la sincronización inicial. Este parámetro solo se puede establecer al inicio.

Comportamiento

La sincronización inicial basada en la copia de archivos reemplaza la base de datos local del nodo de destino con la base de datos local del nodo de origen al sincronizar.

Limitaciones

Durante una sincronización inicial basada en la copia de archivos:
- No puedes realizar una copia de seguridad en el nodo que está siendo sincronizado hacia o en el nodo que está siendo sincronizado desde.
- No se puede escribir local en la base de datos del miembro que se está sincronizando.
Solo puedes ejecutar una sincronización inicial desde un miembro determinado a la vez.
Cuando se utiliza el motor de almacenamiento cifrado, MongoDB utiliza la clave de origen para cifrar el destino.

Sincronización inicial en clústeres NVMe

Debes realizar una sincronización inicial en clústeres que utilicen la opción local de almacenamiento SSD Non-Volatile Memory Express (NVMe), incluso si estás utilizando el escalado automático de Atlas. Los clústeres NVMe de Atlas se escalan automáticamente al siguiente nivel superior cuando el 90 % del espacio de almacenamiento está lleno. Una sincronización inicial tarda más en completarse en comparación con las sincronizaciones posteriores, y reduce el rendimiento del primario desde el cual se leen los datos.

Tolerancia a los fallos

Si un secundario que realiza una sincronización inicial encuentra un no transitorio (es decir, " persistente) error de red durante el proceso de sincronización, el secundario reinicia el proceso de sincronización inicial desde el principio.

Un secundario que realiza la sincronización inicial puede intentar reanudar el proceso de sincronización si se interrumpe por un "transitorio" ("es decir, " error temporal de la red, descarte de la colección o cambio del nombre de la colección.

Por defecto, el secundario intenta reanudar la sincronización inicial durante 24 horas. Puedes usar el parámetro del servidor initialSyncTransientErrorRetryPeriodSeconds para controlar la cantidad de tiempo que el secundario intenta reanudar la sincronización inicial. Si el secundario no puede reanudar con éxito el proceso de sincronización inicial durante el periodo de tiempo configurado, selecciona una nueva fuente saludable del set de réplicas y reinicia el proceso de sincronización inicial desde el principio.

El secundario intenta reiniciar la sincronización inicial hasta 10 veces antes de devolver un error fatal.

Selección de origen para la sincronización inicial

La selección de la fuente de sincronización inicial depende del valor del parámetro de inicio de mongod initialSyncSourceReadPreference:

Para initialSyncSourceReadPreference configurado en primary (por defecto si chaining está desactivado), seleccione el primario como la fuente de sincronización. Si el primario no está disponible o no se puede acceder a él, registra un registro de error y verifica periódicamente la disponibilidad del primario.
Para initialSyncSourceReadPreference configurado en primaryPreferred (por defecto para los miembros de set de réplicas con votación), intenta seleccionar el primario como la fuente de sincronización. Si el primario está fuera de servicio o no se puede localizar, realice la selección de la fuente de sincronización entre los miembros restantes del set de réplicas.
Para todos los demás modos de lectura soportados, realiza la selección síncrona de fuente entre los miembros del set de réplicas.

Los miembros que realizan la selección de origen para la sincronización inicial hacen dos pasadas a través de la lista de todos los miembros del set de réplicas:

El nodo aplica los siguientes criterios a cada set de réplicas al realizar la primera pasada para seleccionar una fuente de sincronización inicial:

La fuente de sincronización debe estar en el estado de replicación PRIMARY o SECONDARY.
La fuente de sincronización debe estar en línea y accesible.
Si initialSyncSourceReadPreference es secondary o secondaryPreferred, la fuente de sincronización debe ser una secundaria.
La fuente de sincronización debe visibleser.
La fuente de sincronización debe estar dentro de 30 segundos de la entrada más nueva en el oplog del servidor principal.
Si el nodo builds indexes, la fuente de sincronización debe crear los índices.
Si el nodo votes en las elecciones del set de réplicas vota, la fuente de sincronizar debe votar también.
Si el miembro no delayed memberes un, la fuente de sincronización no debe retrasarse.
Si el nodo es un delayed member, la fuente de sincronización debe tener un retraso configurado más corto.
La fuente de sincronizar debe ser más rápida (es decir, menor latencia) que la mejor fuente de sincronización actual.

Si no quedan fuentes de sincronización candidatas después de la primera pasada, el nodo realiza una segunda pasada con criterios menos estrictos. Ver Sync Source Selection (Second Pass).

El nodo aplica los siguientes criterios a cada miembro del conjunto de réplicas al realizar la segunda pasada para seleccionar una fuente de sincronización inicial:

La fuente de sincronización debe estar en el estado de replicación PRIMARY o SECONDARY.
La fuente de sincronización debe estar en línea y accesible.
Si initialSyncSourceReadPreference es secondary, la fuente de sincronización debe ser un secundario.
Si el nodo builds indexes, la fuente de sincronización debe crear índices.
La fuente de sincronizar debe ser más rápida (es decir, menor latencia) que la mejor fuente de sincronización actual.

Si el nodo no puede seleccionar una fuente de sincronización inicial después de dos pasadas, registra un error y espera 1 segundos antes de reiniciar el proceso de selección. El secundario mongod puede reiniciar el proceso de selección de la fuente de sincronización inicial hasta 10 veces antes de salir con un error.

Oplog window

La ventana de oplog debe ser lo bastante larga como para que un secundario pueda obtener todos los registros nuevos de oplog que ocurran entre el inicio y el final del proceso lógico de sincronización inicial. Si la ventana no es lo suficientemente larga, existe el riesgo de que algunas entradas puedan eliminarse de la oplog antes de que la réplica secundaria pueda aplicarlas.

Se recomienda que dimensione el oplog para disponer de tiempo adicional para obtener nuevas entradas de oplog. Esto permite cambios que puedan ocurrir durante las sincronizaciones iniciales.

Para obtener más información, consulta Tamaño de oplog.

Replicación

Los miembros secundarios replican datos continuamente después de la sincronización inicial. Copian el registro de operaciones de su sincronización de origen y aplican estas operaciones de forma asincrónica. [1]

Los secundarios pueden cambiar automáticamente su origen de sincronización según sea necesario, en función de los cambios en el tiempo de ping y el estado de la replicación de otros nodos. Consulta Selección de fuente de sincronización de replicación para obtener más información sobre los criterios de selección de fuente de sincronización.

[1]

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 REPL con el texto applied 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.

Replicación de streaming

Las fuentes de Sincronizar desde envían un flujo continuo de entradas de oplog a sus secundarios de sincronización. La replicación de streaming mitiga el atraso de la replicación en redes de alta carga y alta latencia. También:

Reduce la obsolescencia de las lecturas de los secundarios.
Reduce el riesgo de perder operaciones de guardado con w: 1 debido a la conmutación por error del primario.
Reduce la latencia en las operaciones de guardado con w: "majority" y w: >1 (es decir, cualquier nivel de confirmación de escritura (write concern) que requiera esperar la replicación).

Usa el parámetro de inicio oplogFetcherUsesExhaust para desactivar la replicación de streaming y utilizar el comportamiento de replicación anterior. Configura el parámetro oplogFetcherUsesExhaust en false solo si existen limitaciones de recursos en la fuente de sincronizar desde o si deseas limitar el uso del ancho de banda de red por parte de MongoDB para la replicación.

Replicación multihilo

MongoDB aplica operaciones de guardado en lotes utilizando múltiples hilos para mejorar la concurrencia. MongoDB agrupa lotes por ID de documento (WiredTiger) y aplica simultáneamente cada grupo de operaciones utilizando un hilo diferente. MongoDB siempre aplica las operaciones de guardado a un documento determinado en su orden de guardado original.

Las operaciones de lectura que apuntan a las secundarias y están configuradas con un nivel de consistencia de lectura de "local" o "majority" leen de un WiredTiger snapshot de los datos si la lectura se realiza en un secundario en que se están aplicando lotes de replicación.

La lectura de un snapshot garantiza una vista coherente de los datos y permite que la lectura ocurra simultáneamente con la replicación en curso sin necesidad de un bloqueo. Como resultado, las lecturas secundarias que requieren estos niveles de consistencia de lectura ya no necesitan esperar a que se apliquen los lotes de replicación y se pueden manejar a medida que se reciben.

Control de flujo

A partir de MongoDB 4.2, los administradores pueden limitar la velocidad a la que el servidor principal aplica sus escrituras con el objetivo de mantener el retraso por debajo de un valor majority committed máximo flowControlTargetLagSeconds configurable.

Por defecto, el control de flujo es enabled.

Para obtener más información, consulta Control de flujo.

Selección de la fuente de sincronización de replicación

La selección de la fuente de sincronización de replicación depende de la configuración del chaining del set de réplicas:

Con el encadenamiento habilitado (por defecto), realiza la selección de la fuente sincronizada entre los miembros del set de réplicas.
Con el encadenamiento deshabilitado, seleccione el servidor principal como fuente de sincronización. Si el servidor principal no está disponible o no se puede acceder a él, registre un error y compruebe periódicamente su disponibilidad.

Los miembros que realizan la selección de origen de sincronización de replicación realizan dos pasadas por la lista de todos los miembros del conjunto de réplicas:

El miembro aplica los siguientes criterios a cada set de réplicas al realizar la primera pasada para seleccionar una fuente de sincronización de replicación:

La fuente de sincronización debe estar en el estado de replicación PRIMARY o SECONDARY.
La fuente de sincronización debe estar en línea y accesible.
La fuente de sincronización debe tener entradas de oplog más recientes que el nodo (es decir, la fuente de sincronización está adelantada con respecto al nodo).
La fuente de sincronización debe visibleser.
La fuente de sincronización debe estar dentro de 30 segundos de la entrada más nueva en el oplog del servidor principal.
Si el nodo builds indexes, la fuente de sincronización debe crear los índices.
Si el nodo votes en las elecciones del set de réplicas vota, la fuente de sincronizar debe votar también.
Si el miembro no delayed memberes un, la fuente de sincronización no debe retrasarse.
Si el nodo es un delayed member, la fuente de sincronización debe tener un retraso configurado más corto.
La fuente de sincronizar debe ser más rápida (es decir, menor latencia) que la mejor fuente de sincronización actual.

Si no quedan fuentes de sincronización candidatas tras la primera pasada, el miembro realiza una segunda pasada con criterios más flexibles. Consulte Sync Source Selection (Second Pass).

El nodo aplica los siguientes criterios a cada miembro del conjunto de réplicas al realizar la segunda pasada para seleccionar una fuente de sincronización de replicación:

La fuente de sincronización debe estar en el estado de replicación PRIMARY o SECONDARY.
La fuente de sincronización debe estar en línea y accesible.
Si el nodo builds indexes, la fuente de sincronización debe crear índices.
La fuente de sincronizar debe ser más rápida (es decir, menor latencia) que la mejor fuente de sincronización actual.

Si el nodo no puede seleccionar una fuente para sincronizar después de dos intentos, registra un error y espera 1 segundo antes de reiniciar el proceso de selección.

El número de veces que se puede cambiar una fuente por hora es configurable configurando el parámetro maxNumSyncSourceChangesPerHour.

Nota

El parámetro de inicio initialSyncSourceReadPreference prevalece sobre la configuración settings.chainingAllowed del set de réplicas al seleccionar una sincronización inicial. Después de que un miembro de un set de réplicas haya realizado con éxito la sincronización inicial, se remite al valor de chainingAllowed al seleccionar una fuente de sincronización de replicación.

Consulta Selección de fuente de sincronización inicial para obtener más detalles sobre la selección de la fuente de sincronización inicial.

Volver

Oplog

Nodos del set de réplicas