Understanding InnoDB Undo Log Architecture: Pages, Segments, Rollback Segments, and Undo Tablespaces

Based on the MySQL 8.0.32 source code with the InnoDB storage engine, this article describes the logical structure used to manage Undo logs, which are generated when a transaction modifies (INSERT, UPDATE, DELETE) table data.

1. Introduction

Undo logs are stored on disk and organized into four hierarchical layers, from top to bottom: Undo tablespace, rollback segment, Undo segment, and Undo page.

2. Undo Page

An Undo page is the direct container for Undo log records. Its size defaults to 16 KB, the same as a regular data page. A single transaction may need one or more Undo pages, which are linked together when they belong to the same Undo segment.

3. Undo Segment

When a transaction generates a large amount of Undo logs, many Undo pages are required. InnoDB groups these pages into a logical structure called a segment , specifically an Undo segment . Even if only one Undo page is needed, it is still managed by an Undo segment because the exact number of pages required is unknown until the transaction commits.

Undo logs generated by INSERT statements are used only for transaction rollback, while those generated by UPDATE or DELETE are also used to read historical row versions. Consequently, InnoDB uses separate Undo segments for INSERT‑type logs and for UPDATE/DELETE‑type logs.

Insert Undo segment – manages Undo pages that store Undo logs from INSERT operations.

Update Undo segment – manages Undo pages that store Undo logs from UPDATE and DELETE operations.

4. Rollback Segment

Each concurrent transaction is assigned one or more Undo segments, which in turn are managed by rollback segments . A rollback segment contains a header with 1,024 slots, each slot occupying 4 bytes to store the page number of an Undo segment’s header. An unused slot holds the maximum 4‑byte integer 4294967295 , represented in the source code by the constant FIL_NULL .

Based on the lifecycle of table data, tables are classified as:

Regular user tables – both the table definition and data persist after a MySQL restart.

Temporary user tables – the table definition persists but the data is discarded after a restart.

Changes to regular tables require Undo logs to survive a restart so that uncommitted transactions can be rolled back, which also necessitates corresponding Redo logs. Changes to temporary tables do not need durable Undo logs, and therefore no Redo logs are generated.

Read‑write transactions are assigned rollback segments in three possible ways:

If the transaction only modifies regular tables, one rollback segment is allocated.

If the transaction only modifies temporary tables, one rollback segment is allocated.

If the transaction modifies both regular and temporary tables, two rollback segments are allocated.

5. Undo Tablespace

The files on disk that store Undo logs are logically called Undo tablespaces. Because MySQL can run many concurrent transactions, a single Undo tablespace could grow very large. InnoDB can automatically truncate an Undo tablespace to its initial size when all rollback segments within it are unused, controlled by the system variables innodb_undo_log_truncate and innodb_max_undo_log_size .

When the workload continuously creates transactions, a single Undo tablespace cannot be truncated effectively. Therefore, InnoDB supports multiple Undo tablespaces, whose count is controlled by the variable innodb_undo_tablespaces (default 2, minimum 2, maximum 127).

The number of rollback segments per Undo tablespace is governed by innodb_rollback_segments (default and maximum 128, minimum 1), ensuring a balanced distribution of segments across tablespaces.

6. Summary

Undo tablespaces manage rollback segments; rollback segments manage Undo segments; Undo segments manage Undo pages; Undo pages store Undo logs.

InnoDB supports 2 – 127 Undo tablespaces, each with up to 128 rollback segments, allowing a total of 256 – 16,256 rollback segments. Each rollback segment can manage 1,024 Undo segments, supporting 262,144 – 16,646,144 Undo segments overall.

Question for readers: Considering only the limit on the number of Undo segments, what is the minimum and maximum number of concurrent read‑write transactions that can be supported with 127 Undo tablespaces?