RootForum Community

oschad wrote:Was macht man bei MySQL, wenn man Backup machen will?

Die meisten Leute verwenden dann mylvmbackup. Das ist ein Perl script, das FLUSH TABLES WITH READ LOCK und LVM Snapshots miteinander synchronisiert. Bei korrekter Anwendung führt das zu einer Datenbank-Schreibsperre von ca. 2 Sekunden, Lesezugriffe werden nicht unterbrochen.

Dazu muss man aber erstmal sowas wie einen Snapshot vom Dateisystem oder einer Partition machen können. Das ist einfach nicht überall gegeben, d.h. man kann nicht überall Backup machen.

Und was macht man eigentlich mit laufenden Transaktionen? Es könnte ja noch wichtig sein, dass die laufen - es ist nicht üblich, dass eine Applikation damit rechnet, dass das DBMS zwischendurch mal den Schreibzugriff sperrt.

In Wirklichkeit haben sich die MySQL-Leute nie mit Backup ernsthaft beschäftigt, weil sie dann etwas implementieren müssten, was teuer zu implementieren im Nachhinein ist. Kann ich verstehen, aber als Sysadmin finde ich das einfach ein KO-Kriterium für MySQL, ich will funktionierende Backups haben und zwar immer und will den Applikationen darüber dafür nicht den Schreibzugriff sperren müssen - das kann ich nämlich einfach nicht immer.

Wie gesagt, aus meiner Sicht wissen die meisten Leute nicht einmal, dass MySQL an der Stelle einfach kaputt ist.

mfg
Oli

oschad wrote:Dazu muss man aber erstmal sowas wie einen Snapshot vom Dateisystem oder einer Partition machen können. Das ist einfach nicht überall gegeben, d.h. man kann nicht überall Backup machen.

Da widersprichst Du Dir selbst ein bisschen... auf der einen Seite eine Riesen-DB mit x Gigabytes an Tabellen, und dann keine dedizierte und für den Datenbankbetrieb entsprechend geeignete Maschine? Hmmm...

oschad wrote:Und was macht man eigentlich mit laufenden Transaktionen? Es könnte ja noch wichtig sein, dass die laufen - es ist nicht üblich, dass eine Applikation damit rechnet, dass das DBMS zwischendurch mal den Schreibzugriff sperrt.

In einem so hochkritischen Umfeld (SLA mit 99,9% Verfügbarkeit oder so was in der Art) sichert man durch Replikation auf einen Slave, von dem man dann letztendlich das Backup zieht (und der kann ja ruhig mal ein Weilchen nicht da sein). Man muss dabei allerdings darauf achten, dass die Schreiblast nicht größer ist als das, was der Slave nach einer Backup-Pause auch tatsächlich wieder aufholen kann, sonst kommt man mit jedem Tag weiter aus'm Sync...

oschad wrote:In Wirklichkeit haben sich die MySQL-Leute nie mit Backup ernsthaft beschäftigt, weil sie dann etwas implementieren müssten, was teuer zu implementieren im Nachhinein ist. Kann ich verstehen, aber als Sysadmin finde ich das einfach ein KO-Kriterium für MySQL, ich will funktionierende Backups haben und zwar immer und will den Applikationen darüber dafür nicht den Schreibzugriff sperren müssen - das kann ich nämlich einfach nicht immer.

ACK, aber was für eine Alternative gibt es, die nicht dieselben (oder ähnliche) Probleme bereithält? OK, PostgreSQL (das ich bevorzugt einsetze) hat mit seinem WAL und der Rotationssteuerung für selbiges schon mal ein bisschen mehr Komfort als MySQL. Ein FS-Snapshot bei laufenden Writes kann aber ebenfalls zu einem kaputten Datenmurks im Backup führen (wobei PostgreSQL meist noch von selbst recovern kann, sofern das WAL noch einigermaßen intakt ist). 100% sicher ist man auch dort nur mit einem FS-Snapshot bei heruntergefahrener DB, oder wenigstens im RO-Betrieb.

