Keine USV

I

Indi

Member of Honour
Folgendes Szenario:

Ein paar Linux Rechner im lokalen Netzwerk. Gentoo, 2.6er Kernel.

Alle Rechner arbeiten gemeinsam an einem Problem. Dazu hab ich ein paar PHP- und Perl-Scripts laufen, die ich dem default-runlevel hinzugefügt habe.

Ein paar Scripts sind für mathematische Berechnungen zuständig, ein anderes verarbeitet Daten auf einem lokalen MySql-Server.

Sollte ich den Computer abschalten wird der aktuelle Status der Scripts überprüft und der Computer erst dann heruntergefahren, wenn die Scripts einen speziellen Punkt erreicht haben, von dem an sie wieder weiterarbeiten können, wenn das Script wieder aktiviert wird.

Ein Problem hab ich allerdings wenn der Strom plötzlich ganz weg ist. Mehrere USV-Stationen für mehr als 10 Computer kosten nahezu ein Vermögen. Daher such ich nach alternativen Möglichkeiten, die Daten auf einem Weg zu retten, der möglichst kostengünstig ist, wenn das Netzwerk erweitert werden soll.

Das Hauptproblem liegt diesbzgl. vor allem bei den INSERTS und UPDATES der MySQL-Datenbanken. Was passiert mit einer solchen Abfrage beispielsweise, wenn genau in diesem Moment der Strom wegbricht?

Es ist insofern auch schwierig die Daten in der DB zu kontrollieren, da die Menge selbst nicht überschaubar ist und vor allem nicht lesbar, da teilweise einfach nur Zahlen und Checksums gespeichert werden.

Meine erste Idee war, die Datenbank-Abfragen in einem Pool zu sammeln, damit nicht jede Sekunde etwas eingefügt wird, sondern nur zb. alle 10 Minuten, so könnte ich nach den Inserts überprüfen, ob die Daten richtig eingefügt wurden und falls nicht, die Datenbank wieder auf den vorhergehenden Timestamp herstellen. Allerdings befürchte ich dabei, dass sich die Ausführungszeit bei der Menge an Abfragen enorm verlangsamen würde, außerdem habe ich dadurch wieder einen Haufen an unnötigen SELECTS wenn der Strom vorhanden bleibt... Eine höhere Auslastung der einzelnen Server würde wiederum zu einem erhöhten Bedarf der Gesamtzahl an Server führen.

Vlt. hat jemand ne Idee dazu. Ich bin für jeden Lösungsansatz dankbar.
 
also das mit dem mysql zeugs lässt sich doch einfach in eine transaktion auslagern. wenn der server abstürzt, wird automatisch ein rollback gemacht.
 
Danke soox, das war irgendwie genau das Stichwort das ich gebraucht hab. Total übersehen in der MySQL-Docu. Thx!
 
Das Problem dürfte wohl eher sein, daß die Daten, die während eines Stromausfalls übertragen werden auch weg sind und man kaum nachvollziehen kann, was angekommen ist und was nicht. Außerdem gehen auf DB-Servern beim Stromausfall immer Daten verloren, wenn diese auch nur das kleinste bisschen Cache nutzt. Genau für solche Situationen sind USVs doch da. Die Dinger wurden erfunden, weil niemand eine Lösung bauen kann, die im Fall eines Abbruchs der Stromversorgung Datenverlust verhindern kann. Schliesslich darf man nicht nur die am Projekt beteiligten Programme sehen, sondern auch mal die Systeme dahinter.

Das beginnt bei Datenverlusten, die entstehen weil Daten aus dem HD-Cache nicht mehr auf die HD geschrieben werden und geht weiter über Daten, die sich quasi gerade in der "Netzwerkleitung" befinden, d.h. für die Übertragung gecached wurden, DB-Indizes, die noch im RAM waren usw.

