Ich wollte etwas ausprobieren und davor eine MariaDB-Datenbank sichern. In /var/lib/mysql speichert MariaDB die angelegten Datenbanken, daher existierte dort bereits ein Volume – die Sicherung wäre also nach dem Neustart des Containers nicht verloren gewesen. Da ich sie nicht dauerhaft brauchte, aber nicht riskieren wollte, sie nach einem Neustart zu verlieren, legte ich sie temporär dort ab. In einen Unterordner, den ich mit Unterstrich-Suffix benannte, damit klar war, der Ordner ist nicht von MySQL verwaltet.
Auf dem Datenbankserver fiel später beim Upgrade eine seltsam benannte Datenbank namens #mysql50#_backup-nextcloud-11.05.2023 auf:
Konnte ich mir nicht erklären und war verwundert, dass Rauten überhaupt als Datenbankname zulässig sind – da musste etwas bei der Sicherung schief gelaufen sein. Es steckte aber mehr dahinter, als eine Datenbank, die keiner braucht. Das Upgrade des Servers lief wegen genau dieser Datenbank auf Fehler:
mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD
Major version upgrade detected from 10.3.11-MariaDB to 10.5.22-MariaDB. Check required!
Phase 1/7: Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.index_stats OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.roles_mapping OK
mysql.servers OK
mysql.table_stats OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.transaction_registry OK
mysql.user OK
Phase 2/7: Installing used storage engines... Skipped
Phase 3/7: Fixing views
mariadb-check: Got error: 1102: Incorrect database name '#mysql50#_backup-nextcloud-11.05.2023' when selecting the database
FATAL ERROR: Upgrade failedEin paar Wochen sind vergangen und dass ich den SQL-Dump händisch temporär in /var/lib/mysql abgelegt hatte, war vergessen. Ich vermutete daher, die Datenbank wohl mal dupliziert zu haben und dabei durch einen Fehler die Sonderzeichen im Name gelandet sind. Die Sicherung wurde ohnehin nicht mehr gebraucht, also wollte ich sie bei der Gelegenheit gleich entfernen – was MariaDB nicht akzeptierte:
MariaDB [(none)]> drop database `#mysql50#_backup-nextcloud-11.05.2023`;
ERROR 1102 (42000): Incorrect database name '#mysql50#_backup-nextcloud-11.05.2023'Rauten sind also doch nicht erlaubt, aber sie müssen ja irgendwie rein gekommen sein. DBeaver versuchte es mit DROP SCHEMA, was jedoch zum gleichen Fehler führte. Maskieren/Escapen half ebenfalls nicht. Ich schaute daher im Datenverzeichnis von MariaDB was dort zu finden war und stieß auf einen ähnlich benannten Ordner:
find /var/lib/mysql -name \*backup\*
/var/lib/mysql/_backup-nextcloud-11.05.2023In ihm liegen aber keine für MySQL üblichen Datenbankdateien, sondern nur ein SQL-Dump – in diesem Falle nextcloud.sql. Da fiel mir die anfangs erwähnte Sicherung wieder ein, die ich testweise dort abgelegt hatte. Der Datenbankserver hatte die SQL-Datei beim nächsten Start geladen und mit #mysql50# Präfix kenntlich gemacht, dass es sich um keine echte Datenbank handelte – sondern der selbstständig geladene Export. Das war mir nicht bewusst. Wenngleich es zugegeben natürlich auch nicht die sauberste Idee war, in /var/lib/mysql selbst Daten abzulegen.
Lösen ließ sich das Problem durch herunterfahren des Datenbankservers und anschließendes Löschen des Ordners mit der Datenbanksicherung:
rm -rf /var/lib/mysql/_backup-nextcloud-11.05.2023Die nun endgültig gelernte Lektion
Das erinnert mich an ein Problem mit HCL Connections, als ich testweise eine von WebSphere zu ladende Jar-Datei umbenannt habe, um sie als Sicherung für einen Test zu behalten: Es ging schief, weil WAS sämtliche Dateien im Verzeichnis lud. Nachdem dies in ähnlicher Weise zum zweiten Mal passiert ist, lautet die gelernte Lektion nun definitiv: Keine Sicherungen mehr im gleichen Verzeichnis anzulegen, in dem eine Anwendung ihre Daten erwartet. Auch wenn man selbst denkt, dass es Filter auf bestimmte Pfade/Endungen gibt – wenn man nicht selbst der Entwickler ist, weiß man eben nicht zu 100%, ob das wirklich so ist.
Und auch wenn es in vielen Fällen funktioniert: Ausnahmen bestätigen die Regel. Diese Ausnahmen fallen einem jetzt oder später potenziell auf die Füße – damit verbringt man unnötig einige Zeit. Falls man unter Docker nirgendwo ein zweites Volume für z.B. Backups angelegt hat, muss man im Zweifel zuerst den Container stoppen und eines anlegen.
Um das abschließend noch klarzustellen, sind Rauten entgegen meiner Vermutung tatsächlich in Datenbanknamen erlaubt. Überraschend viele können genutzt werden, wenn man sie mit den korrekten Anführungsstrichen maskiert. Beabsichtigt benennen würde ich so trotzdem keine Tabelle: Es ist eine weitere potenzielle Fehlerquelle aus der selben Art von Kategorie, die meistens funktionieren, bis man Zeit mit einer Ausnahme verbringt. Muss auch nicht wirklich sein – Buchstaben und Minus bzw. Unterstrich als Trennzeichen haben bisher völlig ausreicht.
