Wenn man, wie ich, beim Systemstart das komplette /var – Verzeichnis in einer RAM-Disk spiegelt, was die RAM-Disk per mount bind einfach über das Originalverzeichnis legt, kann bei MySQL Probleme bekommen.
Problem
Bei dem Befehl create database DATENBANKNAME; und anschließendem use DATENBANKNAME; wurde gemeldet, dass diese Datenbank, die ich ja gerade angelegt hatte, nicht existiert. Ein Blick in’s Dateisystem bestätigte das auch. Durch dummen Zufall schaute ich auch in’s überlagerte Festplatten-Verzeichnis und fand dort die eben angelegte Datenbank.
Außerdem fiel auf, dass sämtliche Änderungen in der mysql-Tabelle, also Benutzer anlegen, Rechte vergeben etc, keinerlei Wirkung hatten. Auch hier wurden alle Daten direkt in das überlagerte Verzeichnis geschrieben. Beim Lesen der Daten wiederum wurde die RAM-Disk verwendet.
D.h. sämtliche Änderungen wurden mit OK quitiert, aber geändert hat sich nichts, denn beim Auslesen wurden immer die Daten von der RAM-Disk genommen.
Bei der Änderung von normalen, schon bestehenden Datenbankdaten, z.B. beim anlegen von Tabelle oder ändern von Inhalten, funktionierte alles korrekt.
Ursache
Wie schon damals beim Umzug des MySQL-Datenverzeichnisses hatte ich meinen Freund apparmor in Verdacht. Ich weiß nicht genau, diese Anwendung arbeitet, aber in der Konfig.-Datei werden die Verzeichnisse angeben, in die die jeweilige Anwendung schreiben darf.
Ausgehend von meiner Konfiguration mit dem Überlagern mit der RAM-Disk müssen in die Datei
/.disk2ram/var.volatile/lib/mysql/ r,
/.disk2ram/var.volatile/lib/mysql/** rwk,
/.disk2ram/var.state/lib/mysql/ r,
/.disk2ram/var.state/lib/mysql/** rwk,
Danach kann man MySQL auch wieder vernünftig verwenden, hoffentlich 😕
Nachtrag: es gibt immer noch untragbare Probleme (z.B. einen Komplett-Crash von MySQL) in dieser Konfiguration. Ich bin noch an der Lösung dran…