Frage Jeden Tag eine 22-GB-MySQL-Datenbank sichern


Momentan kann ich das Backup mit mysqldump machen. Aber ich muss den Webserver herunternehmen UND es dauert ungefähr 5 Minuten, um das Backup zu machen. Wenn ich den Webserver nicht abnehme, dauert es ewig und wird nie beendet + die Website wird während des Backups nicht mehr zugänglich.

Gibt es eine schnellere / bessere Möglichkeit, meine 22 GB große und wachsende Datenbank zu sichern?

Alle Tabellen sind MyISAM.


26


Ursprung


Schaut euch diesen Link an zu einer ähnlichen Frage serverfault.com/questions/8044/backup-mysql-server - Charles Faiga


Antworten:


Ja.

Richten Sie die Replikation auf einem zweiten Computer ein. Wenn Sie eine Sicherungskopie erstellen müssen, können Sie die sekundäre Maschine sperren, mysqlhotcopy oder mysqldump ausführen und anschließend entsperren. Es wird sich wieder mit Ihrem Master verbinden und Sie müssen den Master nie offline nehmen.

Sie können dies sogar auf dem gleichen Computer tun, wenn es Ihnen nichts ausmacht, die Schreib-E / A zu verdoppeln, aber idealerweise sollten Sie es in Echtzeit auf einem zweiten physischen Server sichern und Ihre Snapshot-Backups so oft wie nötig erstellen ohne Ihren Produktionsserver zu stören.

Theoretisch ist es auch möglich, eine Datenbank mit einem bekannten Status und binlogs wiederherzustellen. Ich habe es noch nie gemacht, also bitte zuerst nachforschen, aber Sie können einen bekannten Zustand Ihrer Datenbank sichern, dann einfach alle neuen binlogs sichern und sie erneut abspielen, wenn Sie jemals wieder benötigt werden. Da binlogs linear geschrieben werden, wäre das rsyncing neuer binlogs auf einem entfernten Computer sehr schnell.

Bearbeiten: In der Tat sieht es so aus, als wäre die Verwendung von binlogs für die Sicherung dokumentiert.

Diese Frage ist sehr verwandt


28



Ja, das funktioniert super und würde meine Antwort sein. Der einzige große Nachteil ist, dass Sie müssen Stelle sicher dass die Replikation täglich korrekt funktioniert. Wir machen Schnappschüsse unserer Slave-Datenbank während der Geschäftszeiten und ein nächtliches Backup vom Master.


Entschuldigen Sie, dass das Betriebssystem Linux ist. Wenn Sie LVM nicht verwenden, sollten Sie es sein. Wenn dies der Fall ist, können Sie auf einfache Weise Backups über Snapshots erstellen.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Dadurch können Sie nächtliche Backups erstellen, ohne einen Slave-Server hinzufügen zu müssen. Ich bin sehr dafür, einen Slave-Server für hohe Verfügbarkeit zu haben, aber ich möchte nicht, dass Sie denken, dass Sie stecken bleiben, bis Sie diesen Slave erstellen können.


5





FLUSH-TABELLEN MIT READ LOCK möchten Sie nicht regelmäßig (oder nur halb-regelmäßig) auf einem Produktionssystem ausführen. Es sollte nur ein letzter Ausweg sein.

Richten Sie mindestens zwei Replikations-Slaves ein (dazu wird natürlich ein FLUSH TABLES WITH READ LOCK benötigt). Sobald sie eingerichtet sind, können Sie eine Sicherung aufheben, während die andere als Reserve-Master synchronisiert bleibt.

Wenn einer Ihrer Slaves ausfällt, können Sie einen Snapshot verwenden, um einen zweiten (oder dritten) Slave neu aufzubauen. Wenn alle Ihre Slaves fehlschlagen, kehren Sie zu FLUSH TABLES WITH READ LOCK zurück.

Denken Sie daran, immer einen Prozess zu haben, der regelmäßig prüft, ob die Daten synchron sind - verwenden Sie etwas wie mk-table-checksum, um dies zu tun (dies ist nicht sinnvoll einzurichten, konsultieren Sie die Maatkit-Dokumentation für Details).

Da 22 GB relativ klein sind, haben Sie keine Probleme damit. Dies mit einer großen Datenbank zu tun, könnte problematischer sein.


2





Die Lösung hier ist zweifach, wie oben beschrieben:

  1. Richten Sie die Replikation Ihres Servers auf einen Slave ein, den Sie offline nehmen können. Der beste Weg, dies zu tun, ist ein Dump der Datenbank mit mysqldump und dem Parameter --master-data.
  2. Richten Sie nächtliche Backups auf dem Slave ein. Sie können entweder mysqldump mit den Flags --master-data --flush-logs und --single-transaction verwenden, oder Sie können den mysql-Server stoppen, die Datendateien auf der Festplatte kopieren und neu starten (die Replikation wird wo aufgenommen) es hat aufgehört).
  3. Führen Sie jedes Skript (z. B. 5, 10, 20 Minuten) auf dem Slave aus, um zu überprüfen, ob mysql noch repliziert. Ich schrieb ein einfaches Python-Skript um es zu tun, was du gerne benutzen kannst.

Beachten Sie, dass Sie, wenn Sie InnoDB für Ihre Tabellen verwenden, das Flag --singletransaction verwenden können, um Tabellensperren zu vermeiden und dennoch einen konsistenten Dump der Datenbank auch auf dem Master zu erhalten und somit Ihre Backups ohne zu machen Herunterfahren des Servers. Die obige Lösung ist jedoch eine bessere.

Wenn Sie LVM unter Linux verwenden, können Sie auch einen LVM-Snapshot der Partition erstellen und diesen dann sichern. LVM-Snapshots sind unteilbar. Wenn Sie also "Tabellen mit Lesesperre spülen" und dann Ihren Snapshot erstellen und entsperren, erhalten Sie einen konsistenten Snapshot.

Wenn Sie über E / A-Konflikte besorgt sind, die den Speicherauszug zu lange dauern lassen, können Sie einen dritten Computer hinzufügen und mysqldump über das Netzwerk ausführen, um zu vermeiden, dass Ihre Datenträger durcheinander geraten.


1





Sie könnten eine schrittweise Sicherung durchführen. Backup 1/24 der Datensätze jede Stunde. Das einzige Problem mit diesem Ansatz ist, wenn es während der ersten paar Stunden des Tages abstürzt, verlieren Sie alles von dieser Zeit bis zum Zeitpunkt des Absturzes. Wie auch immer, es sind weniger als 24 Stunden verlorener Datensätze (ich weiß nicht, wie wichtig das für Sie ist).


0





Abhängig von Ihrer Umgebung sind Schnappschüsse in der Regel eine hervorragende Möglichkeit. Vor allem, wenn Sie den Master aus irgendeinem Grund sichern müssen. Wir führen Master- und Slave-Paare aus und verwenden für beide Snapshot-Backups.

  1. FLUSH TABLES WITH READ LOCK;
  2. Ziehen Sie einen Snapshot für die Datenbank und Protokolldateisysteme.
  3. UNLOCK TABLES;
  4. Kopieren Sie Ihre Datendateien aus dem Snapshot in Ihrer Freizeit.

Mit InnoDB-Tabellen möchten Sie vielleicht laufen SET AUTOCOMMIT=0; bevor Sie die Lesesperre ausführen.


0





Schau dir an "Best Practice zum Sichern einer MySQL-Produktionsdatenbank?"Es ist ein ähnlicher Beitrag auf Stack Overflow.


0