PostgreSQL^® 11: Checksummen und Basebackups

Die zweite Beta-Version von PostgreSQL^® 11, welche sich nun im Feature-Freeze befindet, ist kürzlich erschienen. Zeit also, einige Verbesserungen vorzustellen, die credativ zu dieser Version im Bereich Checksummen und Basebackups beigetragen hat.

Checksummen-Überprüfung während Basebackups

Checksummen für den Tabellen und Indexen zugeordneten Dateien können seit Version 9.3 beim Anlegen einer PostgreSQL^®-Instanz verwendet werden und warnen bei Bitfehlern in einzelnen Daten-Pages. Sie ermöglichen damit die frühzeitige Erkennung von Storage-Problemen. Allerdings wurden diese bisher nur im Rahmen von Abfragen geprüft, wenn auf den entsprechenden Datensatz zugegriffen wurde. Eine explizite Prüfung ist erst ab Version 11 mit dem neuen pg_verify_checksums Tool möglich, welches allerdings nur bei ausgeschalteter Instanz funktioniert.

Unsere Änderung erlaubt nun Checksummen beim Erstellen eines Basebackups zu überprüfen. Da bei einem Basebackup naturgemäß alle Datenblöcke gelesen werden müssen, ist dies eine gute Gelegenheit deren Konsistenz zu überprüfen. Checksummen-Fehler werden dabei als Warnungen und nicht als Fehler geloggt, damit nicht das gesamte Basebackup abgebrochen werden muss. Dem normalerweise für die Erstellung von Basebackups bzw. Standby Clones verwendeten Programm pg_basebackup wurde eine Option --no-verify-checksums hinzugefügt, die optional diese Überprüfung abschaltet.

Replikations-Slots bei Basebackups

Die zweite Änderung betrifft die Behandlung von Replikations-Slots von pg_basebackup bei der Erstellung von Standby-Servern. Diese erlauben es einem Primary, die für den im Slot spezifizierten Standby benötigten Transaktionslogs vorzuhalten, auch wenn dieser temporär nicht verfügbar ist. Zwar konnte man pg_basebackup einen Replikations-Slot nennen, welcher dann während des Basebackups verwendet wird, allerdings musste dieser bereits vorher manuell angelegt worden sein, da es ansonsten zu einer Fehlermeldung kommt. Unsere Änderung erlaubt nun mit der neuen Option -C bzw. --create-slot in einem Kommando einen Standby-Clone inklusive Verwendung von Replikations-Slots zu erstellen:

$ pg_basebackup -v -h primary.lan -D data --slot=standby1 --create-slot --write-recovery-conf
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1D000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created replication slot "standby1"
pg_basebackup: write-ahead log end point: 0/1D0000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
$ cat data2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=postgres passfile=''/var/lib/postgresql/.pgpass'' host=primary.lan
  port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'standby1'

Danach muss nur noch der Standby gestartet werden und repliziert nun automatisch.

Darüberhinaus wurden einige weitere kleine Verbesserungen an pg_basebackup bzw. dessen Tests von uns umgesetzt.

Paralleler Dump nach /dev/null

Einen Patch, der es nicht in das Release schaffte, wollen wir aber dennoch vorstellen: Paralleler pg_dump nach /dev/null im Directory-Format. Grund hierfür ist die gebräuchliche Verwendung von pg_dump für die Überprüfung von PostgreSQL^®-Instanzen auf Fehler, wobei als Zielort /dev/null verwendet wird, sodass kein zusätzlicher Speicherplatz benötigt wird. Das Problem hierbei ist, dass /dev/null nur im Custom-Format verwendet werden kann, welches aber keine Parallelität erlaubt. Das Directory-Format erlaubt zwar mehrere Prozesse gleichzeitig zu verwenden, allerdings nicht in Verbindung mit /dev/null; letzteres wird durch unseren vorgeschlagenen Patch ermöglicht.

Die Begründung für die Ablehnung war nicht technischer Natur, sondern das pg_dump kein Diagnose-Werkzeug ist und deswegen keine spezielle Unterstützung hierfür eingebaut werden sollte. Nichtsdestotrotz funktioniert der vorgeschlagene Patch und wird auch bei Kunden von uns eingesetzt. Versionen des Patches für PostgreSQL^® 9.3, 9.4, 9.5, 9.6 und 10 sind verfügbar.