oschad wrote:Wie gesagt, aus meiner Sicht wissen die meisten Leute nicht einmal, dass MySQL an der Stelle einfach kaputt ist.

Auch hier Full ACK. Das ist aber ein Problem der Leute, nicht der Software. Ein DB-Server ist eben kein Spielzeug für Gamer-Clan-Kiddies, und gestandene DB-Admins wissen um den ewigen Fluch der Daten(in)konsistenz... (wobei... auch da fallen mir spontan zwei Ausnahmen ein... ich sach nur Oracle auf VMWare ESX - um mehrere DBs parallel auf einem Server zu betreiben :twisted: )

jfreund wrote:

oschad wrote:Dazu muss man aber erstmal sowas wie einen Snapshot vom Dateisystem oder einer Partition machen können. Das ist einfach nicht überall gegeben, d.h. man kann nicht überall Backup machen.

Da widersprichst Du Dir selbst ein bisschen... auf der einen Seite eine Riesen-DB mit x Gigabytes an Tabellen, und dann keine dedizierte und für den Datenbankbetrieb entsprechend geeignete Maschine? Hmmm...

Nicht mit jedem Betriebssystem kann man das oder wie stellst du das mit einem Windows-Server an? Und es gibt auch noch so Sachen wie bestehende Systeme, die das theoretisch könnten, aber nicht so konfiguriert sind und wo man nicht mal eben den Stecker zieht und das alles neu aufzieht.

Davon ab finde ich es merkwürdig, wenn eine Software verlangt, dass man ihre Daten nur sichern kann, wenn man Snapshots auf einer ganz anderen Ebene machen kann. Ja, ich kenne noch mehr Software als MySQL, die das verlangt, aber das ist einfach scheiße in der Administration, ich will das nicht. Ich räume ein, dass man natürlich sichern kann, wenn man die DB auf readonly schaltet, aber will das nicht müssen.

Ich will einfach, dass der Rummel einfach zu benutzen ist, auch als Administrator und ich mir noch über Software-Internas Gedanken machen muss, um eine Datensicherung zu ziehen. Wenn man so etwas wie mysqldump anbietet, dann sollte man doch erwarten, dass man damit einfach Backup macht und gut is. Die meisten Leute, die sich eben nicht mit den Internas auskennen, nehmen einfach mysqldump, weil ihnen das gar nicht bewusst ist, dass das manchmal eben nicht funktioniert.

jfreund wrote:

oschad wrote:In Wirklichkeit haben sich die MySQL-Leute nie mit Backup ernsthaft beschäftigt, weil sie dann etwas implementieren müssten, was teuer zu implementieren im Nachhinein ist. Kann ich verstehen, aber als Sysadmin finde ich das einfach ein KO-Kriterium für MySQL, ich will funktionierende Backups haben und zwar immer und will den Applikationen darüber dafür nicht den Schreibzugriff sperren müssen - das kann ich nämlich einfach nicht immer.

ACK, aber was für eine Alternative gibt es, die nicht dieselben (oder ähnliche) Probleme bereithält? OK, PostgreSQL (das ich bevorzugt einsetze) hat mit seinem WAL und der Rotationssteuerung für selbiges schon mal ein bisschen mehr Komfort als MySQL. Ein FS-Snapshot bei laufenden Writes kann aber ebenfalls zu einem kaputten Datenmurks im Backup führen (wobei PostgreSQL meist noch von selbst recovern kann, sofern das WAL noch einigermaßen intakt ist). 100% sicher ist man auch dort nur mit einem FS-Snapshot bei heruntergefahrener DB, oder wenigstens im RO-Betrieb.

Bist du dir sicher, dass PostgreSQL das auch versemmelt? Nach meinen Erfahrungen funktioniert das zumindest an der Stelle recht gut.

jfreund wrote:

