MySQL Risiken bei Stromausfall minimieren

jmar83

SQL-Guru
Beiträge
146
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? MySQL :: MySQL 5.5 Reference Manual :: 14.17 InnoDB Startup Options and System Variables

  • 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. -> 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!!)

UND: Wie würde es mit "MariaDB" aussehen?

Danke für eure Tipps!

Mit freundlichen Grüssen,
Jan
 
Werbung:
UND: Wie würde es mit "MariaDB" aussehen?

MySQL und MariaDB ist, was die Features bei z.B. Crash-Recovery betrifft, sehr ähnlich. Du kannst Dir mal spaßenshalber PostgreSQL anschauen, dort stecken ca. 20 Jahre Entwicklung drin, exakt das, also Crash-Sicherheit, mittels der WAL-Dateien (Transaktionslogs) hinzubekommen.

Ich kenne Berichte von Rechenzentren mit jeweils hunderten MySQL, PostgreSQL und anderen Datenbanken. Nach einem massiven Blackout kamen alle PostgreSQL-Instanzen sauber und ohne Zutun hoch. Alles andere war mit massiver Arbeit und Datenverlusten verbunden.
 
Werbung:
Vielen Dank für Dein Feedback! Wird sind eh dran, das System auf plalcon-ORM umzustellen. Wenn das erledigt ist, sollte es umso "einfacher" (na ja..) sein, um das DB-System umzustellen. Allerdings gibt es noch ein paar Trigger und stored Procedures, welche raus müssten. Views sind kaum ein Problem, da in diesen im Grossen und Ganzen sowieso SQL-92-kompatibler Code verwendet wird.

Mal schauen...
 
Zurück
Oben