The InnoDB redo log mostly uses physical addressing (byte offsets within a page). While
MDEV-12353 introduced a physical log format, some operations, such as inserting a record ( MDEV-21724) were optimized with special records that use some amount of logical and addressing (depending on the existing contents of the data page).
If a page that is read during redo log apply is older than what the redo log expects (if some page writes were missed for any reason), then most redo log apply operations would happily corrupt the page further. The corruption might sometimes be caught when an insert operation is being applied.
We should introduce an option to generate new
MDEV-12353 OPTION records (subtype CHECKSUM) at mtr_t::commit(). For every page that was modified by the mini-transaction, we would compute and write to the log a CRC-32C checksum of the uncompressed and unencrypted page contents, as well as the previous modification LSN of the page. The checksum would not necessarily be the same as the page checksum in data files. This checksum might not cover the FIL_PAGE_LSN field on the page, because that field would not be updated until page flushing takes place.
When ‘applying’ a CHECKSUM record, recovery (or mariabackup --prepare) would compute the corresponding checksum of the page and compare it to the one that is written to the log record. It would also compare the FIL_PAGE_LSN on the page to the one in the CHECKSUM record.