maria-discuss team mailing list archive

[Gordan Bobic <gordan.bobic@xxxxxxxxx>]

On Thu, Dec 8, 2022 at 6:59 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>
>
>
> Am 08.12.22 um 17:51 schrieb Gordan Bobic:
> > On Thu, Dec 8, 2022 at 6:43 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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?