Log de transacciones

¿Qué es?

El log de transacciones es el fichero —o conjunto de ficheros— donde una base de datos anota cada cambio antes de aplicarlo a los ficheros de datos. Primero se escribe la intención en el log y se confirma; después, cuando convenga, se materializa en las tablas. Esa inversión del orden natural se conoce como write-ahead logging, y es lo que hace posible el resto.

Cada motor le da su nombre, pero el mecanismo es el mismo: binlog y redo log en MySQL, WAL en PostgreSQL, redo log en Oracle, transaction log en SQL Server.

¿Para qué sirve?

• Durabilidad: es la D de ACID. Si el servidor se apaga justo después de un commit, el cambio no se pierde porque está en el log, aunque todavía no estuviera en la tabla.
• Recuperación tras una caída: al arrancar, el motor relee el log, reaplica lo confirmado y deshace lo que quedó a medias.
• Recuperación a un punto en el tiempo: con una copia de seguridad completa más los logs posteriores se puede dejar la base exactamente como estaba antes de un error.
• Réplica: la copia secundaria no vuelve a ejecutar las consultas del origen, sino que aplica su log. Es el mecanismo estándar de la replicación de datos.
• Captura de cambios hacia el entorno analítico: el método de CDC de menor impacto consiste precisamente en leer este log, en vez de consultar las tablas o poner disparadores.

Por qué le importa a quien monta un pipeline

Porque el log no se guarda para siempre: cada motor lo recicla o lo archiva según su propia configuración de retención, y leerlo exige permisos específicos sobre la base operativa. Son las dos condiciones que convierten «leemos el log» en una petición concreta a quien administra el origen, y el primer punto de fricción habitual al montar una captura de cambios.

No confundirlo con el log de una tabla del lakehouse

Los formatos de tabla abierto de un lakehouse también mantienen un log, pero es de otra naturaleza: anota qué ficheros componen la tabla en cada versión, no las filas modificadas una a una. Ese registro es lo que da transacciones sobre almacenamiento de objetos y lo que permite el time travel. Coinciden en la idea —registrar antes de sobrescribir— y se diferencian en el grano.

Tampoco es lo mismo que el event sourcing: el log de transacciones es un detalle interno del motor, mientras que en event sourcing el flujo de eventos es la forma primaria en que la aplicación guarda su estado.

Más información

• ACID — las garantías que el log hace cumplir
• OLTP — el procesamiento que lo escribe sin parar
• CDC — la técnica que lo lee para alimentar la analítica
• OLTP vs OLAP: patrones y anti-patrones — capítulo de la guía práctica de arquitectura de datos de Dataprix.

Para comparar motores y plataformas de datos, el directorio de plataformas de datos de Dataprix recoge fichas y análisis editorial de las principales opciones.