MySQL raises ER_INNODB_UNDO_LOG_FULL when all undo tablespace pages are exhausted, preventing new undo records and halting DML.
ER_INNODB_UNDO_LOG_FULL signals that MySQL’s InnoDB undo tablespaces have no free pages left. Free space by truncating or adding undo tablespaces, or shorten long transactions, to restore normal operation.
ER_INNODB_UNDO_LOG_FULL
ER_INNODB_UNDO_LOG_FULL occurs when every active InnoDB undo tablespace runs out of free pages. The server cannot store additional undo records needed for transaction rollback and MVCC, so it refuses further DML and may abort sessions.
The condition was introduced in MySQL 5.7.4 and typically surfaces during bulk writes, long running transactions, or when undo tablespaces were sized too small. Clearing space or adding capacity resolves the fault quickly.
Undo pages are consumed by each row change until the transaction ends and purge frees the pages. When transactions stay open too long or workload is intense, consumption outpaces purge and space runs out.
Instances with a single shared undo tablespace, disabled truncate settings, or insufficient innodb_undo_log_capacity face higher risk. Crash recovery or large rollbacks can also saturate the space.
First, identify and stop transactions holding space. Then either truncate existing undo logs or add new undo tablespaces and restart purge. Fix configuration to prevent recurrence.
Bulk data loads combined with foreign key checks can fill undo quickly; load in smaller batches. Background migrations sometimes forget to COMMIT; add explicit commits. Long idle connections in poolers keep transactions open; set wait_timeout and interactive_timeout wisely.
Size innodb_undo_tablespaces and innodb_undo_log_truncate for workload, monitor the information_schema.INNODB_TRX table, and alert when used pages near 80 percent. Keep transactions short and use autocommit for OLTP workloads.
ER_INNODB_OUT_OF_MEMORY arises when buffer pool cannot allocate pages. ER_LOCK_WAIT_TIMEOUT signals lock contention from the same long transactions that fill undo. Both improve after shortening transactions and tuning InnoDB.
The instance relies on the default single undo tablespace, which is quickly saturated under heavy write traffic.
Open transactions keep undo pages referenced, preventing purge from reclaiming space until COMMIT or ROLLBACK executes.
Slow purge threads or high redo pressure delay undo page recycling, letting consumption spike.
If innodb_undo_log_truncate is OFF, unused undo segments remain allocated indefinitely.
Occurs when buffer pool cannot allocate memory; often coexists with intense undo activity.
Shows lock waits that may be caused by the same long transactions depleting undo space.
Two phase commit timeout can appear if undo space prevents prepare or commit from finishing.
Query information_schema.INNODB_METRICS for name like 'undo%' or inspect SHOW ENGINE INNODB STATUS to view used pages per undo tablespace.
More disk helps but the root cause is usually long transactions. Fixing application logic is essential.
No. InnoDB does not support changing the size of an existing undo tablespace; create additional ones instead.
Galaxy centralizes queries, lets teams monitor transaction length with endorsed dashboards, and surfaces AI prompts to close idle sessions before undo space is exhausted.
.avif)
.avif){kind=logo}
