Risiken eines unsauberen MySQL Backups

S

Shopping

Legendäres Mitglied
Ein wirklich sauberes Backup einer MySql Datenbank ist nur mit einigem Aufwand moeglich. So besteht z.B. eine Moeglichkeit darin MySql jeweils vor dem Backup herunterzufahren und somit offline zu gehen. Wer dies nicht tut, laeuft bekanntlich Gefahr, dass die Daten nicht mehr konsistent sind. Doch was bedeutet das genau?

Was fuer Konsequenzen koennen inkonsistente Daten fuer ein Forum (wie z.B. Ayom) haben? Reden wir hier von vernachlaessigbaren Unstimmigkeiten im Detail oder von einem moeglichen Totalausfall, falls das Backup wieder aufgespielt werden muss?

Bin gespannt auf Eure kompetenten Antworten.
 
Schreiboperationen bei Datenbanksystemen bestehen bereits beim Schreiben einer Zeile häufig aus vielen Einzeloperationen auf der Betriebssystemebene: Zeile / Seite laden, im Speicher ändern, zurückschreiben, einen Index aktualisieren, womöglich die Seite (bsp. 8 KB) in zwei Seiten zerlegen und die Seitenverkettungen aktualisieren, weil der Platz auf einer Seite nicht mehr ausreicht.

Ein zweiter Themenkreis hängt mit Aufgabenstellungen zusammen, die sich aus mehreren elementaren Insert/Update/Delete - Aktionen (plus womöglich dadurch ausgelösten Indexaktualisierungen) zusammensetzen und die entweder vollständig oder gar nicht ausgeführt werden sollen: Paradebeispiel sind Geldbuchungen - wenn eine Summe von einem auf ein anderes Konto umgebucht werden soll, dann muß das entweder vollständig oder gar nicht passieren - sonst wird per fehlerhafter Datenbank Geld generiert oder vernichtet. Solche Aktionen werden in Transaktionen gekapselt - eine Transaktion wird entweder vollständig oder gar nicht ausgeführt, auch wenn dazwischen alles mögliche passiert.

Damit zusammenhängend können Sperren (Lese-, Schreib-, Schema-, Tabellensperrungen) eingerichtet werden, die andere Zugriffe blockieren: Lesezugriffe müssen alle 'abgearbeitet' sein, wenn ein Nutzer einen exklusiven Schreibzugriff anfordert, das kann Wartezeiten oder sogar Blockaden / Deadlocks produzieren.


QUOTE (Shopping @ Sa 9.02.2008, 20:06)Ein wirklich sauberes Backup einer MySql Datenbank ist nur mit einigem Aufwand moeglich. So besteht z.B. eine Moeglichkeit darin MySql jeweils vor dem Backup herunterzufahren und somit offline zu gehen. Wer dies nicht tut, laeuft bekanntlich Gefahr, dass die Daten nicht mehr konsistent sind.


Ist das wirklich so heftig? Ich nutze ja das Teil nicht, ich weiß allerdings, daß die meisten mySql-Standardinstallationen einen Dateityp nutzen, der nicht transaktionsorientiert ist. Damit fehlt das Werkzeug für solche Absicherungen.

Bei dem von mir genutzten Microsoft SqlServer (2005) habe ich das Problem nicht. Das ist transaktionsorientiert, da kann auch bei laufendem Betrieb ohne Probleme ein Backup erzeugt werden.

Bei Foren gibt es sehr viele Lesezugriffe, nur wenige Insert und eigentlich noch weniger Update-Anweisungen. Im kritischen Fall wäre dann ein Beitrag zerschossen (Schreiben einer Einzelzeile) oder die Bezüge innerhalb eines Themas wären fehlerhaft, aber das sind ja nicht solche Vielfach-Schreibzugriffe wie bei Buchungssystemen.

Allerdings meine ich mal, gelesen zu haben, daß die Standard-mySql-Installation für das Sichern einer Datenbank einen exklusiven Zugriff benötigt, um Schreibzugriffe während der Sicherung zu blockieren. Das hieße, daß in dieser Zeit niemand schreiben könnte - wenn das fünf Minuten dauert, dann ist das natürlich bäh.
 
QUOTE
Ist das wirklich so heftig? Ich nutze ja das Teil nicht, ich weiß allerdings, daß die meisten mySql-Standardinstallationen einen Dateityp nutzen, der nicht transaktionsorientiert ist. Damit fehlt das Werkzeug für solche Absicherungen.



