Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.11, 11.4
Description
InnoDB crash recovery is suppressing error messages about FIL_PAGE_LSN being in the future (recv_lsn_checks_on) and instead implementing a partly duplicated logic (recv_max_page_lsn). At least ever since the recovery was refactored in MDEV-29911, we’d better always enable these checks.
Furthermore, InnoDB fails to treat a page as corrupted when it has a valid checksum but the FIL_PAGE_LSN is too large. This could lead to the database becoming increasingly more corrupted.
Attachments
Issue Links
- causes
-
MDEV-35618 Bogus assertion failure 'recv_sys.scanned_lsn < max_lsn + 32 * 512U' during recovery
- Closed
- is blocked by
-
MDEV-13542 Crashing on a corrupted page is unhelpful
- Closed
-
MDEV-29911 InnoDB recovery and mariadb-backup --prepare fail to report detailed progress
- Closed
-
MDEV-34802 Recovery fails to note some log corruption
- Closed
- relates to
-
MDEV-25909 Unnecessary calls to fil_ibd_load() slow down recovery
- Open
-
MDEV-34879 InnoDB fails to merge the change buffer to ROW_FORMAT=COMPRESSED tables
- Closed
-
MDEV-35226 InnoDB occasionally fails to recover a corrupted page from the doublewrite buffer
- Stalled
-
MDEV-35348 Missing FILE_CHECKPOINT(*) at * recovery
- Needs Feedback
-
MDEV-33670 Redo log overwritten/corrupted
- Confirmed