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
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 # mysqld to syslog and skip known erroes from crash 2009 if $programname == 'mysqld' then { :msg, contains, "[ERROR] InnoDB: Cannot open datafile for read-only: './dbmail/#sql2-704-271.ibd'" stop :msg, contains, "[ERROR] InnoDB: Could not find a valid tablespace file for ``dbmail`.`#sql2-704-271``" stop :msg, contains, "[ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them" stop :msg, contains, "[ERROR] InnoDB: Operating system error number 2 in a file operation" stop :msg, contains, "[ERROR] InnoDB: The error means the system cannot find the path specified" stop :programname, isequal, "mysqld" -/Volumes/dune/www-servers/_logs/mysql_error.log :programname, isequal, "mysqld" stop }