Sofortige Datenbankklone in PostgreSQL 18

• PostgreSQL 18 kann Datenbanken nahezu sofort klonen, indem es die Dateikopierstrategie (FILE_COPY) mit Dateisystem-Klonfunktionen kombiniert
• Mit dem neuen Konfigurationswert file_copy_method = clone lassen sich Klonfunktionen moderner Dateisysteme (FICLONE) wie XFS, ZFS und APFS nutzen
• Benchmark-Ergebnisse zeigen: Beim Klonen einer 6-GB-Datenbank benötigt die bisherige WAL_LOG-Methode etwa 67 Sekunden, die Klonmethode dagegen nur rund 0,2 Sekunden
• Geklonte Datenbanken teilen sich anfangs dieselben physischen Blöcke, werden bei Schreibvorgängen aber per Copy-on-Write getrennt
• Allerdings ist das Klonen nur ohne aktive Verbindungen möglich und funktioniert nur innerhalb eines einzelnen Dateisystems

---

PostgreSQLs templatebasierte Klonstruktur

• PostgreSQL erstellt bei CREATE DATABASE dbname intern eine Kopie der Datenbank template1 und erzeugt daraus die neue Datenbank
  • Das entspricht dem Verhalten von CREATE DATABASE dbname TEMPLATE template1
• Statt template1 kann auch eine andere Datenbank angegeben werden, sodass Klonen mit benutzerdefinierten Templates möglich ist
• In PostgreSQL 18 wurde dieses Template-System zu einer Struktur für sofortiges Klonen erweitert

CREATE DATABASE ... STRATEGY

• Seit PostgreSQL 15 gibt es den Parameter CREATE DATABASE ... STRATEGY, mit dem sich die Klonmethode auswählen lässt
  • Der Standardwert ist WAL_LOG und führt blockweises Klonen über das Write-Ahead Log aus
  • Diese Methode reduziert die I/O-Last und verbessert die Unterstützung für Parallelität, ist bei großen Klonvorgängen aber langsam
• Mit STRATEGY=FILE_COPY lässt sich zur klassischen Dateikopiermethode zurückkehren; PostgreSQL 18 ergänzt darauf aufbauend eine neue Klonoption

FILE_COPY und file_copy_method

• Die Einstellung file_copy_method in PostgreSQL 18 steuert die Dateikopiermethode auf Betriebssystemebene
  • Der Standardwert ist copy; dabei werden alle Bytes gelesen und an einen neuen Ort geschrieben
  • Bei clone wird die Klonfunktion des Dateisystems (FICLONE) verwendet, wodurch sofortiges Klonen ohne zusätzlichen Platzverbrauch möglich wird
• Unterstützte Dateisysteme: XFS, ZFS, APFS, FreeBSD ZFS
• Einrichtung
  • Den PostgreSQL-Cluster auf einem entsprechenden Dateisystem betreiben
  • file_copy_method = clone setzen und die Konfiguration neu laden

Benchmark-Ergebnisse

• Nach dem Erstellen einer Testdatenbank (source_db) mit rund 6 GB wurden zwei Methoden verglichen
  • WAL_LOG: 67.000ms (etwa 67 Sekunden)
  • FILE_COPY + clone: 212ms
• Bei derselben Datenmenge ergibt sich eine mehr als 300-fache Beschleunigung
• Die geklonte Datenbank (fast_clone) belegt nahezu keinen zusätzlichen Speicherplatz

Funktionsweise der geklonten Daten

• Bei Verwendung von file_copy_method = clone werden nur die Dateisystem-Metadaten geklont, sodass beide Datenbanken dieselben physischen Blöcke gemeinsam nutzen
• Die von PostgreSQL gemeldete Datenbankgröße bleibt die logische Größe (rund 6 GB)
• Bei Schreibvorgängen greift Copy-on-Write (COW) und trennt die betroffenen Seiten
  • Seiten mit geänderten Zeilen
  • Seiten, auf die neue Tupel geschrieben werden
  • Indexseiten sowie FSM-, Visibility-Map-Seiten usw.
• Auch bei einem VACUUM werden zusätzliche Seiten getrennt

Verifikation gemeinsam genutzter Blöcke unter XFS

• Mit dem Befehl filefrag -v lässt sich prüfen, ob zwei Datenbanken physische Blöcke gemeinsam nutzen
  • Im Ausgangszustand sind alle Extents als shared markiert
  • Werden einige Zeilen aktualisiert, werden die ersten 40 Blöcke (etwa 160 KB) getrennt und auf andere physische Adressen verschoben
  • Die übrigen Extents bleiben weiterhin gemeinsam genutzt

Hinweise und Einschränkungen

• Beim Klonen darf es keine aktiven Verbindungen zur Quelldatenbank geben
  • Das ist eine Einschränkung von PostgreSQL, kein Problem des Dateisystems
  • In produktiven Umgebungen ist die Nutzung einer separaten Template-Datenbank üblich
• Klonen ist nur innerhalb eines einzelnen Dateisystems möglich
  • Wenn mehrere Tablespaces auf unterschiedlichen Mount-Points liegen, wird auf normales Kopieren zurückgefallen
• In verwalteten Cloud-Diensten (AWS RDS, Google Cloud SQL usw.) ist diese Funktion nicht nutzbar, da kein Zugriff auf das Dateisystem möglich ist
  • Auf eigenen VMs oder Bare-Metal-Systemen ist vollständige Kontrolle möglich

Fazit

• Die Funktion file_copy_method = clone in PostgreSQL 18 nutzt Klonfunktionen auf Betriebssystemebene direkt, um
  die Klonzeit großer Datenbanken drastisch zu verkürzen
• Damit lassen sich in Test-, Entwicklungs- und Lernumgebungen Datenbank-Workflows mit sofortigem Klonen und schnellem Reset umsetzen
• Dabei müssen jedoch die Einschränkung aktiver Verbindungen und die Bindung an ein einzelnes Dateisystem in der Betriebsarchitektur berücksichtigt werden