Die Übersicht über den Zustand des Datenbank-Servers zu behalten, zählt sicherlich zu den wichtigsten Aufgaben eines jeden DBAs. Wie bei den meisten Datenbankprodukten erfolgt diese Kontrolle über ein Fehlerprotokoll, das sogenannte „Error-Log". Dabei handelt es sich um eine ASCII-Log-Datei, die sich (je nach Betriebssystem oder Konfiguration) in einem bestimmten Pfad des Servers befindet.
Mit der Version 8.0.22 gibt es nun eine weitere Möglichkeit, um an diese Informationen zu gelangen.
Fehler machen und verstehen…
Ab der Version 8.0.22. kann auf die aktuellen Inhalte, quasi über eine Art „Online-View", über die Tabelle „performance_schema.error_log" zugegriffen werden.
Die Tabelle beinhaltet exakt dieselben Informationen, wie die Einträge der bekannten ASCII-Log-Datei.
Über das neue „SQL-Interface" in die Error-Log Welt können jetzt natürlich komfortable Auswertungen erfolgen:
Schauen wir uns einmal die jüngsten drei Fehlermeldungen des Systems an:
Auf diesem System scheint sich noch jemand mit einem veralteten Password-Algorithmus anmelden zu wollen (Error-Code „MY-013360"). Gesetzt den Fall, dass uns dieses Problem bekannt ist und wir es gerne ignorieren würden, steht eine entsprechende Systemvariable bereit, über welche sich Fehlermeldungen filtern lassen können:
Ab diesem Moment wird der Fehler „MY-013360" nicht mehr verarbeitet. Natürlich können durch Kommata getrennt weitere Fehler-Code berücksichtig werden.
Schiffe
Der interne Fehlerprozess besteht in den aktuellen 8er-Version nun aus einem zweistufigen, konfigurierbaren (!) Prozess:
- Fehler filtern
- Fehler schreiben
Was innerhalb dieser beiden Schritte passiert, wird über die Variable „log_error_services" bestimmt:
In unserem Beispiel kümmert sich das Plugin „log_filter_internal" auf Basis von „log_error_supression_list" um das Filtern der Fehlermeldungen. „log_sink_internal" ist für die Speicherung der Fehlermeldungen im „error_log" verantwortlich. Das Wort „Plugin" stellt bereits in Aussicht, dass hier Veränderungen möglich sind.
So kann beispielsweise die „Datensenke" verändert und sogar erweitert werden. Bevor jedoch andere Plugins genutzt werden können, müssen diese geladen werden.
Diese Einstellung bewirkt nun, dass die Daten an drei Stellen geschrieben werden:
- Im klassischen Error-Log
- Im JSON-Format
- Im System-Eventlog des Betriebssystems (da gab es auch schon vorher; mysqld_safe —syslog ;-) )
Auch für den „Fehler-Filter" gibt es eine alternative Erweiterung (Plugin): „log_filter_dragnet"
Hierbei handelt es sich um einen regelbasierten Filter (z.B: mit IF-THEN-ELSE Strukturen), über den komplexere Mechanismen abgebildet werden können. Die genaue Funktionsweise inkl. der Syntax und einige Beispiel ist unter der folgenden URL zu finden: https://dev.mysql.com/doc/refman/8.0/en/error-log-rule-based-filtering.html
Lektion gelernt?
Es ist erfreulich zu sehen, dass auch abseits der großen Features (InnoDB-Cluster, MySQL Shell,….) im Detail Optimierungen vorgenommen werden. Eine „detailliertes" Fehlermanagement ist sicherlich kein „Fehler" (!) und hilft dem einen oder anderen DBA die Betriebsprozesse zu optimieren.
Sie haben Interesse an einer Weiterbildung oder Fragen zum Thema MySQL? Sprechen Sie uns an oder besuchen Sie einen unserer Kurse aus unserem Seminarshop:
Zu unseren MySQL Seminaren