On Thu, Dec 8, 2022 at 6:42 PM Reindl Harald <
h.reindl@thelounge.net> wrote:
> WTF - but that don't change anything - you just can't dump+restore multi
> GB large databases in production environments and i expect from a new
> software version that it simply can read it's older data
Yes, I fully agree with that sentiment. Being able to upgrade without logical dump and restore has always been part of the design philosophy.
> and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which
> hold data even in file-per-table mode you can't cleanup from crap caused
> by a crash 13 years ago
In MySQL 5.6.8 I fixed the bug that you could not change innodb_log_file_size or innodb_log_files_in_group afterwards. With that fix, we would safely create new logs on server startup.
MariaDB 10.2 changed the minimum value of innodb_log_files_in_group to 1, and 10.5 hard-wired it to that value.
Starting with MariaDB 10.9, you can
SET GLOBAL innodb_log_file_size while the server is running. A second log file will be created, to replace the
ib_logfile0 at the earliest opportunity (completion of a log checkpoint).
> and what happens over the long with data that has no checksums at all
> because it was possible to completly disable them in the past?
It is anyone's guess. For added benefit, one might also disable the doublewrite buffer without testing that torn writes actually are impossible, and then complain that InnoDB crashes on a corrupted page. MDEV-13542 and some related changes recently fixed (most of) that in 10.6.
Files that were created while innodb_checksum_algorithm=full_crc32 was in effect will always use that checksum format, even if you try to disable checksums afterwards. OK, you can only do that in 10.4 or 10.5; MDEV-25105 in 10.6 removed the innodb_checksum_algorithm values "none" and "innodb".
Regarding the dbmail/#sql2-704-271.ibd in your other message, in MariaDB 10.5 or later you should be able to drop the table even if a .frm file does not exist, with
DROP TABLE dbmail.`#mysql50##sql2-704-271`;
If you are using an older version, you could try to copy the .frm file of another InnoDB table to that name, and then remove the file.
DDL operations should be crash-safe and most of them are atomic starting with MariaDB 10.6.
Marko
--
Marko Mäkelä, Lead Developer InnoDB
MariaDB Corporation