maria-discuss team mailing list archive

[Marko Mäkelä <marko.makela@xxxxxxxxxxx>]

On Thu, Dec 8, 2022 at 6:42 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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).

On upgrades from earlier versions to 5.7 or 10.2 or later, to 10.5 or later
(MDEV-12353), or 10.8 or later (MDEV-14425), the log files will be rebuilt.

> 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