Inicio › Tecnología › Registro De Transacciones
Un registro de transacciones, o log de transacciones (transaction log / write-ahead log), es un mecanismo interno de los sistemas de gestión de bases de datos qué anota de forma secuencial cada cambio realizado sobre los datos antes de aplicarlo definitivamente a las estructuras de almacenamiento principales. Este enfoque, conocido como write-ahead logging (WAL), garantiza la durabilidad y la capacidad de recuperación exigidas por las propiedades ACID: si el sistema falla a mitad de una operación, al reiniciar puede reproducir (redo) las transacciones confirmadas qué no llegaron a escribirse en disco, o deshacer (undo) las qué quedaron a medias. Motores como PostgreSQL, MySQL con InnoDB o SQL Server implementan variantes de este mecanismo como pieza central de su fiabilidad ante caídas.
Es el cuaderno interno de una base de datos donde apunta cada cambio antes de aplicarlo de verdad a los datos guardados. Si el ordenador se apaga a mitad de una operación, al volver a arrancar la base de datos revisa ese cuaderno para saber exactamente qué se quedó a medias y arreglarlo, sin perder ni duplicar información.
En un sistema bancario, cuando se transfiere dinero entre dos cuentas, el motor de base de datos escribe primero en el registro de transacciones tanto el cargo como el abono antes de confirmar la operación; si el servidor se cae justo entre esas dos escrituras, al reiniciar el sistema puede detectar la transacción incompleta y revertirla por completo, evitando qué el dinero desaparezca de una cuenta sin aparecer en la otra.
Es el mecanismo técnico principal qué garantiza la "D" de durabilidad (los cambios confirmados sobreviven a un fallo) y facilita también la atomicidad, al permitir deshacer por completo una transacción qué no llegó a completarse.
Sí, muchas soluciones de replicación funcionan enviando ese mismo flujo de cambios a un servidor secundario, qué los aplica en el mismo orden para mantener una copia sincronizada casi en tiempo real.
Puede bloquear las escrituras nuevas hasta liberarse o, en el peor caso, comprometer la capacidad de recuperación ante un fallo, por lo qué su tamaño y su integridad deben monitorizarse igual qué cualquier otro componente crítico del sistema de base de datos.