The primary purpose of the parameter innodb_force_recovery is to allow data to be dumped from a corrupted database.

Ironically, the parameter may also be used to corrupt a database. Until MDEV-19514 in MariaDB Server 10.5, innodb_force_recovery=4 and larger settings could cause corruption of secondary indexes.

In all versions, the setting innodb_force_recovery=6 will cause the redo log to be ignored. This setting was somewhat redundant, because a similar effect could be achieved by replacing ib_logfile0 with a logically empty log at the desired log sequence number, or by deleting the ib_logfile0 altogether.

We must not allow InnoDB to start up when the log file is missing or physically empty, except when the option innodb_force_recovery=6 is specified, to ignore the redo log altogether and to start the database in read-only mode.

Previously, to allow InnoDB to automatically create a lost log file, a field FIL_PAGE_FILE_FLUSH_LSN was written to the first page of the system tablespace on shutdown, bypassing the redo log and the doublewrite buffer. If the server was killed in the middle of that write, the entire server could fail to start up, due to a corrupted first page of the system tablespace. Because we will no longer automatically create a new log file, we will not update that field in the system tablespace either.