Tatsächlich ist es nicht ganz so heftig. Seit Version 5 kann man zwischen myIsam und innodb wählen. Wie der Name bereits andeutet sind in myIsam reine Text-dateien. innoDB sind Binärdateien.

Während myIsam durch jahrelange Optimierung sehr schnell läuft, kann man in InnoDB auch sichere Transaktionen durchführen. innoDB braucht allerdings auch ein Vielfaches mehr an Speicherplatz.


QUOTE
Allerdings meine ich mal, gelesen zu haben, daß die Standard-mySql-Installation für das Sichern einer Datenbank einen exklusiven Zugriff benötigt, um Schreibzugriffe während der Sicherung zu blockieren. Das hieße, daß in dieser Zeit niemand schreiben könnte - wenn das fünf Minuten dauert, dann ist das natürlich bäh.


Sichere Backups kann man auch myIsam sehr schnell schreiben. Von 5 min kann da überhaupt keine Rede sein. Solange sich das Datenvolumen sich im Megabytebereich hält, bleibt die Erstellung eines Backups meist unter einer Sekunde, aber das ist wieder eigene Musik.

Mit grösseren Datenmengen habe ich in dieser Hinsicht noch nicht gearbeitet.

Auch wenn die Möglichkeiten komplexe Datenbankqueries zu erstellen bis Version 3 nicht an mssql herankamen, habe ich grundsätzlich ausgezeichnete Erfahrungen mit mysql.

Gruss Tümmel
 
So, jetzt habe ich mir mal unter http://dev.mysql.com/doc/ die Dokumentation für die Version 5.1 geholt.

Und muß feststellen: Das ist ziemlich heikel:

myIsam/5.1 unterstützt keine Fremdschlüssel (foreign key). Und (Punkt 13.5.2.2):

QUOTE BACKUP TABLE kopiert die minimale Anzahl an Tabellendateien, die zur Wiederherstellung der Tabelle benötigt werden, in das Sicherungsverzeichnis, nachdem ggf. gepufferte Änderungen auf Festplatte geschrieben wurden. Die Anweisung funktioniert nur bei MyISAM-Tabellen.
...
Während des Backups wird für jede Tabelle für den Verlauf des Sicherungsvorgangs eine Lesesperre gehalten (d. h. immer für eine Tabelle gleichzeitig). Wenn Sie mehrere Tabellen als Momentaufnahme sichern wollen (und dabei vermeiden wollen, dass diese während der Sicherung geändert werden), setzen Sie zunächst eine LOCK TABLES-Anweisung ab, um eine Lesesperre für alle betreffenden Tabellen zu erwirken.


Im Klartext heißt dies: Ein zentrales Werkzeug innerhalb relationaler Datenbanken besteht darin, Tabellen über Fremschlüssel miteinander zu verknüpfen. Damit kann die Basiszeile nicht mehr gelöscht werden, falls eine Detailzeile dazu existiert und die Detailzeile muß einen passenden Schlüssel auf eine Basiszeile enthalten. Datenänderungen, die einer dieser Regeln widersprechen, werden per Rollback abgeblockt. In mySql.5.1 fehlt dieses zentrale Werkzeug, also auch in den Foren, Blogs u.ä., die auf mySql basieren. Selbst wenn es das Werkzeug gäbe, müßte es konsistent bei der Entwicklung verwendet werden.

Das in Kombination mit dem Sicherungsproblem heißt: Man müßte, will man die Konsistenz sicherstellen und gibt es tatsächliche verknüpfte Tabellen (Threadtitel + Threadbeiträge), alle verknüpften Tabellen auf einmal sperren - und dann sichern. In der gesamten Zeit wäre keine Aktualisierung möglich.

Alternative: Umstieg auf InnoDB, wobei das wohl langsamer sein soll und die Datenbankstruktur dann auch Fremdschlüssel nutzen bzw. die PHP-Scripte transaktionsorientiert sein müßten (Schreiben von Forentitel plus erstem Beitrag in einer Transaktion).

Innerhalb von server-daten gibt es Datenbanken mit 40 Tabellen und 60 Verknüpfungen. Natürlich läßt sich auch das problemlos sichern. Bisher hatte ich immer gedacht, daß mySql das unterstützt.
huh.gif
 
1.) am einfachsten sollte das Backup mit:
http://dev.mysql.com/doc/refman/5.1/de/mysqldump.html

