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.
Because undo tablespace files handle I/O operations formerly done inside the system tablespace, the definition of system tablespace is extended to include undo tablespace files.
The undo tablespace feature involves the following configuration options:
innodb_rollback_segments
becomes innodb_undo_logs. The
old name is still available for compatibility.
The innodb_undo_tablespaces and
innodb_undo_directory
configuration options are non-dynamic startup options that can
only be enabled when initializing a MySQL instance, which means
that undo tablespaces can only be created when initializing a
MySQL instance.
The following procedure assumes the configuration is performed on a test instance prior to production deployment.
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. For embedded MySQL
installations, an absolute path must be specified.
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.
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 undo 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.
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 Server” for more information.
Benchmark the performance of I/O intensive workloads.
Periodically increase the value of
innodb_undo_logs and rerun
performance tests. Find the value where you stop experiencing
gains in I/O performance.
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.
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 the 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 filesystem memory cache, in turn
allowing a higher percentage of system memory to be devoted to the
InnoDB buffer
pool.
The typical SSD best practice of keeping the
InnoDB system tablespace on a hard drive and
moving the per-table tablespaces to SSD, is assisted by moving the
undo information into separate tablespace files.
The physical undo tablespace files are named
undo, where
N.ibdN is the space ID, including leading
zeros.
MySQL instances containing separate undo tablespaces cannot be downgraded to earlier releases such as MySQL 5.5 or 5.1.