Comments - InnoDB Undo Log
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.
When the setting innodb_undo_tablespaces=0 is in effect, all undo log records will be stored in the InnoDB system tablespace, and the undo logs cannot be truncated or freed.
Undo tablespace files undo001 through undo127 (when using innodb_undo_tablespaces) will be truncated automatically when innodb_undo_log_truncate=ON, when all undo log records in that undo tablespace has been processed. The innodb_max_undo_log_size is a soft limit. One undo tablespace at a time is chosen for truncation. During this time, further writes to the undo tablespace that has been chosen for truncation are prevented, and new transactions will write their undo log to the other undo tablespaces.
Theoretically and conceptually, it could be cafe to remove undo tablespace files after a successful slow shutdown (innodb_fast_shutdown=0) really removed all undo log records. This cannot be guaranteed; there might exist transactions in XA PREPARE state. Also, database start-up would likely fail if the TRX_SYS page in the system tablespace points to non-existing undo tablespace pages.
Starting with MariaDB Server 10.11, MDEV-19229 allows you to change innodb_undo_tablespaces between server restarts. If the existing undo tablespaces are logically empty, this will reinitialize the desired number of undo tablespaces.