A transaction log is an append-oriented database record of data changes. When data is added, changed, or deleted, the database writes the change to the log before updating its tables. This ordering preserves a recoverable record of what happened. section 4.1.1
The log supports recovery and replication. After a failure, the database can replay recorded changes to restore a clean state; clustered instances can replicate the log and independently rebuild their tables from it. section 4.1.1 section 17.4.2
A transaction log provides several related capabilities:
- Preserves the chronological history of changes rather than only the latest table state. section 4.1.2
- Allows a database state from an earlier time to be reconstructed by replaying entries up to that point. section 4.1.2
- Provides a source for keeping indexes, materialized views, and other derived structures current. section 17.4.2
Change data capture
A change data capture connector can monitor a relational database's transaction log instead of repeatedly inspecting the table itself. The Debezium connector for PostgreSQL is a concrete example of this approach, turning recorded database changes into an integration flow. section 11.9
Figure 4.1 A log is a sequential list where we add elements at the end and read them from a specific position (offset). For example, we read from offset 0, then choose to read from offset 4, and so on.
Use the sequential-log diagram to follow append-at-the-end writes, chronological reads, and positions that identify where reading resumes. section 4.1.2
