MongoDB
Explica el oplog como registro de operaciones replicadas, su ventana temporal y su papel en secundarios, Change Streams, sincronización y recuperación.
El es una capped collection interna que registra operaciones replicables de un replica set. Los secondaries leen estas entradas y las aplican para alcanzar el estado del primary. Change Streams también dependen de esta historia para entregar y reanudar eventos.
write en primary
→ entrada de oplog
→ secondary obtiene batch
→ aplica operación
→ avanza su posiciónNo es una tabla de auditoría ni un contrato de aplicación.
El oplog tiene tamaño limitado y sobrescribe entradas antiguas cuando necesita espacio. Por eso su capacidad debe expresarse también como ventana temporal:
primera entrada disponible: hace 18 horas
última entrada: ahora
→ oplog window ≈ 18 horasEl tamaño en GB no basta; una campaña de escrituras puede consumir la misma capacidad mucho más rápido.
El oplog contiene representaciones internas de inserts, updates, deletes, comandos y transacciones. MongoDB transforma ciertas operaciones para que puedan aplicarse de forma idempotente por los secondaries.
La estructura exacta es interna y puede cambiar. No construyas lógica de negocio leyendo local.oplog.rs directamente.
Un secondary mantiene una posición aplicada. Si el primary genera operaciones más rápido de lo que el secondary consume, aumenta lag.
Métricas necesarias:
oplog window = 12 h
secondary lag = 10 h
→ margen operativo pequeñoUn secondary desconectado necesita que las entradas desde su último punto sigan disponibles. Si queda fuera de la ventana, no puede alcanzar incrementalmente y requiere initial sync o proceso de resync.
Esto puede transferir grandes volúmenes y añadir carga. Dimensiona la ventana para mantenimiento, incidentes y backups.
Un resume token apunta a una posición lógica relacionada con el historial. Si el consumidor intenta reanudar después de que esa historia expiró, el resume falla.
Los consumidores deben monitorear:
Transacciones grandes pueden generar muchas entradas y aplicar cambios de forma coordinada. Aumentan presión sobre oplog, cache y secondaries. No uses una transacción para migraciones masivas.
Antes de una migración, estima no solo documentos modificados sino bytes de oplog y tiempo de aplicación.
El tamaño predeterminado depende de plataforma y configuración. Ajustarlo requiere comprender disco disponible, tasa de escritura, RPO operacional y tiempo de recuperación.
Una ventana excesivamente pequeña provoca resyncs y pérdida de resume. Una enorme consume almacenamiento y no reemplaza backup.
Administradores pueden inspeccionarlo para diagnóstico, pero:
Change Streams son la interfaz soportada para aplicaciones.
Durante cambios de primary, entradas no majority-committed pueden divergir. MongoDB reconcilia la historia y puede revertir operaciones. La posición del oplog y commit point son centrales para este proceso.
Cada shard es normalmente un replica set con su propio oplog. Un Change Stream de cluster combina eventos. Debes monitorear ventanas por shard; el shard más corto puede limitar capacidad de resume global.
El oplog es la historia operativa limitada que alimenta replication y Change Streams. Su tamaño se interpreta como tiempo disponible para alcanzar o reanudar. Debe dimensionarse y monitorearse según la tasa de escritura; no es una API de negocio, auditoría ni backup.
Sharding.