1.Redo Log
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.
ib_logfile0
ib_logfile1
1.1 Changing the Number or Size of Redo Log Files
-
Stop the MySQL server and make sure that it shuts down without errors.
-
my.cnf
innodb_log_file_size
. To increase the number of log files, configureinnodb_log_files_in_group
. -
Start the MySQL server again.
InnoDB
innodb_log_file_size
InnoDB
InnoDB
InnoDB
Backup utilities that copy redo log records may sometimes fail to keep pace with redo log generation while a backup operation is in progress, resulting in lost redo log records due to those records being overwritten. This issue most often occurs when there is significant MySQL server activity during the backup operation, and the redo log file storage media operates at a faster speed than the backup storage media. The redo log archiving feature, introduced in MySQL 8.0.17, addresses this issue by sequentially writing redo log records to an archive file in addition to the redo log files. Backup utilities can copy redo log records from the archive file as necessary, thereby avoiding the potential loss of data.
innodb_redo_log_archive_dirs
label:directory
:
). For example:
mysql> SET GLOBAL innodb_redo_log_archive_dirs='label1:directory_path1[;label2:directory_path2;…]';
label
directory_path
innodb_redo_log_archive_dirs
NULL
, which does not permit activating redo log archiving.
注意事项:
The archive directories that you specify must satisfy the following requirements. (The requirements are enforced when redo log archiving is activated.):
-
Directories must exist. Directories are not created by the redo log archive process. Otherwise, the following error is returned:
ERROR 3844 (HY000): Redo log archive directory '
directory_path1
' does not exist or is not a directory -
Directories must not be world-accessible. This is to prevent the redo log data from being exposed to unauthorized users on the system. Otherwise, the following error is returned:
ERROR 3846 (HY000): Redo log archive directory '
directory_path1
' is accessible to all OS users -
datadir
innodb_data_home_dir
innodb_directories
innodb_log_group_home_dir
,innodb_temp_tablespaces_dir
innodb_tmpdir
innodb_undo_directory
secure_file_priv
, nor can they be parent directories or subdirectories of those directories. Otherwise, an error similar to the following is returned:ERROR 3845 (HY000): Redo log archive directory '
directory_path1
' is in, under, or over server directory 'datadir' - '/path/to/data_directory
'
innodb_redo_log_archive_start()
If you are not using a backup utility that supports redo log archiving, redo log archiving can also be activated manually, as shown:
mysql> SELECT innodb_redo_log_archive_start('label', 'subdir'); +------------------------------------------+ | innodb_redo_log_archive_start('label') | +------------------------------------------+ | 0 | +------------------------------------------+
Or:
mysql> DO innodb_redo_log_archive_start('label', 'subdir'); Query OK, 0 rows affected (0.09 sec)
注意事项:
innodb_redo_log_archive_start()
innodb_redo_log_archive_stop()
). If the session is terminated before the redo log archiving is explicitly deactivated, the server deactivates redo log archiving implicitly and removes the redo log archive file.
label
innodb_redo_log_archive_dirs
subdir
label
subdir
INNODB_REDO_LOG_ARCHIVE
innodb_redo_log_archive_start()
, or deactivate it usinginnodb_redo_log_archive_stop()
. The MySQL user running the backup utility or the MySQL user activating and deactivating redo log archiving manually must have this privilege.
directory_identified_by_label
/[subdir
/]archive.serverUUID
.000001.logdirectory_identified_by_label
label
innodb_redo_log_archive_start()
subdir
innodb_redo_log_archive_start()
.
For example, the full path and name for a redo log archive file appears similar to the following:
/directory_path/subdirectory/archive.e71a47dc-61f8-11e9-a3cb-080027154b4d.000001.log
InnoDB
innodb_redo_log_archive_stop()
If you are not using a backup utility that supports redo log archiving, redo log archiving can also be deactivated manually, as shown:
mysql> SELECT innodb_redo_log_archive_stop(); +--------------------------------+ | innodb_redo_log_archive_stop() | +--------------------------------+ | 0 | +--------------------------------+
Or:
mysql> DO innodb_redo_log_archive_stop(); Query OK, 0 rows affected (0.01 sec)
After the stop function completes successfully, the backup utility looks for the relevant section of redo log data from the archive file and copies it into the backup.
After the backup utility finishes copying the redo log data and no longer needs the redo log archive file, it deletes the archive file.
Removal of the archive file is the responsibility of the backup utility in normal situations. However, if the redo log archiving operation quits unexpectedly beforeinnodb_redo_log_archive_stop()
Activating redo log archiving typically has a minor performance cost due to the additional write activity.
On Unix and Unix-like operating systems, the performance impact is typically minor, assuming there is not a sustained high rate of updates. On Windows, the performance impact is typically a bit higher, assuming the same.
If there is a sustained high rate of updates and the redo log archive file is on the same storage media as the redo log files, the performance impact may be more significant due to compounded write activity.
If there is a sustained high rate of updates and the redo log archive file is on slower storage media than the redo log files, performance is impacted arbitrarily.
Writing to the redo log archive file does not impede normal transactional logging except in the case that the redo log archive file storage media operates at a much slower rate than the redo log file storage media, and there is a large backlog of persisted redo log blocks waiting to be written to the redo log archive file. In this case, the transactional logging rate is reduced to a level that can be managed by the slower storage media where the redo log archive file resides.
2. Undo Logs
Undo logs that reside in the global temporary tablespace are used for transactions that modify data in user-defined temporary tables. These undo logs are not redo-logged, as they are not required for crash recovery. They are used only for rollback while the server is running. This type of undo log benefits performance by avoiding redo logging I/O.
innodb_rollback_segments
The number of transactions that a rollback segment supports depends on the number of undo slots in the rollback segment and the number of undo logs required by each transaction.
InnoDB
InnoDB Page Size | Number of Undo Slots in a Rollback Segment (InnoDB Page Size / 16) |
---|---|
4096 (4KB) | 256 |
8192 (8KB) | 512 |
16384 (16KB) | 1024 |
32768 (32KB) | 2048 |
65536 (64KB) | 4096 |
A transaction is assigned up to four undo logs, one for each of the following operation types:
-
INSERT
-
UPDATE
DELETE
-
INSERT
-
UPDATE
DELETE
INSERT
UPDATE
DELETE
INSERT
A transaction that performs operations on regular tables is assigned undo logs from an assigned undo tablespace rollback segment. A transaction that performs operations on temporary tables is assigned undo logs from an assigned global temporary tablespace rollback segment.
INSERT
INSERT
InnoDB
-
INSERT
UPDATE
DELETE
InnoDB
(innodb_page_size / 16) * innodb_rollback_segments * number of undo tablespaces
-
INSERT
UPDATE
DELETE
InnoDB
(innodb_page_size / 16 / 2) * innodb_rollback_segments * number of undo tablespaces
-
INSERT
InnoDB
(innodb_page_size / 16) * innodb_rollback_segments
-
INSERT
UPDATE
DELETE
InnoDB
(innodb_page_size / 16 / 2) * innodb_rollback_segments
https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-logs.html