Docs Menu
Docs Home
/ /

Sincronización de datos de set de réplicas

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

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

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

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

  1. Clona todas las bases de datos, excepto la base de datos local. Para clonar, mongod escanea cada colección en cada base de datos de nodos de origen e inserta todos los datos en sus propias copias de estas colecciones.

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

  3. Aplica registros de oplog que se almacenaron en búfer durante la copia de datos.

  4. Aplica todos los cambios al conjunto de datos. Con oplog del nodo de origen, mongod actualiza su conjunto de datos para reflejar el estado actual del Set de réplicas.

Importante

  • Durante los pasos 1 y 2, mongod extrae los registros de oplog recién añadidos y los almacena en una colección temporal en la base de datos local. Asegúrese de que el miembro de destino tenga suficiente espacio en disco en la base de datos local para almacenar temporalmente estos registros de oplog durante 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.

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.

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.

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.

  • Durante una sincronización inicial basada en la copia de archivos:

    • No puedes ejecutar copias de seguridad ni en el nodo de origen o de destino.

    • No puedes guardar en la base de datos local en el nodo de destino.

  • Solo puede ejecutar una sincronización inicial desde un nodo de origen a la vez.

  • Cuando se utiliza el motor de almacenamiento cifrado, MongoDB utiliza la clave del nodo de origen para cifrar el destino.

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.

Si un nodo de destino que realiza una sincronización inicial encuentra un error de red persistente durante el proceso de sincronización, el nodo de destino reinicia el proceso de sincronización inicial desde el principio.

Un nodo de destino que realiza la sincronización inicial puede intentar reanudar el proceso de sincronización si se interrumpe por un error temporal de red, un descarte de la colección o un cambio del nombre de la colección.

Por defecto, el nodo de destino intenta reanudar la sincronización inicial durante 24 horas. Puedes utilizar el parámetro de servidor initialSyncTransientErrorRetryPeriodSeconds para controlar la cantidad de tiempo que el nodo de destino intenta reanudar la sincronización inicial. Si el nodo de destino no puede reanudar con éxito el proceso de sincronización inicial durante el período de tiempo configurado, selecciona un nuevo nodo de origen en buen estado 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.

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 chainingAllowed está deshabilitado), selecciona el primario como el nodo de origen. Si el primario no está disponible o no se puede acceder, registra un error y verifica periódicamente la disponibilidad del primario.

  • Para initialSyncSourceReadPreference configurado en primaryPreferred (por defecto para los nodos votantes del set de réplicas), intenta seleccionar el primario como el nodo de origen. Si el primario no está disponible o no se puede acceder, realice la selección de nodos de origen para sincronizar de los nodos restantes del set de réplicas.

  • Para todos los demás modos de lectura admitidos, realiza la selección de miembros de origen para sincronizar desde los miembros de destino.

Los miembros que realizan la selección inicial de nodos de origen hacen dos recorridos por la lista de todos los nodos del set de réplicas:

El nodo aplica los siguientes criterios a cada nodo del set de réplicas al hacer la primera pasada para seleccionar un nodo de origen inicial:

  • El nodo de origen debe estar en el estado de PRIMARY o SECONDARY de replicación.

  • El nodo de origen debe estar en línea y ser accesible.

  • Si initialSyncSourceReadPreference es secondary o secondaryPreferred, el nodo de origen debe ser un secundario.

  • El nodo de origen debe ser visible.

  • El nodo de origen debe estar dentro de 30 segundos de la entrada de oplog más reciente en el primario.

  • Si el nodo builds indexes, el nodo de origen debe crear índices.

  • Si el nodo votes participa en las elecciones del set de réplicas, el nodo de origen debe votar también.

  • Si el nodo no es un delayed member, el nodo de origen no debe retrasarse.

  • Si el nodo es un delayed member, el nodo de origen debe tener un retraso configurado más breve.

  • El nodo de origen debe ser más rápido que la fuente de sincronización actual más rápida.

Si no queda ningún nodo candidato de origen después de la primera pasada, el nodo realiza una segunda pasada con criterios más relajados. Ver Sync Source Selection (Second Pass).

El nodo aplica los siguientes criterios a cada set de réplicas al realizar la segunda pasada para seleccionar un nodo de origen inicial:

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

La oplog window debe ser lo suficientemente larga para que un nodo de destino pueda recuperar cualquier nueva entrada de oplog que ocurra entre el inicio y el final del proceso de sincronización inicial lógica. Si la ventana no es lo suficientemente larga, existe el riesgo de que algunas entradas se pierdan del oplog antes de que el nodo de destino 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.

Los nodos de destino replican datos de manera continua después de la sincronización inicial. Los nodos de destino copian el oplog del nodo de origen y aplican estas operaciones en un proceso asíncrono.

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

Los nodos de origen envían un flujo continuo de entradas de oplog a sus miembros de destino. 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).

Utiliza el parámetro de inicio oplogFetcherUsesExhaust para desactivar la replicación de streaming y el uso del comportamiento de replicación más antiguo. Establece el parámetro oplogFetcherUsesExhaust en false solo si hay alguna restricción de recursos en el nodo de origen o si desea limitar el uso del ancho de banda de la red por parte de MongoDB para la replicación.

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.

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.

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

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

  • Con el encadenamiento habilitado (por defecto), realiza la selección de nodos de origen a partir de los nodos de destino.

  • Con el encadenamiento desactivado, selecciona el primario como nodo de origen. Si el primario no está disponible o no se puede acceder, registra un error y verifica periódicamente la disponibilidad del primario.

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

El nodo aplica los siguientes criterios a cada nodo del set de réplicas al realizar la primera pasada para seleccionar un nodo de origen:

  • El nodo de origen debe estar en el estado de PRIMARY o SECONDARY de replicación.

  • El nodo de origen debe estar en línea y ser accesible.

  • El nodo de origen debe tener entradas de oplog más recientes que el nodo. Es decir, el nodo de origen debe estar por delante del nodo.

  • El nodo de origen debe ser visible.

  • El nodo de origen debe estar dentro de 30 segundos de la entrada de oplog más reciente en el primario.

  • Si el nodo builds indexes, el nodo de origen debe crear índices.

  • Si el nodo votes participa en las elecciones del set de réplicas, el nodo de origen debe votar también.

  • Si el nodo no es un delayed member, el nodo de origen no debe retrasarse.

  • Si el nodo es un delayed member, el nodo de origen debe tener un retraso configurado más breve.

  • El nodo de origen debe ser más rápido que la fuente de sincronización actual más rápida.

Si no quedan nodos de origen candidatos después de la primera pasada, el nodo realiza una segunda pasada con criterios relajados. Consulta Sync Source Selection (Second Pass).

El nodo aplica los siguientes criterios a cada nodo del set de réplicas al realizar la segunda pasada para seleccionar un nodo de origen:

  • El nodo de origen debe estar en el estado de PRIMARY o SECONDARY de replicación.

  • El nodo de origen debe estar en línea y ser accesible.

  • Si el nodo builds indexes, el nodo de origen debe crear índices.

  • El nodo de origen debe ser más rápido que la fuente de sincronización actual más rápida.

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 un nodo de origen se puede cambiar por hora es configurable mediante el ajuste del parámetro maxNumSyncSourceChangesPerHour.

Nota

El parámetro de inicio initialSyncSourceReadPreference tiene prioridad sobre la configuración del set de réplicas settings.chainingAllowed al seleccionar un nodo de origen de sincronización inicial. Después de que un set de réplicas realiza con éxito la sincronización inicial, se remite al valor de chainingAllowed al seleccionar un nodo de origen.

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

En esta página