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. Consulta 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.
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
Cuando realiza una sincronización inicial, MongoDB:
Clona todas las bases de datos excepto la base de datos local. Para clonar, el
mongodescanea todas las colecciones en cada base de datos de origen e inserta todos los datos en sus propias copias de estas colecciones.Modificado en la versión 3.4: La sincronización inicial crea todos los índices de colección a medida que se copian los documentos de cada colección. En versiones anteriores de MongoDB, solo
_idse creaban los índices durante esta etapa.Modificado en la versión 3.4: La sincronización inicial extrae los registros de oplog recién añadidos durante la copia de datos. Asegúrese de que el miembro de destino tenga suficiente espacio en disco en la
localbase de datos para almacenar temporalmente estos registros de oplog durante esta etapa de copia de datos.Aplica todos los cambios al conjunto de datos. Utilizando el oplog de la fuente, el
mongodactualiza su conjunto de datos para reflejar el estado actual del set de réplicas.Cuando finaliza la sincronización inicial, el nodo pasa de
STARTUP2aSECONDARY.
Para realizar una sincronización inicial, consulte Resincronizar un Nodo de un Set de réplicas autogestionado.
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
initialSyncSourceReadPreferenceconfigurado enprimary(por defecto sichainingestá 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
initialSyncSourceReadPreferenceconfigurado enprimaryPreferred(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
PRIMARYoSECONDARY.La fuente de sincronización debe estar en línea y accesible.
Si
initialSyncSourceReadPreferenceessecondaryosecondaryPreferred, 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
30segundos 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
votesen 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
PRIMARYoSECONDARY.La fuente de sincronización debe estar en línea y accesible.
Si
initialSyncSourceReadPreferenceessecondary, 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.
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:
|
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.
Nota
Para que el control de flujo se active, el conjunto de réplicas/clúster fragmentado debe tenerfeatureCompatibilityVersion (fCV) igual a 4.2 y la preocupación majority enabled de lectura igual a. Es decir, el control de flujo habilitado no tiene efecto si fCV no es 4.2 o si la mayoría de la preocupación de lectura está deshabilitada.
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
PRIMARYoSECONDARY.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
30segundos 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
votesen 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
PRIMARYoSECONDARY.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.