MySQL-Crashursache gefunden: HUP-Signal bei MySQL ist kein Neustart

Bei der Erstellung des Scripts zum Spiegeln von /var in eine RAM-Disk habe ich, aus Mangel an Wissen und Erfahrung, das HUP-Signal benutzt um alle Prozesse, die unterhalb von /var ein offenes Filehandle haben, neu zu starten, damit die Überlagerung keinen Datenmüll ergibt. Bei ein paar, z.B. den klogd, hat das von vornherein nicht funktioniert, weswegen die explizit über ihr Init-Script neu gestartet werden.

Bei MySQL hat es nur scheinbar funktioniert, denn der Grund für den Crash von MySQL war genau das nicht neustarten. Der MySQL-Server hatte noch offene Filehandles auf dem Festplatten-Verzeichnis, dann hat die RAM-Disk das Verzeichnis überlagert und alle dann geöffneten Filehandles zeigten auf die RAM-Disk. Das Resultat war, wie zu erwarten war, Datenmüll.

Bei dem Script für die RAM-Disk ist MySQL jetzt auch explizit per Init-Script neu gestartet und das Ganze wurde von mir ausgiebig getestet: seit dieser Änderung bestehen keine Probleme mehr.

Jetzt muss ich mir nur noch überlegen, wie ich alle laufenden Prozesse mit Filehandles in /var dazu bringen kann, sich komplett neu zu starten. Derzeit fällt mir, außer Signalen, nichts ein, denn automatisch auslesen kann ich nur die PID und die Namen der Prozesse.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert