Transaction log
A transaction log is an ordered record of transactions, transaction-related events, or resulting data changes, maintained as a history and often used for tracking or recovery.
PostgreSQL Mistakes and How to Avoid Them
The write-ahead log is PostgreSQL's sequential log of changes that must be recorded before corresponding data pages are written.
- How it is used
- Supports transaction integrity while underpinning replication, disk-capacity planning, and operational monitoring.
- How deep it goes
- Explains operational consequences through disk exhaustion, deletion hazards, replication loops, and monitoring metrics; defers WAL record internals.
- Examples
- Uses bidirectional alpha–beta logical replication and a no-space-left-on-device error to expose WAL risks.
- What you can do after
- Operate/configure it by monitoring WAL size, preserving pg_wal, and filtering replication origins to avoid disk-filling loops.
Read how PostgreSQL Mistakes and How to Avoid Them explains transaction log →
100 SQL Server Mistakes and How to Avoid Them
A transaction log file is the physical database file that stores transaction log records for recovery and transaction processing.
- How it is used
- Uses transaction-log behavior to prevent large data modifications and poor file-growth settings from causing failures or performance issues.
- How deep it goes
- Explains log records, LSNs, log blocks, VLFs, truncation, fragmentation, and a VLF-count query without fully detailing recovery models.
- Examples
- Uses a multi-billion-row table, a failing single DELETE, a DELETE TOP(250000) loop, and a sys.dm_db_log_info query.
- What you can do after
- Operate/configure log capacity and batch large deletes to reduce log-full failures and log-fragmentation performance risks.
Read how 100 SQL Server Mistakes and How to Avoid Them explains transaction log →
ScyllaDB in Action
A commit log is an append-only persistent record of database writes that supports recovery after a node failure.
- How it is used
- Uses the commit log to make ScyllaDB writes durable before memtables flush to SSTables.
- How deep it goes
- Explains the write lifecycle, append behavior, configured flush thresholds, and startup replay, but defers deeper shard internals.
- Examples
- Uses a write-to-SSTable lifecycle and a failed-process recovery scenario to illustrate persistence.
- What you can do after
- Evaluate/understand how ScyllaDB preserves writes and reconstructs in-memory state after process failure.
Apache Kafka in Action
A transaction log is an append-oriented database record of transactions and the data changes they produce.
- How it is used
- Supports database recovery, replication, temporal reconstruction, and change data capture.
- How deep it goes
- Explains write-before-table updates, replay, replication, and chronological access, but defers database-specific log formats.
- Examples
- Uses table updates, clustered database recovery, Debezium for PostgreSQL, and sequential entries identified by offsets.
- What you can do after
- Operate change data capture by monitoring recorded relational-database changes with a connector.
Kafka for Architects
A transaction log is an ordered database record of changes made by committed transactions.
- How it is used
- Records committed database changes for durability and traceability, and supports database-to-Kafka change capture.
- How deep it goes
- Explains ordering, replay, immutability, retention, partitions, offsets, and connector access, but not connector implementation steps.
- Examples
- Uses address updates, partitioned topics, Debezium, JDBC sinks, upserts, and tombstone messages.
- What you can do after
- Evaluate database integration choices using transaction-log capture, JDBC sinks, replay, ordering, retention, and security trade-offs.
Kafka Streams in Action, Second Edition
A transaction log is an append-only sequence of events or records maintained in occurrence order.
- How it is used
- Stores each topic partition’s events in occurrence order as Kafka appends records to the end of the file.
- How deep it goes
- Defines the log’s role and partition placement, but defers file growth and management to log segments.
- Examples
- Shows partition directories containing numbered .log files alongside index, time-index, and leader-epoch files.
- What you can do after
- Evaluate Kafka .log files as event sequences rather than application status or execution logs.
Read how Kafka Streams in Action, Second Edition explains transaction log →
Related concepts
- change-data-captureused by · Change-data capture is a technique for detecting and recording changes to a data source, such as insertions, updates, and deletions, so they can be propagated or processed.
- monitoringkind of · Monitoring is the ongoing observation and measurement of a system’s behavior, state, or operational signals to assess its condition and detect changes or problems.
- Debeziumused by · Debezium is an open-source change data capture platform that captures database changes and streams them to downstream systems.
- multi-version concurrency controlpart of · Multi-version concurrency control is a database concurrency-control technique that maintains multiple data versions, allowing transactions to read consistent snapshots while concurrent writes proceed with reduced blocking.
- virtual log filepart of · A virtual log file is a logical subdivision of a SQL Server transaction log file that stores a portion of its transaction log data.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.