Archivierungsfunktion crashed Datenbanken

Ich kämpfe mich jetzt schon mehrere Monate mit einem schwerwiegenden Problem bei Matomo ab, das nach jedem Server Neustart zu einem Crash aller Matomo Datenbanken führt. Das Problem ist nicht gänzlich neu und wenn man Google und das Forum lang genug durchsucht, tritt das bezeichnete Problem auch in anderen Konstellationen auf. Von daher verwundert es mich, dass nicht mehr Nutzer darüber klagen.

Um den Hergang des Problems näher zu beschreiben ein paar Infos vorab. Zur Archivierung verwende ich einen Cronjob nach Maßgabe von Matomo mit 900 Sekunden Intervall und das bei einem halben Dutzend an Matomo Installationen. Meine Datenbank Konfiguration ist nahezu Standard. Die indiviuellen Änderungen beziehen sich alle auf nicht InnoDB Datenbanken, jedoch verwende ich ebenso nach Maßgabe von Matomo die LOAD DATA INFILE Einstellung und genau diese scheint die Ursache dafür zu sein, dass nach einem Server Neustart alle Matomo Datenbanken nach dem Neustart zerstört sind.

Um das Problem einzugrenzen, habe ich vor dem Neustart zunächst mal den Tracker Code entfernt, dann alle Cronjobs vorübergehend deaktiviert und dann nochmal geprüft, ob es nicht doch noch einen laufenden Prozess gibt. Erst dann habe ich den Neustart gemacht, aber keinen harten, sondern einen graceful restart, damit auch alle Tabellen und Verbindungen geschlossen sind. Gehe ich diesen Weg, passiert nix und nach dem Neustart läuft alles wieder problemlos nachem ich alles wieder aktiviert habe.

Mache ich diese Änderungen nicht, kommt es zu dem besagten DB Crash und das nur bei den Matomo DBs.

Besonders auffällig ist, und das deutet ein weiteres Mal auf die Archivierungsfunktion hin, dass sich der MySQL Server manuell nicht stoppen lässt, wenn ich das oben beschriebene nicht vorher durchführe. Da kommt man jetzt zu der Schlussfolgerung, dass auch mit einem graceful restart doch nicht alles so abläuft, wie gedacht und Verbdindungen nicht geschlossen werden. Ansonsten ließen sich die Auswirkungen nur schwer anders erklären.

Die Problematik mit den zerstörten Datenbanken bestand seit dem ersten Auftreten nicht schon von Beginn an. Anfänglich gabs nach dem Neustart “nur” ein Problem mit einer offensichtlichen ge-lockten ibdata1 und der MySQL Server nicht kapiert hat, dass die ibdata1 gar nicht gesperrt ist. Das ließ sich aber noch vergleichsweise einfach lösen, musste aber nach jedem Neustart immer und immer wieder gemacht werden.

Zuletzt saß der cPanel Support 4 Std. an dem Problem dran, ohne dass sich daraus eine Lösung ergab und man mich dann zu Matomo verwiesen hat, weil alles darauf hindeutet, dass die Archivierungsfunktion die Ursache dafür ist.

Hallo,

Ich muss zugeben, meine Erfahrung mit Datenbanken beschränkt sich auf meinen eigenen Server und ich habe dort noch nicht oft mit beschädigten Daten zu tun gehabt.

Aber Matomo sendet nur SQL queries an den Server, was egal wie falsch diese sind, niemals dazu führen darf, dass die Datenbank beschädigt wird. Wenn das passiert, dann ist das somit eher ein Bug in der Datenbank.

Ich würde empfehlen einmal nachzuschauen, ob es Updates für MySQL gibt, die potenziell ein derartiges Problem korrigieren. Vielleicht ist auch in der Konfiguration irgendetwas nicht korrekt eingestellt.

Ich bin was Updates anbetrifft aktuell und nachdem sich die Problematik auf Matomo reduziert, bzw. sich noch weiter auf die besagte Archivierungsfunktion reduziert, kann man MySQL selbst ausschließen. Ich bin jetzt auch nicht der Datenbank Experte, aber vor dem Hintergrund, dass Matomo (InnoDB) viel mit Speicher macht und vor einem Server Neustart alles was sich noch flüchtig im Speicher befindet irgendwie so beendet werden muss damit es zu keinem Datenverlust oder gar einer Datenbank Zerstörung kommt, muss der Wurm darin liegen. Im Moment arbeite ich mich etwas in die Thematik der max-open-files. Die Fehlermeldungen spucken nicht wirklich viel Informationen aus, aber mit den max-open-files habe ich zumindest einen ersten Ansatz.

Auch wenn ich es schon erwähnt habe, die Thematik ist nicht generell neu. Zwar nicht unmittelbar was die Zerstörung der DB anbetrifft, aber eine einfache Suche nach Matomo/Piwik und Tabellen, die nicht geöffnet/gefunden werden können, bringen auch hier im Forum einige Treffer hervor.

Hallo, eine zerstörte Datenstruktur liegt sicher nciht an der Archivierung oder Datenimports, sondern sind immer verursacht durch falsche Einstellungen von MySQL / MariaDB oder des darunterliegenden Dateisystems. Wenn man durch Abfragen die Datenbank crashen lassen / zerstören könnte, wäre das ein eklatanter Bug.

Poste doch mal Deine Konfiguration, Serverattribute, MySQL / MariaDB Version, Mountoptionen des Dateisystems (/etc/fstab), Dateisystem auf dem die Datenbank liegt (/var/lib/mysql) -> #: df -h oder blkid sind die Befehle.

