Nehmen wir eine halbwegs aktuelle SATA2 Platte, die schafft um die 70 MByte/s. Das Kopieren von 10 Gigabyte Daten dauert dann selbst unterschiedlichen Quell- und Zielplatten im Optimalfall 2,5 Minuten.

Stell dir vor, zehntausende Webseiten eines großen Hosters würden jede Nacht für 2,5 Minuten nur “Error: Can’t connect to MySQL” statt der Webseiten anzeigen. Alle Blogs, alle Typo3-Seiten, alle Portale, Scripte, also einfach fast alles.

Stell dir vor, große Webauftritte (nennen wir mal Facebook, Twitter, heise.de & Co) würden 1x pro Nacht für 2,5 Minuten “Error: Can’t connect to MySQL” anzeigen. Wie peinlich wäre das wohl für die Betreiber.

Außerdem sind vernünftige SLA damit nicht erreichbar. Bei einer Backupzeit von 2,5 Minuten ergibt das selbst bei kurzen Monaten eine Gesamtausfallzeit von über 60 Minuten, im Jahr hätten wir so über 15 Stunden Ausfall wegen dem MySQL-Backup. Die Verfügbarkeit würde also nur wegen dem Backup auf 99,8% sinken. Damit wären weder 99,9% noch 99,99% möglich, was viele Hoster versprechen und viele Kunden fordern.

Ein Rsync kopiert nur veränderte Daten und ist damit im Schnitt deutlich schneller als ein cp und dank dem Lock steht die Datenbank für diese kurze Dauer nur zum Schreiben nicht bereit, kann aber weiterhin alle Daten anzeigen. Damit haben wir keine Fehlermeldungen. So muss es sein

Natürlich – so der jetzt vermutlich kommende Einwand – sind die Daten eines kleinen Privatservers nicht so groß und daher geht es schneller und stellt kein Problem dar. In diesem Fall kann man die stop-cp-start Methode durchaus anwenden, dennoch finde ich es auch bei kleinen Seiten unprofessionell, wenn sie einem Besucher plötzlich kurz eine Fehlerseite anzeigen, weil das Backup läuft. Dann würde ich doch eher den MySQL Dump empfehlen.

Eine weitere Alternative um lock Probleme etc. zu umgehen:
/etc/init.d/mysql stop
cp /var/lib/mysql/* -R /var/backups/mysql/
/etc/init.d/mysql stop

deutlich schneller als ein sql dump.

InnoDB unterstützt “per Table”-Tablespaces”:

http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html

Damit könnte man das Skript auch mit InnoDB einsetzen.

Zumal wird die zentrale ibdata-Datei nicht unnötig aufgebläht, wenn man Dateien löscht.

Hier meine abgewandelte Scriptvariante:

#!/usr/bin/perl
use DBI;
use POSIX qw(strftime);

##
## CONFIGURATION
##

## WARNING: USE ONLY WITH MyISAM!

my $MYSQL_HOST = “localhost”;
my $MYSQL_USER = “backup”;
my $MYSQL_PASS = “XXXXXXXX”;
my $ZFS_DATASET = “datapool/export/db/myisam”;

##
## END OF CONFIGURATION
##

my $SNAP_CMD = “/usr/sbin/zfs snapshot”;
# define a meaningful snapshot name including date and time
my $SNAP_SUFFIX = strftime “mysqlbackup-%Y-%m-%d-%H%M”, localtime;

# Open Database
my @DSN = (‘DBI:mysql:host=’.$MYSQL_HOST, $MYSQL_USER , $MYSQL_PASS);
my $DB = DBI->connect(@DSN) || exit 1;

# Output
print stdout “===============================================================================n”;
print stdout “MYSQL BINARY BACKUPn”;
print stdout “===============================================================================n”;
print stdout “n”;
print stdout “——————————————————————————-n”;
print stdout “Flush and lock tables, take ZFS snapshot, unlock tablesn”;
print stdout “——————————————————————————-n”;
print stdout “n”;

# Flush, Lock, ZFS snapshot, Unlock
$RESULT = $DB->prepare(‘FLUSH TABLES WITH READ LOCK;’);
$RESULT->execute();
system($SNAP_CMD.’ ‘.$ZFS_DATASET.’@’.$SNAP_SUFFIX);
$RESULT = $DB->prepare(‘UNLOCK TABLES;’);
$RESULT->execute();

# Output
print stdout “n”;
print stdout “——————————————————————————-n”;
print stdout “MySQL Backup done.n”;
print stdout “——————————————————————————-n”;

# End of script
$DB->disconnect();

.. genau einen solchen Ansatz habe ich gebraucht für unser Projekt, das bei einem Datenbankausfall fatale folgen hätte und daher stündlich gesichert wird. Bisher hatte ich das auch immer im laufenden Betrieb mit PHP gemacht, hatte aber zu den Zeiten immer einen erhöhten LOAD auf dem Server. Ich habe dies nun mit deinem Ansatz geändert und beobachtet. Ich konnte keinen wesentliche Erhöhung des LOAD nun feststellen, und das Backup geht nun auch innerhalb von Sekunden, ohne das das Projekt beeinträchtigt wird. Super Sache … Ich sag ganz herzlich DANKE

Gruß Jürgen

MyISAM speichert jede Tabelle in einer Datei, daher geht das mit dem RSync und Lock noch, wenn keine Mega-Tabellen dabei sind. Bei InnoDB dagegen werden alle Daten des gesamten Datenbankservers in einer Datei gespeichert, womit der Rsync bei JEDEM Update-Query alle Daten erneut kopieren muss – der Lock würde so viel zu lange dauern.

eine tolle Idee. Genau das was ich suche um eine Downtime von mittlerweile über 20 Minuten in den frühen Morgenstunden zu umgehen. Ich werde es mir bei Zeiten einmal anschauen und umsetzten.