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.
It would be nice if this article had a few additional sub-sections. For example, can you delete an undo log after a system is safely shut down? Do these undo logs shrink? Explaining the additional settings in context. Can you move an undo log to a new directory when the server is shut down for example. These are mostly operations questions, but the architecture questions should be answered as well.
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.