erstellt werden, dort gibt es entsprechende Lock-Optionen die ein 100% konsistentes Backup erlauben.

2. ) wie jAuer sagt gibt es sicher Datenbank in dennen es sehr wichtig ist alle Tabellen zu sperren bevor eine Sicherung gemacht wird. Geldoperationen etc. Bei einem Forum wie Ayom ist aber das schlimste was passieren kann das Datensätzte die gerade zur Zeit des Backups eingetragen werden nicht 100% sauber in der Datenbank stehen. z.B. das der Eintrag zwar in der Datenbank steht, aber die Anzahl Beiträge im Benutzerprofil noch nicht hochgezählt wurde usw. Also nichts kritisch.

Es ist also mit MySQL möglich 100% sichere und konsistente Backups zu erstellen, als auch Transaktionen bei Update Operationen zu benutzen
smile.gif
 
QUOTE (manuel @ So 10.02.2008, 11:07)2. ) wie jAuer sagt gibt es sicher Datenbank in dennen es sehr wichtig ist alle Tabellen zu sperren bevor eine Sicherung gemacht wird. Geldoperationen etc. Bei einem Forum wie Ayom ist aber das schlimste was passieren kann das Datensätzte die gerade zur Zeit des Backups eingetragen werden nicht 100% sauber in der Datenbank stehen. z.B. das der Eintrag zwar in der Datenbank steht, aber die Anzahl Beiträge im Benutzerprofil noch nicht hochgezählt wurde usw. Also nichts kritisch.

Äh - 'nicht ganz'.

Bei richtigen Datenbank-Systemen können während eines Backups laufend Aktualisierungen vorgenommen werden - da muß überhaupt nichts gesperrt werden. Bei server-daten werden alle Datenbanken einmal gegen 23:30 gesichert, die Sicherungen werden komprimiert und gegen 00:30 von HostEurope abgeholt (plus 20 Tage gelagert). Solche Sicherungen könnte man auch vormittags unter Hochbetrieb erstellen.

Da - wie ich soeben lernen mußte - mySql keine Fremdschlüssel unterstützt, ist es denkbar, daß ein PHP-Script einer Seite neue Einträge in mehreren Tabellen erzeugt (Threadtitel + Beitrag). Wird eine Tabelle dazwischen für eine Sicherung gesperrt, dann enthält die Sicherung bsp. den neuen Threadtitel, nicht aber den ersten Beitrag.

Sprich: Die Sicherung ist in sich völlig inkonsistent - sie ist Müll. Das Problem bemerkt man natürlich erst dann, wenn man nach einem Crash die Sicherung einspielt - und dann feststellen muß, daß auch die Müll ist - toll.
mad.gif


Ein Script löst das Problem nicht - die Architektur eines 'Gesamt-Datei-Kopierens' ist das Problem. Bei dem Nutzer, der während einer Sicherung einen neuen Beitrag startet, müßte das Speichern komplett (Threadtitel plus Beitrag) abgebrochen werden - aber das würde (1) ein transaktionssicheres Backend und (2) ein transaktionssicheres PHP-Script voraussetzen.

Sprich: Das


QUOTE (manuel @ So 10.02.2008, 11:07)Es ist also mit MySQL möglich 100% sichere und konsistente Backups zu erstellen, als auch Transaktionen bei Update Operationen zu benutzen
smile.gif


stimmt, wenn das

QUOTE aber das würde (1) ein transaktionssicheres Backend und (2) ein transaktionssicheres PHP-Script voraussetzen.


erfüllt ist. Also Mindestanforderung InnoDB - wer nutzt die?
 
QUOTE Also Mindestanforderung InnoDB - wer nutzt die?

im Moment wohl eher fast keiner. Damit stehen viele sehr nützliche Funktionen nicht zur Verfügung.

Trotzdem ist es eben möglich ein sicheres Backup zu erstellen, wenn das auch den sehr unschönen Nebeneffekt haben kann das dabei die Datenbank quasi Tod ist.


QUOTE Sprich: Die Sicherung ist in sich völlig inkonsistent - sie ist Müll.

