Para mantener copias actualizadas del conjunto de datos compartidos, los miembros secundarios de un conjunto 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 miembro del conjunto de réplicas a otro. Consulte Selección de origen de sincronización inicial para obtener más información sobre los criterios de selección de origen de sincronización inicial.
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.
Proceso de sincronización inicial lógica
Cuando realizas una sincronización inicial lógica, MongoDB:
Clona todas las bases de datos excepto la local. Para clonar,
mongodescanea cada colección en cada base de datos de origen e inserta todos los datos en sus propias copias de estas colecciones.Compila todos los índices de las colecciones mientras se copian los documentos de cada colección.
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 base de datos
localpara almacenar temporalmente estos registros de oplog durante esta etapa de copia de datos.Aplica todos los cambios al conjunto de datos. Utilizando el registro de operaciones del origen,
mongodactualiza su conjunto de datos para reflejar el estado actual del conjunto de réplicas.
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 copia de archivos reemplaza la base de datos local del miembro de destino con la base de datos local del miembro de origen durante la sincronización.
Limitaciones
Durante una sincronización inicial basada en la copia de archivos:
No se puede ejecutar una copia de seguridad en el miembro con el que se está sincronizando ni en el miembro desde el que se está sincronizando.
No se puede escribir
localen la base de datos del miembro que se está sincronizando.
Solo puedes ejecutar una sincronización inicial desde un miembro determinado a la vez.
Al utilizar 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 error de red no transitorio (es decir, persistente) durante el proceso de sincronización, el secundario reinicia el proceso de sincronización inicial desde el principio.
Una sincronización inicial secundaria puede intentar reanudar el proceso de sincronización si se interrumpe por un error de red transitorio (es decir, temporal), una caída de colección o un cambio de nombre de 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(predeterminado si está deshabilitado),chainingseleccione el principal como fuente de sincronización. Si el principal no está disponible o no se puede acceder a él, se registra un error y se comprueba periódicamente su disponibilidad.Para configurado
initialSyncSourceReadPreferenceen (valor predeterminado para losprimaryPreferredmiembros del conjunto de réplicas con derecho a voto), intente seleccionar el principal como origen de sincronización. Si el principal no está disponible o no se puede acceder a él, seleccione el origen de sincronización entre los miembros restantes del conjunto de réplicas.Para todos los demás modos de lectura admitidos, realice la selección de fuente de sincronización desde los miembros del conjunto de réplicas.
Los miembros que realizan la selección de la fuente de sincronización inicial realizan dos pasadas por la lista de todos los miembros del conjunto de réplicas:
El miembro aplica los siguientes criterios a cada miembro del conjunto de réplicas al realizar el primer paso para seleccionar una fuente de sincronización inicial:
La fuente de sincronización debe estar en el
PRIMARYestado deSECONDARYreplicación o.La fuente de sincronización debe estar en línea y accesible.
Si
initialSyncSourceReadPreferencees o, lasecondaryfuente desecondaryPreferredsincronización debe ser secundaria.La fuente de sincronización debe
visibleser.La fuente de sincronización debe estar dentro
30de los segundos de la entrada de oplog más reciente en el servidor principal.Si el miembro, la
builds indexesfuente de sincronización debe crear índices.Si el miembro participa
votesen las elecciones del conjunto de réplicas, la fuente de sincronización también debe votar.Si el miembro no
delayed memberes un, la fuente de sincronización no debe retrasarse.Si el miembro es
delayed memberun, la fuente de sincronización debe tener un retraso configurado más corto.La fuente de sincronización 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 miembro realiza una segunda pasada con criterios más flexibles. Ver Sync Source Selection (Second Pass).
El miembro aplica los siguientes criterios a cada miembro del conjunto de réplicas al realizar el segundo paso para seleccionar una fuente de sincronización inicial:
La fuente de sincronización debe estar en el
PRIMARYestado deSECONDARYreplicación o.La fuente de sincronización debe estar en línea y accesible.
Si es, la
initialSyncSourceReadPreferencefuente desecondarysincronización debe ser secundaria.Si el miembro, la fuente de sincronización debe crear
builds indexesíndices.La fuente de sincronización 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 del registro de operaciones debe ser lo suficientemente larga para que un secundario pueda recuperar cualquier nueva entrada del registro de operaciones que se produzca 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 secundario 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 en un proceso asincrónico. []1
Los secundarios pueden cambiar automáticamente su sincronización desde el origen según sea necesario, en función de los cambios en el tiempo de ping y el estado de la replicación de otros miembros.Consulte Selección del origen de sincronización de replicación para obtener más información sobre los criterios de selección del origen 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
La sincronización desde las fuentes envía un flujo continuo de entradas del registro de operaciones a sus servidores secundarios de sincronización. La replicación en streaming mitiga el retardo de replicación en redes con alta carga y alta latencia. Además:
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 chaining configuración del conjunto de réplicas:
Con el encadenamiento habilitado (predeterminado), realice la selección de fuente de sincronización de los miembros del conjunto 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 miembro del conjunto de réplicas cuando realiza el primer paso para seleccionar una fuente de sincronización de replicación:
La fuente de sincronización debe estar en el
PRIMARYestado deSECONDARYreplicación o.La fuente de sincronización debe estar en línea y accesible.
La fuente de sincronización debe tener entradas de oplog más nuevas que el miembro (es decir, la fuente de sincronización debe estar por delante del miembro).
La fuente de sincronización debe
visibleser.La fuente de sincronización debe estar dentro
30de los segundos de la entrada de oplog más reciente en el servidor principal.Si el miembro, la
builds indexesfuente de sincronización debe crear índices.Si el miembro participa
votesen las elecciones del conjunto de réplicas, la fuente de sincronización también debe votar.Si el miembro no
delayed memberes un, la fuente de sincronización no debe retrasarse.Si el miembro es
delayed memberun, la fuente de sincronización debe tener un retraso configurado más corto.La fuente de sincronización 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 miembro aplica los siguientes criterios a cada miembro del conjunto de réplicas al realizar el segundo paso para seleccionar una fuente de sincronización de replicación:
La fuente de sincronización debe estar en el
PRIMARYestado deSECONDARYreplicación o.La fuente de sincronización debe estar en línea y accesible.
Si el miembro, la fuente de sincronización debe crear
builds indexesíndices.La fuente de sincronización 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.
La cantidad de veces que se puede cambiar una fuente por hora se puede configurar estableciendo el maxNumSyncSourceChangesPerHour parámetro.
Nota
El parámetro de inicioinitialSyncSourceReadPreferenceprevalece sobre el valorsettings.chainingAlloweddel conjunto de réplicas al seleccionar una fuente de sincronización inicial. Una vez que un miembro del conjunto de réplicas realiza correctamente la sincronización inicial, se aplica el valorchainingAllowedal 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.