PostgreSQL Klone mit Reflink-Kopien (und was wir dadurch über Backups lernen können!)
April 21–22
Snapshots sind aus verschiedenen Gründen für PostgreSQL unpraktisch. Dennoch wünscht man sich oft eine schnelle Möglichkeit, eine Kopie des Datenverzeichnisses zu erstellen, idealerweise ohne dabei doppelt so viel Speicher zu belegen.
Wir können etwas Snapshot-ähnliches umsetzen, indem wir das "low level backup API" von PostgreSQL mit Reflink-Kopien kombinieren. Das erlaubt es uns, sparsame aber konsistente Klone zu erzeugen, die wir viel einfacher als Snapshots nutzen können und trotzdem von den Vorteilen profitieren können.
Solche Klone stellen einen Abzweig der Datenbank dar, auf dem wir Migrationsskripte testen können, sie können aber auch als Rückfallpunkt dienen, falls eine Wartung schief geht, oder Notfallwiederherstellungspunkte darstellen, als Alternative zu "echten" Snapshots.
Die Motivation für diesen Vortrag liefern einige unserer Kunden mit sehr großen Datenbanken, bei denen konventionelle Backup- und Recovery-Mechanismen in PostgreSQL zu langsam sind um die Ziele hinsichtlich Wiederherstellungszeit zu erfüllen. Mit einem robusten Mechanismus zum Erstellen von Klonen durch Reflinks können wir die Wiederherstellungszeit verkürzen.
Der große Vorteil bei der Benutzung von Reflinks gegenüber Snapshots ist, dass wir diese einfach in einem Maintstream-Dateisystem benutzen können: XFS. Es gibt zwar verschiedene Möglichkeiten, um Snapshots auf Dateisystemebene (ZFS, BTRFS, bcachefs) oder in einer Speicher-Abstraktionsschicht (LVM, virtualisierter Speicher, SAN) zu nutzen, jedoch unterliegen alle verschiedenen Beschränkungen. Außerdem sind Snapshots keine Möglichkeit, um innerhalb von Sekunden ein geklontes Datenverzeichnis zu erhalten, auf dem wir direkt PostgreSQL starten können.