Critical MySQL 8.0 Undo Log Truncate Bug: Risks, Bug Chain, and Immediate Mitigation

Problem Overview

If a MySQL 8.0 replica has super_read_only=ON and the default innodb_undo_log_truncate=ON, the automatic undo‑log truncation may start but cannot finish, leaving undo_*_trunc.log files and risking silent data corruption.

The root cause is not user writes but the metadata updates performed by the system thread being blocked by the read‑only mode; InnoDB needs to update the data dictionary (DD) and undo tablespace metadata to complete the truncation, which is prevented in super_read_only mode.

Bug Chain

The truncation failure links to several bugs:

Bug #112717 (2023): truncation hangs, residual undo_*_trunc.log, INFORMATION_SCHEMA FILE_SIZE may show 0.

Bug #112262 (same year): DD update failure reports missing tablespace, causing backup tools like Percona XtraBackup to fail.

Bug #119628 (reported this year): truncation failure leads to undo‑tablespace reconstruction on restart, possible data loss if uncommitted transactions exist.

These bugs can cause undo‑tablespace rebuilds, metadata inconsistency, and silent data damage.

Official Response

As of MySQL 8.0.45, the bugs remain open and critical (e.g., #119628 is still Open/Critical). The fix is slated for MySQL 8.4/9.0, with no clear backport to 8.0. Percona Server 8.0.39 already includes a fix (PS‑9322).

Mitigation Steps

Immediate Check : Verify the data directory for leftover undo_*_trunc.log files and monitor INFORMATION_SCHEMA.INNODB_TABLESPACES for abnormal undo‑tablespace status.

Short‑Term Workaround : Set innodb_undo_log_truncate=OFF on the replica to stop automatic truncation.

Handle Intermediate State : If truncation logs exist but the server has not been restarted, perform a “slow shutdown” by setting innodb_fast_shutdown=0, then restart. If a restart has already occurred, run consistency checks or consider rebuilding the replica.

Long‑Term Fix : Upgrade to MySQL 8.4 (the upcoming LTS release) where the fix is incorporated.

Two concrete remediation options for the undo tablespace are: ALTER UNDO TABLESPACE innodb_undo_002 SET INACTIVE to let the system truncate the space automatically.

Temporarily disable super_read_only and enable innodb_undo_log_truncate so the truncation can complete under writable DD.

Conclusion

This issue exemplifies how metadata operations blocked by read‑only mode can lead to silent data corruption via the core undo mechanism. With MySQL 8.0 approaching EOL and no backport guarantee, upgrading to 8.4 is the safest path to protect data integrity.

References

Bug #112717: https://bugs.mysql.com/bug.php?id=112717

Bug #112262: https://bugs.mysql.com/bug.php?id=112262

Bug #119628: https://bugs.mysql.com/bug.php?id=119628

Jean‑François Gagné’s blog post: https://jfg-mysql.blogspot.com/2026/01/undo-log-truncation-bug-in-80-leads-to-data-corruption.html.html