Re: Failed to start mysql due to start_lsn and ens_lsn issue

[Jakub Lopuszanski]

> 2022-08-09T08:13:32.541775Z 1 [ERROR] [MY-011971] [InnoDB] Tablespace 'mysql' Page [page id: space=4294967294, page number=5] log sequence number 445647663343 is in the future! Current system log sequence number 445646996579.

This error means you are in really bad situation, because apparently the #ib_redo27249 is missing some data it should really have in it.
InnoDB strictly follows "the WAL rule", which is that it never writes to disc a dirty page which has changes from lsn higher than the last lsn guaranteed to be already fsynced to redo log.
But here, we see that the page on disc contains changes from lsn=445647663343, while the redo log ends at 445646996579.
Comparing this 445646996579 to the values we've seen in your earlier messages, we see that it belongs to the range for #ib_redo27249, as #ib_redo27249's header indicates start_lsn=0x67c284ac00 and the file seems to have 3276800 bytes (which is sufficient to hold 3274752 lsns), so this file is responsible for the range from 445645106176 (=0x67c284ac00) to 445648380928 (=0x67c284ac00+3274752 ).
In other words: the changes we see already reflected in the tablespace page correspond to offset 2557167 in the redo log file, yet the redo log file ends abruptly at offset 1890403. (Also, from the fact InnoDB tried to create #ib_redo27250 file, we can deduce that at some point InnoDB has filled whole 3274752 of it with data, which is somehow missing now).

InnoDB does not permit such things to happen - it makes sure fsync() is called on redo log file after a write with sufficiently high lsn to it, and before writing dirty page to disc with such lsn.

The only explanation I have for all the symptoms you describe here is that somehow your LVM drive is not respecting fsync()s.

(Alternatively: perhaps you've recovered the files from some inconsistent snapshot)

Q1. Can you share some more details about your LVM configuration?



As for the performance_schema.innodb_redo_log_files being inaccessible, don't worry about it.
AFAIU the queries were performed with innodb_force_recovery=6, a mode in which InnoDB goes into read only mode, and in the read only mode we have:
```
static bool log_pfs_should_create_tables() { return !srv_read_only_mode; }
```
so this table is not "created" in read only mode.
Perhaps, I should clarify, that this table is not a "real" table, like you know, some InnoDB table on disc.
It's just a virtual table created in memory to expose internal server state in a form of nice SQL table.
You can't really insert anything to it, or modify it.
It just reflects some C++ arrays and variables, etc.