Tabellen, die nicht geöffnet/gefunden werden können, bringen auch hier im Forum einige Treffer hervor.

Das sind andere Themenbereiche (Software-Updates, die ihre Schema-Änderungen nicht komplett durchgeführt haben). Zerstörte Datenstrukturen sind etwas ganz anderes.

Im Moment arbeite ich mich etwas in die Thematik der max-open-files

Das ist auch eine ganz andere Baustelle und hat damit sicher nichts zu tun. Das ist nur die Anzahl an File descriptors, die MySQL / andere Dienste maximal öffnen dürfen.

Wie genau äußert sich der “Crash”?

Viele Grüße

Dadurch, dass einerseits eine bestimmte Menge an Tabellen nicht mehr vorhanden ist und zahlreiche andere gesperrt scheinen.Darüberhinaus glaubt MySQL, dass ibdata1 gelockt wäre. Letzteres lässt sich durch Kopieren und Wiederherstellen dergleichen zwar lösen, aber das rettet nicht die zerstörten Datenbanken.

Mag sein, aber das ist das einzige, was überhaupt einen Anhalt gibt und ich könnte damit gar nicht mal daneben liegen, weil zumindest bis jetzt weitere Neustarts die Datenbanken nicht mehr zerstören lässt.

Niemals sollte man manuell im /var/lib/mysql Verzeichnis herumkopieren. Lockings von Tabellen haben durchaus ihre Berechtigung. Dabei kann es zu Deadlocks kommen, aber nur in sehr seltenen Fällen. Und selbst diese werden nach einigen Sekunden gelöst und die Transaktion(en) zurückgerollt.

Das liegt weder an Matomo, noch an MySQL. Es kann passieren, dass eine Tabelle ihre Integrität verliert, aber dass sie einfach weg ist, ist nicht möglich. Eine längere Neustart-Dauer von MySQL liegt übrigens nicht an Matomo, sondern an MySQL selbst. Wir haben hier riesige Instanzen im Einsatz, die für einen Neustart > 30 Minuten benötigen. Je größer die trx-logs und der buffer_pool (und damit auch dirty pages), desto länger benötigt es. Das ist aber genau so, wie es sein soll.

Das klingt schon nicht schlecht - vielleicht wurde in dem Zuge das Problem an anderer Stelle behoben. Hauptsache: Niemals selbst im /var/lib/mysql Verzeichnis zu schaffen machen, außer man weiß genau, was man tut.

@peterbo
Ich mag ja bedingt verstehen, dass Du versuchst Matomo als Übeltäter auszuschließen, aber wenn bei unzähligen Anwendungen sich nur Matomo und die damit verbundenen Datenbanken als ausschließlich betroffen herauskristallisieren, ist es ehrlich gesagt schwer den Fokus auf was anderes zu richten.

Wenn Du mit dem Finger wedelst, dass man dies und jenes bloß nicht machen soll, aber eben die einzige Lösung darin besteht die ibdata1 zu sichern, um sie dann wiederherzustellen, um die Sperre aufzuheben, dann ist es eben so. Das mag ein Problem von MySQL sein, aber MySQL ist nicht die Ursache. Von nichts kommt bekanntlich nichts.

Das mit den open-files hat sich übrigens nachhaltig auch auf andere diffuse Fehler ausgewirkt, sodass MySQL jetzt nur noch sporadisch Fehler ins Logfile schreibt, die sich aber alle und immer auf die InnoDB Datenbanken von Matomo beziehen und bezogen haben.

Aus meiner Sicht ist nicht ganz von der Hand zu weisen, dass die Archivierungsfunktion eine wie auch immer geartete Dysfunktion hat.

Ganz im Gegenteil. Da ich weit über 100 Instanzen betreue, bin ich nicht verlegen darum, mit dem Finger auf Bugs zu zeigen, die da, wie in jeder anderen Software auch, im heavy-user Bereich zahlreich sind. Nur ist es nicht möglich, MySQL durch die Verwendung von Abfragen “crashen” zu lassen, außer es gibt einen Bug in MySQL, oder man hat es so falsch konfiguriert, dass der Server aus dem Memory läuft.

Ich sehe eben, dass Du Deinen Motor aus- und wieder einbaust, nur weil Du Dein Autoradio neu starten möchtest. Der Ansatz ist einfach falsch und man kann sehr viel kaputt machen, aber da muss jeder seine Erfahrung sammeln. Aber Du postest ja auch keine Fehlermeldungen, oder Selects, die ggf. auf Deadlocks schließen lassen, d.h. wir bewegen uns gerade im Bereich von Spekulation. Du hast noch nicht mal die eingesetzten Versionen gepostet, aber hast zwei Leute im Thread, die dir definitiv helfen könnten.

Das mit der vermeintlich gesperrten ibdata1 ist kein isoliertes Problem, das ich mir ausgedacht habe, sondern findet sich in unzähligen anderen Situationen (nicht nur bei mir) ebenso. Und muss ich es leider nochmal sagen, wenn das error_log für MySQL als einzigen Anhalt entweder die gesperrte ibdata1 && ein Problem mit den open-files auswirft, dann ist es schwer nach anderen Ursachen Ausschau halten zu können. Genauso wenig kann ich hier etwas posten, was es nicht gibt. Da hat sich cPanel Support schon 4 Std. lang die Zähne dran ausgebissen und die sollten es eigentlich wissen. Nicht, dass ich für Hilfe nicht dankbar wäre, aber Du wirst mir rechtgeben müssen, dass man das nur vor Ort am Server wenn überhaupt herausfinden kann, was die Ursache sein könnte. Alles andere verläuft nur in Spekulationen und das hilft keinem weiter.