oschad wrote:Wie gesagt, aus meiner Sicht wissen die meisten Leute nicht einmal, dass MySQL an der Stelle einfach kaputt ist.

Auch hier Full ACK. Das ist aber ein Problem der Leute, nicht der Software. Ein DB-Server ist eben kein Spielzeug für Gamer-Clan-Kiddies, und gestandene DB-Admins wissen um den ewigen Fluch der Daten(in)konsistenz... (wobei... auch da fallen mir spontan zwei Ausnahmen ein... ich sach nur Oracle auf VMWare ESX - um mehrere DBs parallel auf einem Server zu betreiben :twisted: )

Was mir nur wichtig ist festzuhalten, dass MySQL-Server im Regelfall nicht(!) von gestandenen DB-Admins betreut werden, sondern von den Leuten, die mal eine DB installieren müssen, weil man ja jetzt Tool X braucht oder PHP-Coder Y mal schnell 'ne DB haben will.

mfg
Oli

jfreund wrote:Ein FS-Snapshot bei laufenden Writes kann aber ebenfalls zu einem kaputten Datenmurks im Backup führen (wobei PostgreSQL meist noch von selbst recovern kann, sofern das WAL noch einigermaßen intakt ist). 100% sicher ist man auch dort nur mit einem FS-Snapshot bei heruntergefahrener DB, oder wenigstens im RO-Betrieb.

Das lese ich jetzt erst: Wieso FS-Snapshot? PostgreSQL sichert man mit einem Dump und gut is, denn die Daten bleiben eingefroren aus der Sicht des zugreifenden Benutzers innerhalb einer Transaktion. D.h. es ist egal, wenn da jemand herumschreibt in der DB, während man sichert, PostgreSQL versteckt das vor dem zugreifenden Benutzer und somit kriegt man einen konsistenten Dump.

mfg
Oli

oschad wrote:Das lese ich jetzt erst: Wieso FS-Snapshot? PostgreSQL sichert man mit einem Dump und gut is, denn die Daten bleiben eingefroren aus der Sicht des zugreifenden Benutzers innerhalb einer Transaktion. D.h. es ist egal, wenn da jemand herumschreibt in der DB, während man sichert, PostgreSQL versteckt das vor dem zugreifenden Benutzer und somit kriegt man einen konsistenten Dump.

Auch MySQL erlaubt transaktionale Dumps (bei InnoDB: mysqldum --singe-transaction [...]). Das ändert aber nichts daran, dass ein Dump keine besonders tolle Backup-Methode ist. Ein Dump sichert alle Daten in der DB, ist nicht inkrementell oder differenziell. Ein Dump beschäftigt die Datenbank und die Platten eine ganze Weile und ist speicherineffizient. Bei Kindergarten-Datenbanken geht das alles noch, aber mach das mal mit einer großen OLTP-Datenbank im zweistelligen GB-Bereich... Besser ist ein Verfahren, das Point-in-Time Recovery erlaubt. Das geht sowohl mit einem Dump als Ausgangsbasis, als auch mit einem Snapshot der Datenbank-Repräsentation im File System. Letzteres ist mir lieber, da ich fast überall Snapshot-fähige Dateisysteme (ZFS) oder Layer (LVM2) im Einsatz habe. Nach dem Einspielen des Dumps (laufende DB-Server) oder einem Restore der Dateien (heruntergefahrener DB-Server) rolle ich mit dem WAL oder dem Binlog an den gewünschten Zeitpunkt heran.

Btw. wir geraten hier recht weit off topic. Wenn Interesse an einer weiteren Diskussion von Backup-Strategien für DB-Systeme besteht, würde ich die betreffenden Beiträge in einen neuen Fred verschieben.

matzewe01 wrote:

oschad wrote: Das lese ich jetzt erst: Wieso FS-Snapshot? PostgreSQL sichert man mit einem Dump und gut is, denn die Daten bleiben eingefroren aus der Sicht des zugreifenden Benutzers innerhalb einer Transaktion. D.h. es ist egal, wenn da jemand herumschreibt in der DB, während man sichert, PostgreSQL versteckt das vor dem zugreifenden Benutzer und somit kriegt man einen konsistenten Dump.

Erklär das doch mal genauer und auch den Umstand, warum im Unterschied zu Mysql, die Daten konsistenter sind als bei mysql und Transaktionen auf Basis der Innodb.

Ok, also bei jeglichen Zugriffen auf die PostgreSQL-DB, bekommt der Benutzer eine eingefrorene DB zu Gesicht, d.h. es gibt mehrere Sichten gleichzeitig auf die DB, nämlich die des zugreifenden Benutzers, für ihn ändert sich die DB während seines Zugriffs nicht, obwohl das natürlich tatsächlich durch konkurrierende Zugriffe passieren kann. Ein Zugriff ist ein einzelner SQL-Ausdruck oder aber eine Transaktion. Ich hab oben beides unter Transaktion zusammengefasst.

D.h. macht ein Benutzer ein lange dauerndes Lesen auf der DB und schreibt ein zweiter Benutzer während des Lesens in die zu lesenden Daten rein, dann sieht das Benutzer 1 nicht, er sieht die DB immer noch so, als wäre sie nicht verändert worden. Erst nach Ablauf seiner Anweisung bzw. nach Ablauf der Transaktion von Benutzer 1, sieht er die Änderung.

Das bedeutet bei konkurrierendem Zugriff auf die gleichen DB, der eine liest, der andere schreibt gleichzeitig die gleichen Daten, kann man die Daten nicht inkonsistent machen für den lesenden Zugriff.

Das führt dazu, dass man natürlich auch einen konsistenten Dump machen kann, was ja nichts anderes ist als alle DBs lesen, denn schreibende Zugriffe anderer Benutzer während des Dumps werden im Dump nicht sichtbar sein, somit sind die Daten auf DB-Ebene konsistent.

Genau dieses Verhalten hast du bei MySQL nicht, konkurrierende Zugriffe werden sichtbar. Wenn man es also genau nimmt, kann man mit MySQL gar nicht garantiert konsistent Daten lesen, da andere konkurrierende schreibende Zugriffe die Konsistenz zerstören können. Als Alternative kann man noch immer einen Lock setzen, bevor man was liest, aber das ist ja in der realen Welt gar nicht darstellbar so etwas, denn dann darf jede Applikation so oft versuchen zuzugreifen, bis man mal in einen freien Zeitschlitz fällt, bei sehr vielen Zugriffen oder abspackenden Applikationen ist das nicht wirklich lustig.

Mmh, also ich weiß nicht, ich finde MySQL an der Stelle einfach nicht gut.

mfg
Oli

matzewe01 wrote:Dann reden wir alle vom gleichen.
Mit Mysql und der Innodb als Tabellen Definition ist aber genau das möglich.
http://dev.mysql.com/doc/refman/5.1/de/ ... ation.html
Nur eine Frage der "Einstellung". Obs gelebt wird vom Entwickler / DBA, ist eine ganz andere Sache.

Und dann muss eben der autocommit off sein.

Ich glaube nicht, dass das ist, was ich meine. Du kannst nicht konkurrierend lesen und schreiben ohne Locking in MySQL. Deswegen macht man ja überhaupt Snapshots vom Dateisystem repsektive der Partition, weil das eben nicht geht.

matzewe01 wrote: Folgende Problematik trifft Dich aber auch auf Seiten Postgres,Oracle etc. soweit ich das weiss:

Tabelle 2 hat eine FK Referenz auf Tabelle 1.

Session1: Insert Tabelle1;
Session2: Select von Tabelle1;
Session1: Insert Tabelle2;
Session1: Commit;
Session2 Select von Tabelle2;

In diesem Fall liefert Dir jede DB, nach meinem Kenntisstand, einen nicht konsistenten Datenstamm.

Nein, denn wenn Daten aus mehreren Tabellen gelesen werden müssen mit mehreren Anweisungen und die Daten konsistent sein müssen, dann macht man natürlich eine Transaktion und innerhalb dieser Transaktion bekommt man den konkurrierenden Schreibzugriff nicht zu Gesicht.

Macht man was kaputt, d.h. kommt sich ins Gehege, beispielsweise löscht einer einen Tabelleneintrag, den der nächste modifizieren will, dann schlägt halt die Transaktion fehl. Das kann natürlich passieren, aber das ist jetzt eine deutlich weniger straffe Einschränkung und trifft lesenden Zugriff, den man beim Backup ja macht, gar nicht.

Genau das aber ist mein Punkt, ich will lesenden Zugriff für Backup konsistent haben, weil das muss ich als Admin einfach haben und ich will dafür nicht den Schreibzugriff abschalten müssen - ich kann das je nach Applikation einfach nicht. Vor allen Dingen will ich das auch, wenn das eingesetzte Dateisystem gerade mal keine Snapshots unterstützt, weil das in dieser Welt wirklich vorkommt. Zudem ist es noch fraglich, ob so ein Snapshot überhaupt alle wichtigen Daten enthält. Wir hätten da diverse Caches, die das ganze ziemlich inkonsistent machen könnten.

mfg
Oli

matzewe01 wrote:

oschad wrote: Ich glaube nicht, dass das ist, was ich meine. Du kannst nicht konkurrierend lesen und schreiben ohne Locking in MySQL. Deswegen macht man ja überhaupt Snapshots vom Dateisystem repsektive der Partition, weil das eben nicht geht.

http://dev.mysql.com/doc/refman/5.1/de/ ... -read.html

Consistent Read ist genau was Du willst!
Das Geplänkel um Transaktionen offensichtlich notwenidg und bei Dir ein offener Punkt des Wissensstandes.

Da hast du an der Stelle recht, mir war nicht bewusst, dass InnoDB das kann. Das Problem ist, dass jede Tabelle in einer DB, die nicht(!) InnoDB ist, alles kaputtmacht. Ich als Admin muss also immer nachschauen, sind alle Tabellen InnoDB, danach kann ich einen Dump machen, ansonsten nicht. Gut ist das nicht, aber wenigstens existiert da schonmal eine Lösung unter bestimmten Bedingungen.

Wenn man ein "CREATE TABLE" macht, was wirft MySQL denn da als Standard-Backend raus?

mfg
Oli

matzewe01 wrote:Ich weiss nicht, ob das eine einstellungssache ist, aber ich meine default ist MyIsam.

Um Myisam möglichst "transaktional" zu sichern, bietet sich die von mir genannte Master Slave Lösung und die Abkoppelung aus dem Sync Prozess an.

Na ja, ist halt einfach Mist in manchen Fällen.

matzewe01 wrote:Eine alternative wäre z.B. auch eine Partitionierung der Tabelle oder eine timestamp der dann Kriterium fürs Backup wird.

Das müssen die Daten dann aber erstmal hergeben, nicht jeder benutzt eine Tabelle nur zum Anhängen. Wie gesagt, unter Windows hast du jetzt einfach mal kein Backup, wenn du ohne Locking arbeitest und kein InnoDB durchgängig hast.

matzewe01 wrote: Transaktionen auf der DB Seite sind das eine, Geschäftstransaktionen auf Applikationsebene eine ganz andere Geschichte.
Ein "entsprechender" Bestellprozess von Warenkorb füllen, bezahlmethode wählen, bezahlen, stornieren usw, kann man unnmöglich in eine DB Transaktion packen.

Solange dein Datenmodell konsistent ist, musst du keine Transaktion machen. Wenn du Atomare Operationen brauchst, um Konsistenz zu gewährleisten, dann nimmt man Transaktionen. Sicher muss man den Warenkorb nicht transaktionsorientiert füllen, aber Bestände reduzieren und Bezahlen sollte schon in einer Transaktion laufen beispielsweise und das ist auch nicht so schwierig zu implementieren.

mfg
Oli

matzewe01 wrote:Ich weiss nicht, ob das eine einstellungssache ist, aber ich meine default ist MyIsam.

Default ist, was der DBA vorgibt. Wenn der DBA nichts vorgibt, ist es MyISAM.

oschad wrote:Das Problem ist, dass jede Tabelle in einer DB, die nicht(!) InnoDB ist, alles kaputtmacht. Ich als Admin muss also immer nachschauen, sind alle Tabellen InnoDB, danach kann ich einen Dump machen, ansonsten nicht.

Full ACK. MyISAM-Tabellen auf einem laufenden Server ohne Lock zu dumpen ist Harakiri und kann bös schiefgehen. Wenn der Server für den DBA eine Black Box ist und er sich nicht auf das Tabellen-Setup verlassen kann, ist ein Backup ohne Downtime nur mit Snapshots möglich (und bei intelligenter Verzeichnis-/Volume-Aufteilung sind auch Caches kein Problem). Ich bleibe allerdings dabei, dass Dumps zumindest bei großen Datenbanken keine praktikable Form des Backups darstellen - ein 50GB großes Dumpfile ist unhandlich, und der Restore dauert viel länger als ein zurückkopieren der Datenverzeichnisse. Unter dem Gesichtspunkt "wie schnell kann ich wieder Betriebsbereitschaft herstellen" gewinnt bei mir der Snapshot.

Allerdings würde ich auch den DB-Entwickler teeren, federn, pfählen und vierteilen, der MyISAM für schreibintensive Applikationen mit hohen Konsistenzanforderungen verwendet. Für so etwas (OLTP) nimmt man (wenn es schon MySQL sein muss) InnoDB (da gibt's dann noch ein paar andere Macken, wie etwa eine übergroße Empfindlichkeit der DB-Files). MyISAM ist für Systeme interessant, auf denen nur ganz selten bzw. nicht parallel geschrieben wird, wie etwa Data Warehouses (keine/kaum Schreibzugriffe) oder ein Logging-Backend (nur sequentielle Writes).

matzewe01 wrote:

oschad wrote: Solange dein Datenmodell konsistent ist, musst du keine Transaktion machen. Wenn du Atomare Operationen brauchst, um Konsistenz zu gewährleisten, dann nimmt man Transaktionen. Sicher muss man den Warenkorb nicht transaktionsorientiert füllen, aber Bestände reduzieren und Bezahlen sollte schon in einer Transaktion laufen beispielsweise und das ist auch nicht so schwierig zu implementieren.

Wie sollte eine konstitentes Datenmodell aussehen, wo eine Transaktion auf Rückmeldungen mehrer Backendsysteme abhängig ist?

Dann muss man halt einen Transaktionslayer obendrauflegen, ansonsten wird das schwer gehen.

mfg
Oli

matzewe01 wrote:

oschad wrote: Dann muss man halt einen Transaktionslayer obendrauflegen, ansonsten wird das schwer gehen.

;-) Wo wir dann bei der Zuständigkeit auf der Anwendungsbene sind.

Aber es macht ja keinen Sinn, dass man Fälle konstruieren kann, in denen man mit Transaktionen auf DB-Ebene nicht auskommt und daraus abzuleiten, dass MySQL kein Backup-Problem hat. Der Regelfall, den ich beobachte bei Kunden ist, dass DBs recht isoliert benutzt werden.

Ich sehe es deswegen so, dass man mit MySQL unter bestimmten Randbedingungen Backup machen kann, ansonsten eben nicht so richtig, obwohl das mit einem anderen DBMS gegangen wäre. Dann gibt es noch einige Fälle, in denen eine Datensicherung auch andere Datenspeicher zugleich umfasst, da braucht man für eine Datensicherung ein komplexeres Setup.

mfg
Oli