Deine einzige sinnvolle Lösung: Kauf dir eine USV, an die du die 2 wichtigsten Rechner (DB und "management"-Rechner) anklemmst, damit wenigstens diese beiden ihre Daten noch korrekt auf die HD bekommen. Ohne USV wird das jedenfalls nichts halbes und nichts ganzes und kann dich das ganze Projekt kosten.

Bis vor ein paar Jahren hab ich auch mal geglaubt ein solches Parallel-Computing, wie du es dort gebaut hast, ohne USV betreiben zu können, aber die Praxis hat mich eines besseren belehrt. Deinen Worst-Case, darfst du dabei nicht außer acht lassen: Die Rechner crashen und das Dateisystem wird irreparabel beschädigt? Spätestens dann wirst du dich in den Hintern beißen, daß du keine USV hattest.

Alternative Lösung: Lagere den Spaß auf ein paar Rootserver aus. Da hast du ein RZ mit Ausfallsicherheit, was den Strom angeht. Die kosten ja mittlerweile auch nicht mehr die Welt.
 
Transaktionsbasierte DBs reichen da völlig. Das ist dann wie ext3fs: Es kann zwar notwendig sein, zu reparieren, aber die Daten werden nie völlig verschwinden.
Anders ausgedrückt: auf diese Weise kann es zwar sein, dass ein gerade errechnetes ergbenis es nicht mehr in die DB schafft, weil der Strom plötzlich weg ist, aber die DB wird immer einen konsistenten Status wiederherstellen können. Schlimmstenfalls sind dann halt 1minute oder so nochmal zu rechnen...
 
auch mit transaktionen und journaling filesystemen wie ext3 und co kann es dennoch zu datenverlust kommen. das risiko ist jedoch einiges geringer dass nur ein teil der berechneten daten in der datenbank vorhanden ist.

ev lässt sich auch noch mysql so konfigurieren, dass keine zu schreibenden daten zwischengespeichert werden. aber selbst dann, kann es sein, dass dies linux selbst macht.

ein tägliches backup ist sicherlich auch keine schlechte sache.
 
Auch Transaktionen können unterbrochen werden. Abgesehen davon wird beim Einfügen einer Transaktion zumindest bei Disk-basierten Tabellentypen wie MyISAM der komplette Index in den RAM geladen. Wird dieser Index nicht korrekt zurück geschrieben, weil der Strom ausfällt, kommt es zu beschädigten Tabellen, die sich lediglich in 80% aller Fälle restaurieren lassen. Meist wird dann das Einspielen eines Backups notwendig. Bei täglichen Backups heißt das im schlimmsten Fall, daß 23-24 Stunden Rechenarbeit weg sind.

Zwar kann man MySQL beibringen, daß nichts im Cache landen soll, indem man alle Caches auf 0 stellt, so geht das doch bei einem Linux-System nicht, zumindest wäre mir nichts bekannt, wie man den HD-Cache deaktivieren könnte.

Ich jedenfalls würde sowas (nicht nochmal) riskieren und das ganze auf Rootserver auslagern. Ob ich mir für ca. 3000 Euro nun 3 Rechner für ein Projekt kaufe oder 900 Euro für 3 Rootserver über ein Jahr ausgebe (12 Monate x 25 Euro x 3 Server) spielt ja kaum eine Rolle. ;)
 
Versteh ich nicht. Eine Transaktion kann doch mittels sync() sicher auf die Platte geschrieben werden. In einem Journal FS weiss ich doch auch sicher, dass entweder der komplette Datensatz oder nix auf die Platte geschrieben wurde. Wenn eine Transaktion also abgeschlossen ist, dann ist sie auf der Platte. Wenn vorher eine Unterbrechung eintritt, dann ist sie es eben nicht und muss neu angestoßen werden. Schlimmstenfalls werden aufgrund von Syncronisationsproblemen Transaktionen doppelt angestoßen, aber das kann man ja ausfiltern.
Ich habe jetzt keine konkreten DBs vorliegen, die das realisieren, aber zumindest möglich sollte es doch mit Standardsoftware sein, wenn es so einfach ist, oder?
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben