Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 37.5Mb
PDF (A4) - 37.5Mb
PDF (RPM) - 36.9Mb
HTML Download (TGZ) - 10.2Mb
HTML Download (Zip) - 10.2Mb
HTML Download (RPM) - 8.9Mb
Man Pages (TGZ) - 211.3Kb
Man Pages (Zip) - 321.0Kb
Info (Gzip) - 3.4Mb
Info (Zip) - 3.4Mb
Excerpts from this Manual

MySQL 5.7 Reference Manual  /  ...  /  Storing InnoDB Undo Logs in Separate Tablespaces

14.7.7 Storing InnoDB Undo Logs in Separate Tablespaces

You can store InnoDB undo logs in one or more separate undo tablespaces outside of the system tablespace. This layout is different from the default configuration in which undo logs reside in the system tablespace. The I/O patterns for undo logs make undo tablespaces good candidates to move to SSD storage, while keeping the system tablespace on hard disk storage. Users cannot drop the separate tablespaces created to hold InnoDB undo logs, or the individual segments inside those tablespaces. However, undo logs stored in undo tablespaces can be truncated. For more information, see Section 14.7.8, “Truncating Undo Logs That Reside in Undo Tablespaces”.

The undo tablespace feature involves the following configuration options:

  • innodb_undo_tablespaces

    Defines the number of tablespace files that rollback segments are divided between when you use a non-zero innodb_undo_logs setting. This non-dynamic startup option can only be configured when initializing the MySQL instance.

  • innodb_undo_directory

    The path where undo tablespaces are created. The location can be changed later by shutting down the server, moving undo tablespace files (undoN.ibd files) to a new directory, updating the innodb_undo_directory setting, and restarting the server.

  • innodb_undo_logs

    Defines the number of rollback segments used for data-modifying transactions that generate undo records. innodb_undo_logs replaces innodb_rollback_segments, which remains available for backward compatibility.

Configuring Separate Undo Tablespaces

The following procedure assumes the configuration is performed on a test instance prior to production deployment.

  1. Chose a directory location where you want InnoDB to create separate undo tablespaces for the undo logs. Specify the directory path as the argument to the innodb_undo_directory option in your MySQL configuration file or startup script. If no path is specified, undo tablespaces are created in the MySQL data directory, as defined by datadir.

  2. Decide on a starting value for the innodb_undo_logs option, which defines the number of rollback segments used by InnoDB. (Undo logs exist within undo log segments, which are contained within rollback segments.) You can start with a relatively low value and increase it over time to examine the effect on performance.

    One rollback segment is always assigned to the system tablespace, and 32 rollback segments are reserved for use by temporary tables and are hosted in the temporary tablespace (ibtmp1). Therefore, to allocate rollback segments to undo tablespaces, innodb_undo_logs must be set to a value greater than 33. For example, if you have two undo tablespaces (innodb_undo_tablespaces=2), innodb_undo_logs must be set to 35 to assign one rollback segment to each of the two undo tablespaces.


    When you configure separate undo tablespaces, the rollback segment in the system tablespace is rendered inactive.

  3. Decide on a non-zero value for the innodb_undo_tablespaces option. The rollback segments specified by the innodb_undo_logs value are divided between this number of separate tablespaces. The innodb_undo_tablespaces value is fixed for the life of the MySQL instance, so if you are uncertain about the optimal value, estimate on the high side.

  4. Create a new MySQL instance, using the values you chose in the configuration file or in your MySQL startup script. Use a realistic workload with data volume similar to your production servers. Alternatively, use the transportable tablespaces feature to copy existing database tables to your newly configured MySQL instance. See Section 14.7.6, “Copying File-Per-Table Tablespaces to Another Instance” for more information.

  5. Benchmark the performance of I/O intensive workloads.

  6. Periodically increase the value of innodb_undo_logs and rerun performance tests. Find the value where you stop experiencing gains in I/O performance.

  7. Deploy a new production instance using the ideal settings for these options. Set it up as a slave server in a replication configuration, or transfer data from an earlier production instance.

Performance and Scalability Considerations

Keeping the undo logs in separate files allows the MySQL team to implement I/O and memory optimizations related to this transactional data. For example, because undo data is written to disk and then rarely used (only in case of crash recovery), it does not need to be kept in the file system memory cache, in turn allowing a higher percentage of system memory to be devoted to the InnoDB buffer pool.

The typical best practice of keeping the InnoDB system tablespace on a hard drive and moving the file-per-table and general tablespaces to SSD is assisted by moving the undo information into separate tablespace files.


The physical undo tablespace files are named undoN.ibd, where N is the space ID, including leading zeros.

Prior to MySQL 5.7.18, space IDs were assigned to undo tablespaces in a consecutive order starting with space ID 1. As of MySQL 5.7.18, The first undo tablespace can be assigned a space ID other than 1. Space ID values for undo tablespaces are still assigned in a consecutive order.

MySQL instances containing separate undo tablespaces cannot be downgraded to earlier releases such as MySQL 5.5 or 5.1.

User Comments
Sign Up Login You must be logged in to post a comment.