Ich denke das ist eben ansichtsSache alle anderen Themen/Posts usw. sind davon völlig unbetroffen. Daher ist der Schaden meiner Meinung nach sehr klein und kann 1. schnell behoben oder 2. ignoriert werden.
Wenn ich ein Backup zurück spielen muss sind alle Themen/Posts nach dem Backup sowie so weg, weswegen ein falsches Thema recht wenig stört. Davon abgesehen das ein Backup in den meisten Fällen 100% richtig funktionieren sollte...
 
QUOTE
Also Mindestanforderung InnoDB - wer nutzt die?


Das kommt wie bereits erwähnt auf die Anwendung an.

Ist im Moment des Backups kein weiterer Datenbankbenutzer da,
gibt's dann wohl in keiner sql-Version Probleme mit einem konsistenten Backup.

Folglich gibt es auch myIsam in den allermeisten Fällen genug Möglichkeiten und Zeitfenster 100% konsistente Backups zu erstellen.

Im Hochbetrieb würde ich auch kein Backup mit myIsam empfehlen, soweit nicht anders möglich,
denn es ist sicher nicht die feine Art, User einfach abzuwürgen.

Dann sollte man sich wirklich überlegen auf innoDB umzusteigen.
InnoDB benutze ich in der Regel in Systemen, wo höhere Sicherheitsanforderungen bestehen.
Die Transaktionen in innoDB lassen sich einfach mit einem Befehl starten und beenden + rollback befehl, im Falle eines Scheiterns und wenn notwendig.

btw. Das innoDB langsamer ist als myIsam, bedeutet nicht das innoDB zwangsläufig langsamer sein muss als andere sql-Versionen.

 
QUOTE Was fuer Konsequenzen koennen inkonsistente Daten fuer ein Forum (wie z.B. Ayom) haben? Reden wir hier von vernachlaessigbaren Unstimmigkeiten im Detail oder von einem moeglichen Totalausfall, falls das Backup wieder aufgespielt werden muss?

Bin gespannt auf Eure kompetenten Antworten.

Minimale Fehler. Wahrscheinlichkeit sehr gering.


QUOTE Sprich: Die Sicherung ist in sich völlig inkonsistent - sie ist Müll. Das Problem bemerkt man natürlich erst dann, wenn man nach einem Crash die Sicherung einspielt - und dann feststellen muß, daß auch die Müll ist - toll.

Das ist das erste und mit grösster Wahrscheinlich auch das letzte mal, dass ich eine Aussage von Jürgen zum Thema DBs mit Unsinn quittieren muss. Wobei


QUOTE erstellt werden, dort gibt es entsprechende Lock-Optionen die ein 100% konsistentes Backup erlauben.

das auch nicht ganz korrekt ist.

Fakt ist, Mysql ist ein etwas dümmeres DBMS. Das hat zu Konventionen und Methoden geführt, wie ein Teil des DTM nach PHP wandert. Es ist möglich, dass eine marginal inkonsitente Sicherung entsteht. Diese Inkonsistenz ist aber von der gleichen Grössenordnung wie sie non-transactional immer stattfinden kann. Z.b. 2006 mysql server has gone away.

Wenn ein Mysqldump zu einem völlig inkonsitenten Backup führt, kann man durchaus zu einem anständigen DBMS wechseln. I.d.R. ist es aber billiger (weil man das bei dem DBMS Wechsel eh muss) den Programmier zu ersetzen. Weil der hat ganz gewaltige Scheisse gebaut.

Ich fahre seit Jahren mit Mysqldump sehr gut. Bei Ayom werden die Dumps problemlos während Vollbetrieb gemacht. Allerdings hat Jürgen theoretisch recht. Es kann sein dass. Es ist möglich. Und das ist es zugebenermassen bei einem anständigen DBMS nicht der Fall.

Aber hey, wir haben schon Trigger
wink.gif
Nur Constraints und jaaaaaaa Fremdschlüssel wären nicht schlecht.

Und zugegebenermassen sind auch ein nicht zu vernachlässigender Teil der automatischen Test einer reifen PHP Anwendung oftmals nichts anderes als Constraint Checks auf den Daten.

Meine Aussagen sind leider halt auch kein Freipass mysqldump blind zu vertrauen. DBMS heisst DB Management System. Die Idee dahinter ist Oracle als DBMS alles machen zu lassen, was mit den Daten zu tun hat. Deshlab MS. Bei Mysql ist das einfach weit banaler. Ein grosser Teil von dem Management muss von dem Applikations-Layer gemacht werden. Also Fazit: Eine schlecht aufgebaute Applikation mit Mysql Anbindung kann Fehlerchen produzieren. Eine Applikation die nach Jürgens Theorie (es _ist_ theoretisch möglich) absoluter Müll produziert, dürfte in meinen Augen nicht mal Applikation genannt werden!


