SET GLOBAL innodb_log_group_home_dir, innodb_log_file_disabled

MySQL 8.0 introduced a way to disable or enable the InnoDB redo log while the server is running. jeanfrancois.gagne has pointed out that this could make sense for speeding up some bulk operations, such as setting up a replica.

I believe that the most straightforward way to implement this would be to rely on the log resizing mechanism that was introduced in MDEV-27812, and on the SET GLOBAL statement:

• innodb_log_file_disabled (new parameter, default OFF): disable or enable the redo log
• innodb_log_group_home_dir (previously read-only the storage location of ib_logfile0
• innodb_encrypt_log and possible encryption parameters (this will remain read-only while the server is running)
• innodb_log_file_size (MDEV-27812 enabled SET GLOBAL for this).

Until MDEV-36770 and MDEV-36828 have been fixed, a change of each of the above parameters will invoke the log resizing mechanism, instead of being executed in one atomic step.

The logic of online log resizing or log rebuild is straightforward.

1. Create and allocate a new file ib_logfile101 that will be the new log file.
2. Start replicating log to ib_logfile101.
3. On the next log checkpoint (page cleaner batch) that advances the LSN beyond the start of ib_logfile101, make ib_logfile101 the main write-ahead log ib_logfile0.
   • If innodb_log_group_home_dir is changed to point to a different file system, an atomic replacement of the old ib_logfile0 with the new ib_logfile101 will not be possible.
     • For a short moment, a valid ib_logfile0 will exist in both the old and the new location. Either one will be valid for recovery.
     • The ib_logfile0 in the old location will be deleted.

If the administrator successfully executes SET GLOBAL innodb_log_group_home_dir but forgets to adjust innodb_log_group_home_dir in the server configuration, InnoDB will fail to start up until the parameter has been corrected or the ib_logfile0 has been moved back. See MDEV-27199.

If the server is shut down or killed while innodb_log_file_disabled=ON, it will fail to start up normally. A start-up with innodb_force_recovery=6 may be attempted, but the database may be badly corrupted, depending on the state of the buffer pool when the server had been terminated. While (innodb_log_file_disabled=ON) is in effect, no ib_logfile0 will exist at all. We will continue to allocate LSN and write log records to log_sys.buf, but the log "writes" simply advance log_sys.write_lsn and log_sys.flushed_to_disk_lsn without accessing the non-existent file. During the time when no ib_logfile0 exists, crash recovery will be refused by default, thanks to MDEV-27199. When the redo log is being re-enabled, the ib_logfile101 would be ignored by recovery until it is renamed to ib_logfile0 as part of a log checkpoint.

For disabling or enabling the redo log, instead of SET GLOBAL innodb_log_file_disabled, MySQL 8.0 uses the following syntax:

ALTER INSTANCE DISABLE INNODB REDO_LOG;

ALTER INSTANCE ENABLE INNODB REDO_LOG;