Neue Features mit Streaming Replication

Das mit Version 9.0 eingeführte, eingebaute Replikationsverfahren über Streaming Replication erfährt von Hauptversion zu Hauptversion stetige Verbesserungen. Auch PostgreSQL 9.3 bleibt dieser Tradition treu und verbessert die Handhabung von Streaming Replication im Falle eines Failovers oder Recovery des primären Servers.

Wird der primäre Server durch eine Online-Sicherung wiederhergestellt, oder wird ein Failover auf einen anderen Streaming Replication Standby durchgeführt, so ändert die betroffene PostgreSQL-Instanz die sogenannte Timeline, eine Art Zeitschiene, auf die das Transaktionslog des Datenbankservers einschwenkt.

Dies ermöglicht auch das mehrfache Recovern einer Online-Sicherung, falls man beispielsweise den falschen Zeitpunkt für das Ende der Rücksicherung (Point In Time Recovery, PITR) gewählt hat. Alle anderen Streaming Standby müssen dieser Timeline folgen. Bis PostgreSQL 9.2 ist dies nur mit Hilfe des »restore_command« -Kommandos in der »recovery.conf« möglich, da ein Zugriff über ein Archiv mit allen archivierten Transaktionslogs notwendig ist. Dies enthält die sogenannten History-Dateien für den Wechsel der Timeline (alle Dateien enden mit ».history« ), die der Streaming Replication Standby benötigt, um diesen Wechsel nachzuvollziehen. Mit Version 9.3 fällt diese Notwendigkeit eines Archivzugriffes weg, Streaming Replication kann nun direkt einen Wechsel der Timeline nachvollziehen. Erforderlich ist nach wie vor das Setzen des Parameters »recovery_target_timeline='latest'« in der Konfigurationsdatei »recovery.conf« .

Neben der Möglichkeit, einen Hot-Standby-PostgreSQL-Server mithilfe des Parameters »trigger_file« zu einer vollwertigen PostgreSQL-Instanz zu delegieren, bietet PostgreSQL zusätzlich noch die Möglichkeit, dies über den Befehl »pg_ctl promote« zu implementieren. Mit der Version 9.3 gibt es hier zusätzlich die Möglichkeit, den Standby ohne Warten auf einen Checkpoint zur vollwertigen, schreibbaren Instanz zu machen. Hierzu muss die Kommandozeilenoption »-m fast« verwendet werden. Dies erspart unter Umständen eine längere Wartezeit, bevor die Instanz zum Schreiben zur Verfügung steht.

Mehr Speicher

Bis einschließlich PostgreSQL 9.2 war es für Einstellungen von »maintenance_work_mem« beziehungswiese »work_mem« nicht möglich, effektiv mehr als 2 GByte für Sortierungen im RAM zu nutzen. Dies lag an einer hartcodierten Beschränkung innerhalb der Datenbank. Besonders für DDL-Kommandos, die diesen Konfigurationsparameter nutzen, kommt dieser Beschränkung eine wichtige Bedeutung zu. So profitiert zum Beispiel nun das »CREATE INDEX« -Kommando effektiv von einer hohen Einstellung in »maintenance_work_mem« , wenn sehr große Indexe erzeugt werden müssen. Das Sortieren für den Aufbau des Index kann dann im Idealfall komplett per Quicksort im Speicher des Datenbankservers erfolgen, ohne auf das Storage-System ausweichen zu müssen.

Für Altsysteme, die diese Einstellung schon immer auf hohe Werte gesetzt hatten (auch wenn diese effektiv nie genutzt wurden), sollte der Wert jetzt jedoch geprüft werden. Ansonsten droht Gefahr, wenn die Einstellung plötzlich wirklich entsprechend hohe Speicherallozierungen auf dem System vornimmt.

Bereits in älteren PostgreSQL-Versionen konnte man mittels sogenannter Expression Indexes reguläre Ausdrücke indizieren. Allerdings funktionierte das nur für statische reguläre Ausdrücke und falls mehrere Suchbegriffe indiziert werden mussten, wurde es aufgrund der Vielzahl der benötigten Indexe schnell ineffektiv.