QUOTE Im Hochbetrieb würde ich auch kein Backup mit myIsam empfehlen, soweit nicht anders möglich,
denn es ist sicher nicht die feine Art, User einfach abzuwürgen.

Solange die Tables nicht so gross sind, dass sie ewig gelockt sind, i.d.R. kein Problem.

Ich hatte mal ein incrementelles Mysql Backup am laufen. Hat sich aber nicht bewährt.

Und bevor die Frage kommt, ja, hab schonmal ein Ayom Backup eingespielt.

Ivo, welche Applikation? Auch ein Forum? Open Source?
 
Ich sollte meine Aussage von oben etwas konkretisieren.

Wenn man eine Grund- und eine Detailtabelle (Forum: Threadtitel und Threadbeiträge) hat und wenn es beim Backup die Situation gab, daß dem Threadbeitrag kein Titel zugeordnet war (unsauberes Speichern von der Anwendung) und man dieses Backup einspielen muß, dann hängt dieser Threadbeitrag im Nirvana.

Bei einem Forum ist das zu vernachlässigen - halt irgendein Defekt, der nach einigen Monaten niemandem mehr auffällt.

Nur: Web-Datenbanken werden ja noch für andere Dinge verwendet. server-daten wird inzwischen bsp. für Strukturen (Firmen 1:n Personen 1:n Kontakte / Wiedervorlagen mit Signalisierung, Firmen 1:n Termine m:1 Personen) genutzt. Oder der unten verlinkte Online-Kalender - statt Orten Filialen mit Termin- und Mitarbeiterzuordnung und entsprechenden Fremdschlüsseln. Versicherungsanfragen, die in einer Tabelle reinkommen und auf verschiedene Personen (mit Kosten für diese) aufgeteilt werden. Da hängt an einem einzigen Fremdschlüsseleintrag eine Terminvereinbarung, eine Zahlungsverpflichtung und ähnliches dran. Und da sind solche Systeme Pflicht.

Ich hatte tatsächlich erst beim Schreiben bzw. Nachlesen begriffen, daß mySql das in der Standardversion nicht anbietet. Und das hat natürlich Konsequenzen für alle Softwareprodukte, die auf dieser Standardversion beruhen. Denn die müssen das Problem tatsächlich in die Applikation verschieben - ich mußte (und muß beim Einrichten von Kundendatenbanken) für solche Dinge nie Zeit aufwenden. Natürlich produziert mir die MS-Sql2005-Lizenz satte Fixkosten. Aber dafür ermöglicht das auch, daß ich mich auf die wesentlichen Dinge konzentrieren kann, entlastet also durch die zusätzliche Abstraktion.
 
Jürgen,
wenn du so weitermachst schreibe ich noch schnell ein 100% sicheres mysl-backup-script.

QUOTE
Es kann sein dass. Es ist möglich. Und das ist es zugebenermassen bei einem anständigen DBMS nicht der Fall.


Man kann auch die Connections auslaufen lassen und anschliessend blocken.
Dann sollte wohl ein 100% konsistentes Backup möglich sein, wenn man überhaupt etwas 100% nennen kann.


QUOTE
Denn die müssen das Problem tatsächlich in die Applikation verschieben - ich mußte (und muß beim Einrichten von Kundendatenbanken) für solche Dinge nie Zeit aufwenden.


Das stimmt. Der Zeitaufwand ist aber denkbar gering und wahrscheinlich sehr viel geringer als sich jedesmal um Fremdschlüssel Gedanken machen zu müssen und diese zu definieren.

Fremdschlüssel hatte ich übrigens als erstes aufgegeben bevor ich mich von ms-sql endgültig verabschiedet hatte und eigene Datenbankformate geschrieben habe.


QUOTE dann ist das natürlich bäh

Schätzungsweise sind die Fremdschlüssel in ms-sql nur eingeführt worden, um ms-sql Datenbanken nach jedem Absturz wenigstens reparieren zu können.




 
Ketzerisch:

JEDES Backup ist "inkonsistenz". DENN: Wenn es eingespielt wird, ist es mindestens 15 Minuten alt und somit habt Ihr so oder so einen Datenverlust.

Das System sollte so aufgebaut sein, das ein Backup mit allergröster Wahrscheinlichkeit NIE benötigt wird.
 
Ich nutze die Möglichkeit mit dem Wartunsmodus, denn das ist meine einzigste Möglichkeit, da sonst sämtliche Statistiken die über die Scripte erzeugt werden total verfälscht werden und bei Wiederherstellung total durcheinander sind, so dass diese Resetet werden müßten.

An Software nehme ich nur den MySQLDumper, der läuft jedenfalls sehr schnell drüber.
 
QUOTE (Tuemmel @ Mo 11.02.2008, 23:55)Man kann auch die Connections auslaufen lassen und anschliessend blocken.
Dann sollte wohl ein 100% konsistentes Backup möglich sein, wenn man überhaupt etwas 100% nennen kann.


Das ist keine Option, wenn viele Datenbanken regelmäßig gesichert werden müssen. Da können Nutzer parallel drauf sein, auch nachts und solche 'wichtigen Schreiboperationen' durchführen. Das muß völlig automatisiert sein.


QUOTE (Tuemmel @ Mo 11.02.2008, 23:55)
QUOTE
Denn die müssen das Problem tatsächlich in die Applikation verschieben - ich mußte (und muß beim Einrichten von Kundendatenbanken) für solche Dinge nie Zeit aufwenden.


Das stimmt. Der Zeitaufwand ist aber denkbar gering und wahrscheinlich sehr viel geringer als sich jedesmal um Fremdschlüssel Gedanken machen zu müssen und diese zu definieren.


Auf server-daten laufen inzwischen Kundendatenbanken mit 40 Tabellen und ca 50 Fremdschlüsselbeziehungen. Die werden über das Menü für Verknüpfungen erstellt: Grundtabelle, Detailspalte, Ausdruck, der ausgegeben werden soll (bsp. Nachname + ', ' + Vorname) - das dauert eine Minute und erzeugt die Pulldownliste einschließlich Blätter- und Suchmöglichkeit gleich mit. Das Menü kennt inzwischen noch andere Felder, damit können bsp. Personen sortiert nach der Entfernung mit Kilometerangabe zu einem Stammdatensatz ausgegeben werden. Und ich kann mich damit um solche Sachanforderungen des Kunden kümmern.


QUOTE (Tuemmel @ Mo 11.02.2008, 23:55)Fremdschlüssel hatte ich übrigens als erstes aufgegeben bevor ich mich von ms-sql endgültig verabschiedet hatte und eigene Datenbankformate geschrieben habe.


QUOTE dann ist das natürlich bäh

Schätzungsweise sind die Fremdschlüssel in ms-sql nur eingeführt worden, um ms-sql Datenbanken nach jedem Absturz wenigstens reparieren zu können.


Fremdschlüssel sind ein allgemeines Konzept für relationale Datenbanken und haben nichts mit Microsoft zu tun. Genauso wie das Konzept der Transaktionsorientiertheit plus dem Abstraktionsgrad von Sql (als Sprache der vierten Generation) dient das dazu, Fehler und Risiken zu vermeiden. Ich finde es bald schon drollig, wie solche Konzepte hier als 'nicht so notwendig' beiseitegeschoben werden. Für ein Forum mag das ok sein. Mehr aber auch nicht, bereits bei Bestell- und Bezahlungsvorgängen wird das heikel.


QUOTE JEDES Backup ist "inkonsistenz". DENN: Wenn es eingespielt wird, ist es mindestens 15 Minuten alt und somit habt Ihr so oder so einen Datenverlust.


Du kennst sicherlich Komplett-Backups plus Backups des Transaktionslogs? Wenn letzteres noch erstellt werden kann, bsp. weil diese Platte noch verfügbar ist, dann kriegt man alles bis zum Crash. Und bei einer transaktionsorientierten Datenbank erzeugt auch ein Stromausfall keine inkonsistenten Daten.
 
QUOTE
Das ist keine Option, wenn viele Datenbanken regelmäßig gesichert werden müssen. Da können Nutzer parallel drauf sein, auch nachts und solche 'wichtigen Schreiboperationen' durchführen. Das muß völlig automatisiert sein.


Glaubst im Ernst ich würde nachts alle 5 Minuten aus dem Bett springen, schauen ob gerade kein User mehr da ist und dann schnell ein Backup machen?
dry.gif



