Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
11.2, 11.3(EOL)
Description
jeanfrancois.gagne suggested that it would be easier for users if they did not have to modify any start-up parameters (adding an :autoshrink attribute to innodb_data_file_path) but could simply have InnoDB shrink the system tablespace during a slow shutdown (after SET GLOBAL innodb_fast_shutdown=0).
The reason why the :autoshrink attribute was introduced in MDEV-14795 to make the cleanup opt-in was twofold: to reduce the InnoDB startup time and to avoid any trouble in case the system tablespace is corrupted in any way. The way the feature is implemented should avoid trouble, by first checking that everything is consistent and then making the modifications.
Attempting to shrink the system tablespace on a slow shutdown will retain the opt-in aspect: the default value is innodb_fast_shutdown=1. The time needed for shrinking the system tablespace should be negligible (some seconds) compared to the time needed for a complete purge of committed transaction history (which could even be hours, depending on the state of the database).
Dedicated undo tablespaces will be truncated based on the value of the settable global variable innodb_undo_log_truncate. That logic would not be touched here.
Attachments
Issue Links
- causes
-
MDEV-34209 InnoDB is disregarding read-only mode on slow shutdown
- Closed
-
MDEV-34216 Possible corruption when shrinking the system tablespace on innodb_fast_shutdown=0
- Closed
-
MDEV-34855 Bootstrap hangs while shrinking the system tablespace
- Closed
- is blocked by
-
MDEV-14795 InnoDB system tablespace cannot be shrunk
- Closed