MDEV-14425 will make InnoDB refuse to start up without ib_logfile0 unless innodb_force_recovery=6 is specified. In preview-10.8-MDEV-14425-innodb there is a change that removes the updates of the field FIL_PAGE_FILE_FLUSH_LSN in the system tablespace, because due to MDEV-14425, that field is no longer being read.

Thing with ib_logfile0 is that people may be used to removing it from offline backups. I certainly did that many times, and if I did, I expect many others do that too. That one can remove redo log after regular shutdown, is common knowledge. It should not take 20GB in the backup, when logically, it is empty. If there is not much effort to retain that feature, I'd retain it, but otherwise write a big Warning into the release notes.

wlad, before MDEV-14425, mariadb-backup --prepare created a zero-length ib_logfile0 as a dummy placeholder. In MDEV-14425, the size of that dummy file was increased to 12304 (0x3010) bytes. The code change attached to this MDEV-27199 will merely remove all updates of FIL_PAGE_FILE_FLUSH_LSN in the first page of the system tablespace.

If the server is started up with a zero-sized ib_logfile0, in MDEV-14425 we will assume that we are upgrading after a backup had been prepared. The start LSN will then be read from FIL_PAGE_FILE_FLUSH_LSN, and a new log file will be created starting from exactly that LSN.

If a user tries to be smart and creates a zero-sized ib_logfile0 without manually updating the FIL_PAGE_FILE_FLUSH_LSN in the system tablespace to a recent enough LSN, then scary error messages like "page LSN is in the future" may be issued. As always, if some log was discarded while some changes had already been written to data pages, all sort of corruption may occur.

If the database was initialized with a server that never updates the FIL_PAGE_FILE_FLUSH_LSN field, then any server startup attempts with a zero-size ib_logfile0 will be refused because of an invalid LSN. If that field was ever updated with a valid LSN by an older server, this safety mechanism cannot work, and the server may "rewind" to an earlier LSN.

I believe that any operations that would rebuild the redo log should be left to code that has been developed and tested. Users should not be encouraged to directly manipulate the log files themselves.

It would be great if the above was clarified in the documentation.

greenman, can you please make sure that this as well as MDEV-14425 will be documented?

Users who run performance tests (such as wlad) might want to initialize a server with test data, shut it down and then back up the files, to be restored before read/write performance test runs. That would save the trouble of loading data before each test run, and guarantee that each test is starting from the same state.

Such users could be accustomed to deleting the ib_logfile0 to save space in the backup. That used to be safe after a clean shutdown. Now that we no longer store the latest LSN anywhere else than the log file, the log file must not be deleted. To save space in the backup, the server could be restarted with a smaller innodb_log_file_size and then shut down. Alternatively, the database could be copied with mariadb-backup and prepared with mariadb-backup --prepare to create a minimal log file, and then backed up.

MDEV-27812 would allow a DBA to shrink the log file before shutting down the server. The log could simply be resized to its minimal size:

SET GLOBAL innodb_log_file_size=4096*1024;