QUOTE
Ketzerisch:
JEDES Backup ist "inkonsistenz". DENN: Wenn es eingespielt wird, ist es mindestens 15 Minuten alt und somit habt Ihr so oder so einen Datenverlust.
Das System sollte so aufgebaut sein, das ein Backup mit allergröster Wahrscheinlichkeit NIE benötigt wird.


Das ist überhaupt nicht ketzerisch, wenn du meinst dass bei Benutzung eines Backups Daten wegen fehlender Aktualität eventuell verlorengegangen sind.
Die Konsistenz sollte davon aber eben nicht betroffen sein und darum geht's hier, glaube ich.


Wenn ich an Fremdschlüssel denke, kommen mir hochkomplizierte Datenbankstrukturen mit nicht mehr nachvollziehbaren Verknüpfungen in den Sinn,
sodass ich nach 3 Wochen der Datenbank den Stempel "please don't touch" aufgedrückt habe.
Ich kann mit Fremdschlüsseln nicht arbeiten. Das führt bei mir nur zu einem Riesenchaos.

Ohne Fremdschlüssel schreibe ich viel klarere Strukturen.
sodass man im schlimmsten Fall auch selbst eine Fehlerroutine schreiben kann, um inkonsistente Datensätze raus zu schmeissen oder gegebenenfalls zu ergänzen.


QUOTE Du kennst sicherlich Komplett-Backups plus Backups des Transaktionslogs?

Das ist wirklich ein Schwachpunkt in mysql. In der letzten mit bekannten Version wurde wegen der performance noch von Transaktionslogs andeutungsweise abgeraten.
Kann sein, dass sich das aber inzwischen verbessert hat. Da bin ich nicht mehr auf dem neuesten Stand.

====================================================
Ich weiss, der Edit passt jetzt überhaupt nicht zum Thema, doch nur zu Jürgens Genugtuung habe ich gerade einen Kommentar vom letzten Jahr wiedergefunden:

Das ist jetzt weder eine Anfrage noch ein Problem, sondern nur ein Beispiel für "nobody's perfect" und auch schon lange abgehakt.

CODE
/*
mysql server crash:
$result=mysql_query("select distinct f.freunde, w.foto, w.format, l.benutzername, l.id, l.onlinestatus,b.y1,min(w.lfdnr) from benutzer b,
login l, freunde f left join foto w on (w.lfdnr<>0 and w.id=f.freunde and f.id=".$ids.") or
(w.lfdnr<>0 and f.freunde=".$ids." and f.id=w.id) where (l.id<>".$ids." and b.id<>".$ids." and b.id=l.id and (b.id=f.id or b.id=f.freunde) and (f.id=".$ids." or f.freunde=".$ids."))
group by l.benutzername asc,l.onlinestatus, b.y1, w.lfdnr, f.freunde, w.foto, w.format
",$link)or die(mysql_error());
*/


=====================================================
 
Die Qualität eines Backups misst sich eben genauso, wie die Qualität anderer Dinge: an den Anforderungen. Und wie sind die Anforderungen bei 90% der Anwendungen im Internet? Sie sind so: Hauptsache es läuft, und zwar schnell; Datenverluste sind praktisch egal. Böse gesagt: es ist egal, ob der User eines Forums einen Beitrag nochmal schreiben muss. Und mit diesen Anforderungen reicht dann eben ein Treiber ohne transaktionelle Absicherungen wie MyISAM völlig aus.

Wer andere Anforderungen hat wird tunlichst ein anderes Datenbankmodell wählen. Vielleicht reicht ja schon die Nutzung von InnoDB, oder der Umstieg in die Mittelklasse ;-) zu PostgresQL.

Was ich sagen will ist, bezogen zur Ausgangsfrage: wer MySQL mit MyISAM nutzt hat ja schon mit dieser Entscheidung festgelegt, dass für ihn kein Risiko eines unsauberen MySQL-Backups existiert. Ist doch auch ok, oder?
 
Event. eine Lösung.

a) Raid 1 System im Software Raid
b) Raidsynchronisation wird deaktiviert
c) Backup wird geschrieben
d) Raidsynchronisation wird aktiviert

Problem: Bei grösseren Datenmengen nicht möglich, das Softwareraid braucht extreme Ressourcen bei der Synchronisation, ob das überhaupt realisierbar ist, stelle ich einmal dahin
wink.gif
. Unsere Systeme werden wie wohl bei den meisten Anbietern Full und Inkrementell gesichert.

