The redo log is a disk-based data structure used during crash recovery to correct data written by incomplete transactions. During normal operations, the redo log encodes requests to change table data that result from SQL statements or low-level API calls. Modifications that did not finish updating the data files before an unexpected shutdown are replayed automatically during initialization, and before the connections are accepted. For information about the role of the redo log in crash recovery, see Section 14.21.2, “InnoDB Recovery”.
By default, the redo log is physically represented on disk by two
ib_logfile1. MySQL writes to the redo log
files in a circular fashion. Data in the redo log is encoded in
terms of records affected; this data is collectively referred to
as redo. The passage of data through the redo log is represented
by an ever-increasing LSN value.
To change the number or the size of your
log files, perform the following steps:
mysql> SET GLOBAL innodb_fast_shutdown = 1;
After ensuring that
innodb_fast_shutdownis not set to 2, stop the MySQL server and make sure that it shuts down without errors (to ensure that there is no information for outstanding transactions in the log).
Copy the old log files into a safe place in case something went wrong during the shutdown and you need them to recover the tablespace.
Delete the old log files from the log file directory.
my.cnfto change the log file configuration.
InnoDB, like any other
ACID-compliant database engine,
flushes the redo log of a
transaction before it is committed.
uses group commit
functionality to group multiple such flush requests together to
avoid one flush for each commit. With group commit,
InnoDB issues a single write to the redo log
file to perform the commit action for multiple user transactions
that commit at about the same time, significantly improving
Group commit in
InnoDB worked in earlier
releases of MySQL and works once again with MySQL 5.1 with the
InnoDB Plugin, and MySQL 5.5 and higher. The
introduction of support for the distributed transactions and Two
Phase Commit (2PC) in MySQL 5.0 interfered with the
InnoDB group commit functionality. This issue
is now resolved.
The group commit functionality inside
works with the Two Phase Commit protocol in MySQL. Re-enabling
of the group commit functionality fully ensures that the
ordering of commit in the MySQL binary log and the
InnoDB logfile is the same as it was before.
It means it is safe to use the MySQL Enterprise Backup product
InnoDB 1.0.4 (that is, the
InnoDB Plugin with MySQL 5.1) and above.
For more information about performance of
COMMIT and other transactional operations,
see Section 8.5.2, “Optimizing InnoDB Transaction Management”.