Docs Menu
Docs Home
/
Manual de base de datos
/

Oplog del set de réplicas

El El registro de operaciones (oplog) es una colección especial con límite que mantiene un registro continuo de todas las operaciones que modifican los datos almacenados en sus bases de datos. Si las operaciones de escritura no modifican ningún dato o fallan, no crean entradas en el registro de operaciones.

A diferencia de otras colecciones limitadas, el oplog puede crecer más allá de su límite de tamaño configurado para evitar eliminar el majority commit point.

MongoDB aplica operaciones de base de datos en el primario y luego registra las operaciones en el oplog del primario. Los miembros secundarios luego copian y aplican estas operaciones en un proceso asíncrono. Todos los miembros del set de réplicas contienen una copia del oplog, en la colección local.oplog.rs, lo que les permite mantener el estado actual de la base de datos.

Para facilitar la replicación, todos los miembros del set de réplicas envían señales de latido (pings) a todos los demás nodos. Cualquier nodo secundario puede importar entradas del oplog de cualquier otro nodo.

Cada operación en el oplog es idempotente. Es decir, las operaciones de oplog producen los mismos resultados, ya sea que se apliquen una o varias veces al conjunto de datos de destino.

Cuando inicias por primera vez un miembro de un set de réplicas, MongoDB crea un oplog de un tamaño por defecto si no especifica el tamaño del oplog.

Para sistemas Unix y Windows

El tamaño por defecto del oplog depende del motor de almacenamiento:

Motor de almacenamiento
Tamaño por defecto del oplog

5% de espacio libre en disco

5% de la memoria física

El tamaño del oplog por defecto tiene las siguientes restricciones:

  • El tamaño mínimo de oplog es 990 MB. Si el 5 % de espacio libre en disco o memoria física (según lo que sea aplicable en función del motor de almacenamiento) es menor que 990 MB, el tamaño por defecto de oplog es 990 MB.

  • El tamaño máximo por defecto del oplog es 50 GB. Si el 5% de espacio libre en disco o memoria física (según lo que sea aplicable en función de su motor de almacenamiento) es mayor que 50 GB, el tamaño por defecto del oplog es 50 GB.

Para sistemas macOS de 64 bits

El tamaño por defecto de oplog es de 192 MB de espacio libre en disco o memoria física, según el motor de almacenamiento:

Motor de almacenamiento
Tamaño por defecto del oplog

192 MB de espacio libre en disco

192 MB de memoria física

En la mayoría de los casos, el tamaño por defecto del oplog es suficiente. Por ejemplo, si un oplog ocupa el 5 % del espacio libre en disco y se llena en 24 horas de operaciones, los secundarios pueden dejar de copiar entradas del oplog por hasta 24 horas sin desactualizarse demasiado para continuar replicando. Sin embargo, la mayoría de los sets de réplicas tienen volúmenes de operaciones mucho más bajos y sus registros de operaciones (oplogs) pueden contener un número mucho mayor de operaciones.

Antes de que mongod cree un oplog, puede especificarse su tamaño con la opción oplogSizeMB. Una vez que hayas iniciado un nodo del set de réplicas por primera vez, utiliza el comando administrativo replSetResizeOplog para cambiar el tamaño del oplog. replSetResizeOplog te permite redimensionar el oplog dinámicamente sin reiniciar el proceso de mongod.

Se puede especificar el número mínimo de horas para preservar una entrada del oplog donde mongod solo remueve una entrada del oplog si se cumplen ambos de los siguientes criterios:

  • El oplog ha alcanzado el tamaño máximo configurado.

  • La entrada del oplog es más antigua que el número de horas configurado según el reloj del sistema del host.

Por defecto, MongoDB no establece un período de retención mínimo para el oplog y lo trunca automáticamente comenzando con las entradas más antiguas para mantener el tamaño máximo configurado del oplog.

Para configurar el periodo mínimo de retención del oplog al iniciar el mongod, ya sea:

Para configurar el período mínimo de retención del oplog en un mongod en ejecución, utiliza replSetResizeOplog. Establecer el período de retención mínimo de oplog mientras mongod está en ejecución anula cualquier valor establecido al inicio. Debes actualizar el valor del archivo de configuración correspondiente o la opción de línea de comandos para que esos cambios persistan tras un reinicio del servidor.

Las entradas de oplog están selladas con marca de tiempo. La oplog window es la diferencia de tiempo entre las marcas de tiempo más recientes y más antiguas en el oplog. Si un nodo secundario pierde la conexión con el primario, solo puede usar replicación para sincronizarse nuevamente si la conexión se restaura dentro de la oplog window.

Si puedes predecir que la carga de trabajo de tu set de réplicas se asemejará a uno de los siguientes patrones, podría interesarte crear un oplog que sea más grande que aquel establecido por defecto. Por el contrario, si tu aplicación realiza predominantemente lecturas con una cantidad mínima de operaciones de escritura, un oplog más pequeño puede ser suficiente.

Las siguientes cargas de trabajo podrían requerir un tamaño de oplog mayor.

El oplog debe traducir las actualizaciones múltiples en operaciones individuales para mantener la idempotencia. Esto puede utilizar una gran cantidad de espacio de oplog sin un aumento correspondiente en el tamaño de los datos o en el uso del disco.

Si borras aproximadamente la misma cantidad de datos que insertas, la base de datos no crecerá significativamente en el uso del disco, pero el tamaño del registro de operaciones puede ser bastante grande.

Si una parte significativa de la carga de trabajo consiste en actualizaciones que no aumentan el tamaño de los documentos, la base de datos registra una gran cantidad de operaciones pero no cambia la cantidad de datos en el disco.

Para ver el estado del oplog, incluyendo el tamaño y el rango de tiempo de las operaciones, usa el método rs.printReplicationInfo(). Para obtener más información sobre el estado del oplog, consulta Comprobar el tamaño del oplog.

En diversas situaciones excepcionales, las actualizaciones del registro de operaciones de un secundario podrían retrasarse respecto al tiempo de rendimiento deseado. Utilice db.getReplicationInfo() de un miembro secundario y la salida del estado de replicación para evaluar el estado actual de la replicación y determinar si existe algún retraso involuntario.

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.

Consulta Atraso de la replicación para obtener más información.

Los nodos secundarios de un set de réplicas registran entradas del oplog que tardan más en aplicarse que el umbral de operación lenta. Estos mensajes son logged para los secundarios bajo el componente REPL con el texto applied op: <oplog entry> took <num>ms.

2018-11-16T12:31:35.886-05:00 I REPL [repl writer worker 13] applied op: command { ... }, took 112ms

Los registros de aplicación lenta de oplog en los secundarios son:

Para obtener más información sobre cómo establecer el umbral de operación lenta, consulta

No puedes drop la colección local.oplog.rs de ningún nodo del set de réplicas si tu implementación de MongoDB utiliza el motor de almacenamiento WiredTiger. No se puede descartar la colección local.oplog.rs de una instancia autónoma de MongoDB. mongod requiere el oplog tanto para la replicación como para la recuperación de un nodo si el nodo falla.

A partir de MongoDB,5.0 ya no es posible realizar operaciones de escritura manuales en el registro de operaciones en un clúster que se ejecuta como un conjunto de réplicas. Las operaciones de escritura en el registro de operaciones cuando se ejecuta como una instancia independiente solo deben realizarse con la ayuda del soporte técnico de MongoDB.

Volver

Replicación

En esta página