Edit: vergesst die Idee... habe heute gerade mit diesem Teil wieder mal Probleme gehabt. Hardware Raid und fertig.. Software Raid ist zum k***!
 
QUOTE (profo @ Di 12.02.2008, 20:34)Hauptsache es läuft, und zwar schnell; Datenverluste sind praktisch egal. Böse gesagt: es ist egal, ob der User eines Forums einen Beitrag nochmal schreiben muss. Und mit diesen Anforderungen reicht dann eben ein Treiber ohne transaktionelle Absicherungen wie MyISAM völlig aus.


Das stimmt - einerseits.

Andererseits versperren sich damit Anbieter von Datenbanklösungen den Zugang zu Firmenkunden - denn da ist das nicht mehr egal. Und das ist dann lustigerweise kein Online/Offline-Problem mehr, weil das Risiko einer nicht transaktionsorientierten Datenbank offline genauso existiert.


QUOTE (profo @ Di 12.02.2008, 20:34)Was ich sagen will ist, bezogen zur Ausgangsfrage: wer MySQL mit MyISAM nutzt hat ja schon mit dieser Entscheidung festgelegt, dass für ihn kein Risiko eines unsauberen MySQL-Backups existiert. Ist doch auch ok, oder?


Theoretisch stimmt das. Praktisch gibt es genügend Laien, die sich bsp. für einen Verein Joomla installieren, Mitglieder tragen ihre Daten (einschließlich Bankdaten) online ein - und die wissen nix von diesen möglichen Problemen.

Marc: Wenn das Datenbanksystem die Daten bereits inkonsistent rausschreibt, weil während der Zeitdauer des Schreibens Dinge geändert werden und ein blockierender Log unerwünscht ist, dann sind die Daten auf der Byte-Ebene korrekt. Das ist kein per Raid lösbares Problem. Das sind Schnappschüsse zu verschiedenen Zeitpunkten, die zusammen inkonsistent sind.
 
QUOTE
Andererseits versperren sich damit Anbieter von Datenbanklösungen den Zugang zu Firmenkunden


Ich finde es immer schön, wenn man sich darauf einigt, das der Himmel rosa ist, nur sich sich ein paar Experten eine rosa Brille aufgesetzt haben.


QUOTE
Mitglieder tragen ihre Daten (einschließlich Bankdaten) online ein - und die wissen nix von diesen möglichen Problemen.


Faszinierend ist die Polarität wie du scheinbare Probleme auf kleinster Vereinsebene unterschwellig als immenes Sicherheitsrisiko für Benutzer mit Schlagwörtern (Bankdaten) darstellst und verallgemeinerst.

Wo ist das Sicherheitsproblem, wenn die Bankdaten eines Benutzers möglicherweise nicht konsistent wären, weil der Kassenwart des Vereins ausgerechnet zu einer Zeit die Bankdaten seiner Mitglieder zum Zeitpunkt des Backvorgangs eingeben muss ? Deine Argumentation ist total abwegig !

Schlimmstenfalls kann er die inkonsistenten Datensätze nochmal eingeben oder vervollständigen, aber dazu muss es gar nicht erst kommen.
Wenn nicht ist die ganze Applikation ohnehin ein Sicherheitsrisiko und man sollte sich schleunigst einen anderen Programmier suchen.

1. Ausserdem werden Anbieter von Datenbanklösungen für Firmenkunden mit hochsensiblen Daten sicher innoDB wählen. Jedoch nicht wegen des Backups, sondern der Gewährleistung konsistenter Daten während sämtlicher zusammenhängender Schreibvorgänge.

2. Man kann automatisch die threads in Ruhe beenden lassen und anschliessend, während der Zeit des Backup blocken oder den Datenbankzugriff teilweise oder ganz sperren. Da gibt es vielfältige Möglichkeiten.

3. Man kann auch, nachdem kein thread mehr offen ist, temporär die Benutzerrechte ändern, sodass bei gigantischen Backups vereinzelten Benutzern noch ein Lesezugriff bleibt.

Die Firma oder den Verein möchte ich erst mal sehen, wo rund um die Uhr Benutzer ständig Daten eingeben, es sei denn es sind Onlinefirmen.


Mit diesen 100% konsistenten Backups sind dann auch Firmen abgedeckt.
Ob myIsam oder innoDB ist hier zum Thema eines konsistenten Backups völlig egal.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben