MySQL Risiken bei Stromausfall minimieren

Datenbanksysteme Allgemeines
1

Hallo zusammen

Bin aktuell mit mit einem Hausautomations-System beschäftigt, wo u.A. MySQL eingesetzt wird. Nun ist es so, dass dieses nicht auf einem “normalen” Computer läuft sondern auf einem embedded-System. Und dort läuft Linux (auf ext4) sowie MySQL (InnoDB) drauf.

Frage: Wie lässt sich das Risiko minimieren falls der Anwender dem Gerät den Strom entfernt? Es ist dabei nicht vorgesehen dass man einen Zugriff auf das Linux-System hat - weder über “normale” Ein- und Ausgabemöglichkeiten wie Tastatur und Bildschirm (hat sowieso kein Desktop, die Maus ist nicht mal für die Entwickler ein Thema) noch über SSH.

Zwar ist es vorgesehen dass im Web-GUI (für die Administration) ein Button zum Herunterfahren drin sein soll, aber was ist wenn das Gerät “einfach so” vom Stromnetz getrennt wird?

Welche MySQL-Optionen hätte man dafür, um ein solches Risiko möglichst klein zu halten? Mir ist natürlich klar, dass relationale Datenbanken grundsätzlich nicht dafür geeignet sind - insbesondere dann wenn oft geschrieben, und nicht nur hauptsächlich gelesen wird.

  • Alle DB-Operationen welche aus mehreren Schritten nacheinander bestehen als Transaktion auszuführen. Aber was passiert dann, angenommen der Strom wird zwischen mehrerern SQL-Anweisungen in der Art lesen/ändern/löschen gekappt? Ich gehe von einem Rollback aus nach einem Stromausfall, und nicht von einer erneuten Ausführung der ganzen Transaktion?

  • Welche InnoDB-Optionen könnte man zwecks Risiko-Minimierung (NICHT “Verhinderung”) anpassen? https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html

  • Ich habe mir überlegt, sämtliche Caching-Features für InnoDB auszuschalten, aber so einfach ist das leider nicht. Z.B. Macht das Ausschalten der Option “innodb_doublewrite” das Problem nur noch grösser - kann offenbar sogar zum Problem werden wenn das System noch mit Strom versorgt wird. -> https://dba.stackexchange.com/questions/86636/when-is-it-safe-to-disable-innodb-doublewrite-buffering -> “Only if data are not important. Disabling double write buffer not only breaks ACID compliance, but also can (and eventually will) corrupt InnoDB tablespace”

(Natürlich muss dabei in der Doku für den Endbenutzer ausdrücklich darauf hingewiesen werden dass man UNBEDINGT das System per Web-GUI herunterfahren muss!!)

Danke für eure Tipps!

Mit freundlichen Grüssen,
Jan

2

Obwohl es im Internet einige Beiträge dazu gibt, scheint es keine wirklich einheitliche Meinung zu haben was nun das “geringste Übel” ist:

  • hxxps://dba.stackexchange.com/questions/12611/is-it-safe-to-use-innodb-flush-log-at-trx-commit-2
  • hxxps://stackoverflow.com/questions/43605130/power-failure-and-mysql-crash
  • hxxps://forums.mysql.com/read.php?22,604726,604726

Zugegeben - ich bin jetzt auch kein MySQL-Crack und muss mich wohl noch weiter damit befassen. Allerdings ist scheinbar davon auszugehen, dass die default-Werte “relativ sicher” sind. Sehe ich das möglicherweise richtig?

Mit freundlichem Gruss,
Jan

3

Geht es denn nur um die MySQL-Ebene oder auch um etwas „Zusätzliches“?

Risiko bei Stromausfall… bin mir nicht sicher, ob das risiko „vollständig“ vermeidbar ist.

Die Links sind auf jeden Fall gut, wenn dort keine Antwort auffindbar, dann wüsste ich nicht, wo. :frowning:

Edit:

Mist, „partielles“ Lesen. :frowning:

4

Hallo CyborgBeta

Vielen Dank für Dein schnelles Feedback!

Also das Betriebssystem sollte das aushalten, wie es ein Router auch tut. Ferner ist keine mech. Festplatte drin, also kein Lese-/Schreibkopf.

Somit geht es (bis jetzt zumindest, da sonst mit keinen anderen Teilen des Systems Probleme festgestellt wurden) eigentlich nur um MySQL…

Ich bin mir absolut sicher, dass das nicht vollständig vermeidbar ist.

"Mist, “partielles” Lesen. :frowning:"

Kein Problem!! :wink:

Habe noch im MySQL-Forum nen Beitrag geschrieben: MySQL :: How to disable write cache in every way on mysql / innodb?

Mit freundlichem Gruss,
Jan

5

Auch “FLUSH TABLE(S) …, …, … FOR EXPORT;” scheint nicht wirklich eine Lösung zu sein: https://forums.mysql.com/read.php?22,668719,668776#msg-668776

Gruss,
Jan

6

"Aber was passiert dann, angenommen der Strom wird zwischen mehrerern SQL-Anweisungen in der Art lesen/ändern/löschen gekappt? Ich gehe von einem Rollback aus nach einem Stromausfall, und nicht von einer erneuten Ausführung der ganzen Transaktion?"

7

Eine Transaktion die nicht committed wurde, ist nicht passiert :wink:

Das heisst wenn das sich System mitten in einer Transaktion stirbt und danach wieder da ist, ist diese unterbrochene Transaktion eben nie passiert :wink:
Wie du siehst, sind Transaktionen sind relativ einfach zu handhaben.

Das RDBMS an sich kann sich allerdings verschlucken, genauso wie das Dateisystem und das ganze OS wenn der Saft einfach so mal weg ist, am besten das verhindern :wink:
Fuer richtige Server etc. gibt es ja UPS die dem System ein Signal schicken damit es sich kontrolliert herunterfaehrt wenn der Strom laenger wegbleibt, also die Akku Laufzeit dem Ende zugeht und immer noch kein Netz verfuegbar ist, vielleicht gibt es ja sowas fuer dein Embeddedsystem auch.

Zum Schluss sollte man immer einen (Wartungs-) Fachmann fuer solche komplexen Systeme haben, die laufen eben nicht von selber einfach so fuer immer falls mal eine gewisse Komplexitawet ueberschritten wurde.

Man sollte sich auch Gedanken machen wie man einen kompletten"Factory Reset" einbaut und wie wichtig sind denn diese Daten?
Stirbt jemand wenn diese Daten weg sind? Falls ja, sollte man viel mehr Aufwand betreiben um diese zu sichern :wink:

8

Hallo Maki!

Vielen Dank für Dein Feedback.

„Eine Transaktion die nicht committed wurde, ist nicht passiert :wink:“

Alles klar… habe zuerst gedacht dass es sein könnte dass es nur ein Rollback gibt wenn eine einzelne SQL-Anweisung (CREATE, UPDATE, DELETE) einen Fehler wirft. Und eben möglicherweise nicht im Fall eines sonstigen Unterbruchs wie einem Stromausfall - dass dann die Transaktion inkl. Commit beim nächsten Start des DB-Dienstes vollzogen wird.

„Wie du siehst, sind Transaktionen sind relativ einfach zu handhaben.“

Ja, das scheint nicht allzu kompliziert zum Begreifen zu sein! :wink:

„Das RDBMS an sich kann sich allerdings verschlucken, genauso wie das Dateisystem und das ganze OS wenn der Saft einfach so mal weg ist, am besten das verhindern :wink:“

Es handelt sich um ein Raspi (momentan 3 B, später wohl 3 B+) unter Raspian 9 „Stretch“. Frage: Wie ist denn das z.B. bei Routern. Ich meine die haben auch nen Schalter, und keinen Taster. Also Strom weg, ohne Herunterfahren. Und meist ist auch ein Linux-System drauf. Dort gibt’s ja auch nie Probleme damit. (Die haben zwar keine DB drauf, aber Deine Antwort bezieht sich ja auch auf’s OS)

„Fuer richtige Server etc. gibt es ja UPS die dem System ein Signal schicken damit es sich kontrolliert herunterfaehrt wenn der Strom laenger wegbleibt, also die Akku Laufzeit dem Ende zugeht und immer noch kein Netz verfuegbar ist, vielleicht gibt es ja sowas fuer dein Embeddedsystem auch.“

Könnte man implementieren, ja.

„Zum Schluss sollte man immer einen (Wartungs-) Fachmann fuer solche komplexen Systeme haben, die laufen eben nicht von selber einfach so fuer immer falls mal eine gewisse Komplexitawet ueberschritten wurde.“

Mein Team und ich sind nicht Anwender, sondern Entwickler des Systems.

„Man sollte sich auch Gedanken machen wie man einen kompletten"Factory Reset“ einbaut und wie wichtig sind denn diese Daten?"

Es gibt die Möglichkeit, ein Backup zu machen. Des Weiteren gibt’s eine Möglichkeit eines Redundanz-Clusters, mit Master-/Slave-Ansatz. (Auf Ebene der lokalen Geräte, für den Fall wenn der Master defekt geht oder das darauf System abstürzt - aber das ist ein anderes Thema…)

„Man sollte sich auch Gedanken machen wie man einen kompletten"Factory Reset“ einbaut und wie wichtig sind denn diese Daten?"

Eine Option um das System in den Initialzustand zurücksetzen ist aktuell nicht implementiert, jedoch natürlich was um einen Restore des Backups zu machen. Der setzt das Gerät vorher zurück.

„Stirbt jemand wenn diese Daten weg sind? Falls ja, sollte man viel mehr Aufwand betreiben um diese zu sichern :wink:“

Evtl. mein Vorgesetzer an einem Herzinfarkt, falls zuviel schief läuft bei den ersten Kunden mit Version 1.0.0! :wink:

Grüsse,
Jan

9

Ich meine schon dass die Endnutzer zugriff auf Fachpersonal (= du & das Team) haben sollten.

Der Pi hat schon SD Karten zerschossen wegen Spannungsschwankungen, selten die HW kaputtgemacht, oft aber das Dateisystem unbrauchbar gemacht.

Erklaer deinem Vorgesetzten mal wie das ist mit Innovationen: Die ersten 48 mal funktionieren die selten :wink:

„Raspi Pi UPS“ spuckt genug Ergebnisse aus, sind wie alles um den Raspip Pi meist Bastelloesungen, Raspi Pi ist ja genau das: Eine Bastelplattform zum spielen

10

Die haben ein Flash, RAM und anderen Speicher mit einer internen Firmeware.

Die interne Firmeware bootet das eigentliche Betriebssystem (dazu RAM). Ist das Betriebssystem Schrott, ist das Gerät noch immer über die Firmeware zu erreichen. Sämtliche Speicheraktionen werden ebenfalls in einem Flash oder SD-Karte (oder was auch immer) durchgeführt. Alles das was ihr benötigt hat der Raspberry nicht und wird es auch nie haben.

Klar, man kann den Crash der SD-Karte durch Schreibschutz verhindern, aber dann muss die DB woanders gespeichert werden.

Ein vernüftiges embedded System bietet dies schon von Haus aus.

Ich habe meinem Geschäftsparter auch gesagt: „nimm keinen Raspberry für Video-Streaming, das System stürzt dauernd ab.“ Tja, nun steht dort ein teuerer Rechner, weil der Raspberry einfach dafür sch**** ist. Es ist und bleibt ein billiger Bastel-Rechner. Der durchaus seine Berechtigungen hat, ich mag ihn :slight_smile:

11

Beispiel(e)?

Gruss,
Jan

12
13

Auf den ersten Blick erkenne ich kein klares Anzeichen eines Redundanz-Features bei diesen Geräten…(?)

Grüsse,
Jan

14

also - physikalische Redundanz wirst Du bei einem Gerät nie bekommen (sollte klar sein).

Allerdings booten die Geräte aus dem internen Flash. D.h. bei Stromausfall wird der Flash nicht geschrottet wie die SD-Karte beim Raspberry, die Kiste bootet immer. Zum Speichern kannst Du selber eine SD-Karte reinstecken (oder USB-Stick), welche aber den üblichen Problemen unterliegen.

daran hat sich noch nie ein Enduser gehalten…

15

Danke für’s Feedback! :wink: