Ich habe über das nachgedacht, was Sie geschrieben haben, und hier sind einige Ideen für Sie:
- Wenn Sie eine Sicherung benötigen, die bis zu einem bestimmten Zeitpunkt wirklich konsistent ist, müssen Sie pg_basebackup oder pg_barman verwenden (verwendet intern pg_basebackup) - die Erklärung finden Sie unter 1. Link unten. Das neueste pg_basebackup 10 streamt WAL-Protokolle, sodass Sie auch alle Änderungen sichern, die während des Backups vorgenommen wurden. Natürlich dauert dieses Backup nur die gesamte PG-Instanz. Andererseits sperrt es keine Tabelle. Und wenn Sie dies von einer Remote-Instanz aus tun, verursacht dies nur eine geringe CPU-Last auf der PG-Instanz, und die Festplatten-E / A ist nicht so groß, wie einige Texte vermuten lassen. Siehe Links 4 über meine Erfahrungen. Die Wiederherstellung ist ganz einfach - siehe Link 5.
- Wenn Sie pg_dump verwenden, müssen Sie sich darüber im Klaren sein, dass Sie keine Garantie dafür haben, dass Ihre Sicherung zum Zeitpunkt wirklich konsistent ist - siehe erneut Link 1. Es besteht jedoch die Möglichkeit, Snapshots der Datenbank zu verwenden (siehe Links 2 und 3). Auch dabei kann man sich nicht auf 100% Konsistenz verlassen. Wir haben pg_dump nur auf unserer analytischen Datenbank verwendet, die nur 1x pro Tag neu lädt (gestrige Partitionen aus der Produktionsdatenbank). Sie können es mit der parallelen Option beschleunigen (funktioniert nur für das Verzeichnissicherungsformat). Der Nachteil ist jedoch eine viel höhere Belastung der PG-Instanz - höhere CPU-Auslastung, viel höhere Festplatten-IO. Auch wenn Sie pg_dump remote ausführen - in diesem Fall speichern Sie nur Festplatten-IO zum Speichern von Sicherungsdateien. Außerdem muss pg_dump eine Lesesperre auf Tabellen setzen, damit es entweder mit neuen Einfügungen oder mit der Replikation kollidieren kann (wenn es auf Replikaten übernommen wird). Aber wenn Ihre Datenbank Hunderte von GB erreicht, kann sogar ein paralleler Dump Stunden dauern, und in diesem Moment müssten Sie sowieso zu pg_basebackup wechseln.
- pg_barman ist eine "komfortable Version" von pg_basebackup + es ermöglicht Ihnen, Datenverlust zu verhindern, selbst wenn Ihre PG-Instanz sehr stark abstürzt. Um es zum Laufen zu bringen, sind mehr Änderungen erforderlich, aber es lohnt sich auf jeden Fall. Sie müssen die WAL-Protokollarchivierung einstellen (siehe Link 6) und wenn Ihr PG <10 ist, müssen Sie "max_wal_senders" und "max_replication_slots" einstellen (die Sie sowieso für die Replikation benötigen) - alles ist im pg-barman-Handbuch obwohl Beschreibung ist nicht gerade toll. pg_barman streamt und speichert WAL-Aufzeichnungen auch zwischen Backups, sodass Sie auf diese Weise sicher sein können, dass im Falle eines sehr schweren Absturzes fast kein Datenverlust auftritt. Aber es zum Laufen zu bringen, kann viele Stunden dauern, weil die Beschreibungen nicht gerade gut sind. pg-barman führt mit seinen Befehlen sowohl Backup als auch Wiederherstellung durch.
Ihre Datenbank ist 5 GB groß, sodass jede Sicherungsmethode schnell ist. Aber Sie müssen entscheiden, ob Sie eine Point-in-Time-Wiederherstellung und nahezu keinen Datenverlust benötigen oder nicht – ob Sie also Zeit investieren, um pg-barman einzustellen oder nicht.
Links:
- PostgreSQL, Backups und alles das musst du wissen
- Rezension für Paper:14-Serializable Snapshot-Isolation in PostgreSQL - über Schnappschüsse
- Paralleles Dumping von Datenbanken - Beispiel für die Verwendung von Snapshots
- pg_basebackup-Erfahrungen
- pg_basebackup - Tar-Sicherung wiederherstellen
- Archivieren von WAL-Protokollen mit Skript
