it-swarm-eu.dev

Ist es möglich, Datenbank-Snapshots mit PostgreSQL schnell zu erstellen / wiederherzustellen?

Zunächst einmal bin ich ein Entwickler, kein DBA oder Systemadministrator. bitte sei höflich :)

Ich arbeite an einem Anwendungsworkflow, bei dem eine einzelne Benutzeraktion komplexe Änderungen in der Datenbank auslöst - Hunderte von Datensätzen in einigen Tabellen erstellen, Hunderte von Datensätzen in anderen aktualisieren usw. Insgesamt etwa 12 Tabellen (von ~ 100) ) sind von dieser Aktion berührt. Aufgrund der Komplexität fällt es mir sehr schwer, alle Änderungen manuell rückgängig zu machen, bevor ich einen weiteren Test ausführen kann. Während des größten Teils meiner Entwicklungszeit kann ich einfach eine "ROLLBACK" -Anweisung gegen Ende des Workflows einfügen, aber wenn ich kurz davor bin, meine Änderungen festzuschreiben, muss ich die reale Sache testen.

Ich habe eine lokale Kopie der Produktionsdatenbank, mit der ich arbeiten kann. In meinem Fall ist das Speichern und Wiederherstellen zwischen Tests schneller als das Schreiben eines Skripts, um alle Änderungen rückgängig zu machen. Es ist schneller, aber es verlangsamt mich immer noch sehr (die Wiederherstellung dauert auf meinem alternden Laptop ungefähr 20 Minuten). Gibt es eine Möglichkeit, einen Schnappschuss des aktuellen Status der Datenbank zu speichern und ihn dann schnell wiederherzustellen?

Ich bin garantiert der einzige Benutzer im System und habe Root-Zugriff. Der Datenbankspeicherauszug beträgt ~ 100 MB, wenn er tariert und gzipiert wird. Die PostgreSQL-Version ist 8.3.

Vielen Dank im Voraus für hilfreiche Ideen.

54
Zilk

Sie könnten Snapshots auf Dateisystemebene verwenden, dies ist jedoch häufig recht umständlich, erfordert spezielle Dateisysteme und ist nicht immer verfügbar, insbesondere bei älteren Laptops. ;-);

Wie wäre es, wenn Sie Ihren Basisstatus als Datenbank erstellen und dann mithilfe der Funktion CREATE DATABASE ... TEMPLATE Eine neue Datenbank für Ihren Testlauf erstellen. Nach dem Test werfen Sie diese Datenbank weg. Dann ist Ihre Geschwindigkeitsbeschränkung im Wesentlichen nur die Zeit, um cp -R Das Datenbankverzeichnis. Das ist ungefähr so ​​schnell, wie Sie es ohne Dateisystem-Snapshot-Magie bekommen werden.

36

Verwenden Sie Stellar , es ist wie git für Datenbanken:

Mit Stellar können Sie die Datenbank schnell wiederherstellen, wenn Sie z. Schreiben von Datenbankmigrationen, Wechseln von Zweigen oder Durcheinander mit SQL. PostgreSQL und MySQL (teilweise) werden unterstützt.

12

Wenn Ihre Datenbank in Virtualbox ausgeführt wird, können Sie Snapshots problemlos speichern und Snapshots sowohl des Datenbankstatus als auch des Betriebssystems in wenigen Sekunden wiederherstellen (oder 1-2 Minuten, wenn Sie wirklich a haben) lot von Daten in der Datenbank oder im Betriebssystem oder sehr wenig Speicher, der der virtuellen Maschine zugewiesen ist) kostenlos.

In Ihren/den meisten Fällen ist es am besten, ein leichtes Linux (als einen Windows-Server) zu installieren, um die virtuelle Maschine auszuführen, auf der die Datenbank gehostet wird, sofern Sie erwähnen, dass auf Ihrem Laptop nur wenige Ressourcen verfügbar sind.


Auf der Produktionsseite verwende ich die Snapshot-Backups von MediaTemple , um das gleiche Ergebnis zu erzielen (aber es sind 20 $ pro Backup-Slot und spezifisch für diesen Webhosting-Service, sodass Sie möglicherweise nicht dazu passen).

5
wildpeaks

Wahrscheinlich nicht die Antwort, auf die Sie hoffen, aber haben Sie eine niedrigere Stufe des Schnappschusses in Betracht gezogen - zum Beispiel LVM?

Ich habe diese Frage gefunden, als ich versucht habe, dasselbe zu tun, und habe git im Datenverzeichnis postgresql verwendet. Das Verwerfen der Änderungen ist so einfach wie:

git reset --hard
2
user92843

Obwohl ich sagen muss, dass Stellar und git reset --hard Eine interessante Lösung sind, habe ich ein Problem mit größeren Datenbanken und Tests und verwende die Lösungen Virtualbox usw. Bei größeren Tests werden diese jedoch etwas "problematischer", wenn Sie Bare-Metal-Lösungen usw. verwenden.

Daher MUSS ich ZFS als Dateisystem erwähnen, um diese in Zukunft aus folgenden Gründen zu berücksichtigen, die @Peter Eisentraut ebenfalls erwähnte:

  1. Schnappschüsse - insbesondere wenn Sie eine Replikation von Prod nach QA/DR durchführen, können Sie dasselbe "Dateisystem" für die Tests verwenden:
#On a replication node, rather stop, snap, restore for a "consistent" backup ;)
su -l -c "/usr/bin/m2ee stop" acw_qa
pg_ctlcluster ${=QA} stop --force
zfs destroy -R $SNAPSHOT
pg_ctlcluster ${=REPLICATION} stop --force
zfs snapshot $SNAPSHOT
pg_ctlcluster ${=REPLICATION} start

zfs destroy $CLONE
zfs clone -o mountpoint=$CLONEDIR $SNAPSHOT $CLONE
rm $CLONEDIR/$CLUSTER/recovery.conf
pg_ctlcluster ${=QA} start
su -l -c "/usr/bin/m2ee start" acw_qa
  1. um einen Test durchzuführen, starten Sie kurz vor dem Test einen Postgresql-Stopp wie oben. zfs snapshot $SNAPSHOT Starten Sie den Postgresql. Stoppen Sie dann den Postgresql und stoppen Sie den Postgresql und nur zfs rollback $SNAPSHOT

  2. Komprimierung - Postgresql erhält eine typische 3: 1-Komprimierung in meinen Datenbanken, sodass Sie viele weitere Tests durchführen können;)

0
Hvisage

Eine weitere Möglichkeit, die experimentiert werden könnte, besteht darin, eine Kopie des postgresql-Datenverzeichnisses zu speichern und dann das vorhandene Verzeichnis mit der Kopie neu zu schreiben, wenn Sie es wiederherstellen möchten. Es wird mehr Speicherplatz auf der Festplatte benötigen, ist aber definitiv schneller als die Wiederherstellung von einem Backup. Ich bin mir jedoch nicht sicher, ob dies schneller als die Vorlagenmethode wäre. Daher wäre es eine gute Idee, zuerst einige Tests durchzuführen.

0
Haroldo_OK