On Thu, Dec 8, 2022 at 6:59 PM Reindl Harald <h.reindl@thelounge.net> wrote:
Am 08.12.22 um 17:51 schrieb Gordan Bobic:
On Thu, Dec 8, 2022 at 6:43 PM Reindl Harald <h.reindl@thelounge.net> wrote:
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
How can that happen when every once in a while upgrades require a full clean shutdown with innodb_fast_shutdown=0 so that the ib_logfile* have to be rebuild due to an on-disk format change?
in my whole life from MySQL 5.0 (the frist time i built mysql with innodb support at all) to MariaDB 10.3 i didn't do anything then upgrade, restart service and be done
I don't have an explanation for that, short of pure luck, in the fact that the log was naturally empty because everything had been flushed to disk at the point you upgraded. You should play the lottery more often if your luck is that good. Mine certainly isn't.
More to the point, if that is a concern, why can you not shut down cleanly with innodb_fast_shutdown=0, rm the files, and let MariaDB re-create them completely clean and empty?
don't ask me why that shit can't be removed automatically over 13 years - the reference to './dbmail/#sql2-704-271.ibd' lives somewhere in the "global tablespace" which shouldn't exist at all
I have seen phantom InnoDB tables like that before, but never ones that coiuldn't be cleared with a simple "drop table". Does it show up in innodb_sys_tables or innodb_sys_tablespaces?