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

[Jakub Lopuszanski]

The failure is about:
```
if (file.m_header.m_start_lsn != expected_start_lsn) {
const auto file_path = log_file_path(files_ctx, expected_file_id);
ib::error(ER_IB_MSG_LOG_FILE_INVALID_LSN_RANGES, file_path.c_str(),
ulonglong{file.m_header.m_start_lsn},
ulonglong{expected_start_lsn});
return false;
}
```
where `file.m_header.m_start_lsn` is as the name suggests read from file's header (presumably the file is #innodb_redo/#ib_redo27250), while the `expected_start_lsn` is computed based on previous file's start_lsn and length:
https://github.com/mysql/mysql-server/blob/mysql-8.0.30/storage/innobase/log/log0files_dict.cc#L250-L277 expected_start_lsn);
which is a matter of simple arithmetic: take file size, subtract 2KB (the header size) and add it to the start_lsn.

The reason we stop Innodb is that if m_start_lsn is not matching expected lsn, then something is really really wrong with the redo log - it is not forming a single sequence of bytes, but either misses some part, or have two files overlapping (which seems to be your case as 445648380928 is larger than 445543588864).
You really don't want to boot InnoDB without a fragment of redo log, or corrupted redo log as this will mean a portion of changes to your tablespace files is missing or corrupted, which in turn means your table will probably be in corrupted state afterwards.


1. Are you perchance using Ubuntu 20.04 and ZFS?
I ask because investigation of https://bugs.mysql.com/bug.php?id=108012 shown that there's a bug in this particular Ubuntu+ZFS combination resulting in fallocate not working as it should, which would be one way to explain what you are seeing. In this bug comments you'll find a test you may perform on your machine to see if it is affected.

2. Could you share `ls -lh ./#innodb_redo` so we can see the sizes of redo log files on your disk?

3. Also, could you please run:
xxd -l 512 '#innodb_redo/#ib_redo27250'
and
xxd -l 512 '#innodb_redo/#ib_redo27249'
so that we can see headers of these files?

4. Did you perhaps modified/moved/copied/unpacked the files "manually" somehow? Or perhaps used some backup/restore utility? Anything that could explain how come the files have content different than InnoDB expects?

5. Did you modify https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_redo_log_capacity before the crash?


6. Could you please report the issue via https://bugs.mysql.com/bug.php so it is easier for us to track than a forum thread?

Thanks for reporting the problem, and thanks in advance for help in investigating it,
Kuba