Script: MySQL DB-Dump mit wenig Serverbelastung

[fork]

Hi,

ich hatte ein Problem mit einem Server von mir(Zarafa). Immer wenn der DB-Dump lief, dann war damit auch der Mailserver teilweise nicht erreichbar. (Zarafa wirft fast alles in die Datenbank. D. h. die DB ist relativ gross - bei mir 20 GB). Der Dump hat wohl zu viel Last erzeugt. Deswegen habe ich mir ein kleines Script geschrieben, dass diverse Methoden zum verringern der Last umsetzt.

Vielleicht könnt Ihr das Script ja auch gebrauchen.

Das Script ist hier:

https://github.com/deadbulb/mysql-db-backup

Per git holen:

git clone https://github.com/deadbulb/mysql-db-backup.git

Grüße,
fork();

[DrunkenFreak]

Warum nicht einfach die Prioritäten ändern?

[fork]

Das wird auch getan(mit "nice"), aber das reicht nicht. Ich bin mir auch noch nicht sicher, ob da nicht noch etwas ganz anderes mit rein spielt. Irgendwelche Schreibpuffer von der DB voll oder so.

[marce]

Am schlimmsten, auch für die Performance der jeweiligen Anwendung, die auf die DB zugreift ist meist die Tatsache, daß für ein Export der DB ein Lock auf die Tabellen gesetzt iwird - und je nach dem, wie "glücklich" die Anwendung mit einer gelockten Tabelle umgeht sie halt mehr oder weniger ihre Funktion einstellen kann :-)

... in dem Fall wäre es sogar kontraproduktiv, die Geschwindigkeit des Dumps herunterzusetzen - da in dem Fall des Lock länger bestehen würde...

Wenn man dann noch überlegt, wie die DB bei einem Dump an sich reagiert (Transaktionssicherheit und so'n Kruscht) - kommt man manchmal auch nicht durmrum, auf die DB zugreifende Dienste einfach zu beenden...

[fork]

Soweit ich das verstanden habe setzt mysqldump --single-transaction keine Locks. In der manpage von mysqldump steht nur dazu, dass keine ALTER/DROP/RENAME TABLES moeglich sind.

Ich vermute aber, das bei der Geschichte irgendwie ein Transaktionspuffer vollläuft, ohne genau einen Dunst davon zu haben, wie das bei vielleicht MySQL abläuft.

[marce]

hm...:
http://dev.mysql.com/doc/refman/5.1/de/mysqldump.html sagt

shell> mysqldump --all-databases --single-transaction > all_databases.sql

Diese Datensicherung muss vor Beginn des Speicherauszugsvorgangs lediglich (mit FLUSH TABLES WITH READ LOCK) eine globale Lesesperre für alle Tabellen erwirken.

, in Verbindung mit
http://mysqlha.blogspot.de/2008/07/w...bles-with.html

The implementation does this:

set the global read lock - after this step, insert/update/delete/replace/alter statements cannot run
close open tables - this step will block until all statements started previously have stopped

... durchaus geeignet, eine Anwendung in einen Warte-Zustand zu bringen.

Um ein konsistenten Dump einer DB zu erzeugen muss im Prinzip die komplette Datenbank gesperrt werden und der Dump idealerweise in einer Transaktion ablaufen. Das lustige bei MySQL ist dabei noch, daß nicht jede Speicherengine sowas wie Transaktionen beherrscht...

Wobei man die Kirche auch im Dorf lassen muss - wirklich relevant sind die Einschränkungen diesbezüglich nur in sehr wenigen Fällen, das meiste davon kann man durch geschickte Programmierung abfangen...

[fork]

Hmmm...

So richtig zufriedenstellend ist das noch nicht. Das muss doch irgendwie gehen.
Nun gut. Back to RTFM....

[nopes]

Jaja MySQL und ihre Table Engines, afaik muss man für ACID konformes sichern ein extra Tool einsetzten, welches es früher nur zu kaufen gab - MySQL Hotbackup ~500$ oder so, inzwischen gibt es eine freie Alternative - XtraBackup. Jedenfalls für mich schon länger ein Grund, MySQL nicht mehr zu nutzen.

[fork]

Ansonsten habe ich gerade gemerkt, dass da doch noch noch teilweise MyISAM für die Tabellen verwendet wird und nicht InnoDB wie angenommen....