mysql_error.log
contains the following:
mariadb-10.4.32
|
2024-12-27 14:45:20 0 [ERROR] [FATAL] InnoDB: Trying to read page number 6933 in space 0, space name innodb_system, which is outside the tablespace bounds. Byte offset 0, len 16384Please check that the configuration matches the InnoDB system tablespace location (ibdata files)
|
This intentional crash on an out-of-bounds read was removed in this merge of this change, in MariaDB Server 10.6.5. The foundation for that had been laid in MDEV-13542.
It is hard to say what could cause an out-of-bounds access. I can offer a guess. Even though we reproduced MDEV-30671 and MDEV-31355 only when using innodb_undo_tablespaces>1 and innodb_undo_log_truncate=ON, I suspect that these bugs affect also the innodb_undo_tablespaces=0 case, but are harder to hit. The scenario would be that an old transaction tried to access an old version of a record, but the undo log page that contained the history had been freed prematurely and reused for something else. Then, as part of interpreting something as an undo log record, InnoDB would try to access an out-of-bounds page. This is just one possible guess.
If the server had crashed in the past, it is possible that some corruption was inflicted due to a crash recovery bug. I do not remember the bug numbers anymore, but there should be one or two reported cases of backup or recovery failing before MariaDB Server 10.5. When I redesigned the redo log record format in MDEV-12353, I noticed a few broken cases, at least related to SPATIAL INDEX, but I don’t think that it can be the problem here.
The page flushing and checkpoint logic was greatly simplified in MariaDB Server 10.5. I suspect that some hard-to-reproduce recovery or mariabackup failures in 10.4 could have disappeared thanks to that.
I think that your best option is to start the server with innodb_force_recovery=2 and use mysqldump to back up the database, and then load the dump into MariaDB Server 10.6.20 or 10.11.10 or later. If the 10.4 server would crash during the execution of mysqldump, then you should try innodb_force_recovery=3. Be aware that this may result in an inconsistent dump, because it would hard-wire the transaction isolation level to READ UNCOMMITTED.
MariaDB Server 10.4 is not supported anymore. The last release in that series was 10.4.34 in May 2024.
Hi Sergie;
I am sorry, but I am not as techy as you might think. I created a Slack account, but it says that I am not part of the team. I don't if I am supposed to do anything with your post. Thanks.