Das Einrichten und Verwalten einer PostgreSQL-Datenbank erfordert oft die Anpassung von Konfigurationsparametern, um die Leistung, Sicherheit und/oder Funktionalität zu optimieren. Bei der Änderung von Parametern stellt sich oft die Frage: Wann ist ein Neustart des PostgreSQL-Clusters erforderlich, wann genügt ein Reload? 

Cluster-Neustart versus Reload

Bevor wir uns mit den spezifischen Parametern befassen, ist es wichtig zu verstehen, was ein Cluster-Neustart und ein Reload genau bedeuten. Ein Cluster-Neustart beendet den PostgreSQL-Cluster und startet ihn erneut. Dies führt zu einer kurzen Downtime, während dieser der Cluster nicht verfügbar ist. Laufende Sitzungen und Abfragen werden beim Restart abgebrochen. Auf der anderen Seite führt ein Reload dazu, dass die laufende PostgreSQL-Instanz die Konfigurationsdateien erneut lädt, ohne den gesamten Server neu zu starten. Reloads ermöglichen es, Änderungen ohne Downtime umzusetzen. 

Woran erkennt man, welche Parameter einen Neustart erfordern?

Variante 1 - postgresql.conf

In der sehr gut dokumentierten Standard-Konfigurationsdatei postgresql.conf sind alle Parameter, die einen Neustart erzwingen, mit dem Hinweis „(change requires restart)“ versehen 

Variante 2 - View pg_settings:

Alle Parameter in der View pg_settings, die in der Spalte context den Wert „postmaster“ haben, erfordern bei einer Änderung einen Restart des PostgreSQL-Clusters: 

Einige Beispiele für Parameter, die einen Cluster-Neustart erfordern

​archive_mode	​Ein-/Ausschalten der WAL-Archivierung
​cluster_name	​Cluster-Name in der Prozessliste
​huge_pages	​Verwendung von Huge-Pages
​listen_addresses	​IP-Adressen, auf die der Cluster „hört“
​max_connections	​Maximale Anzahl gleichzeitiger Datenbank-Sitzungen
​port	​Port, auf den der Cluster „hört“
​shared_buffers	​Anzahl der Buffer im Hauptspeicher​
shared_preload_libraries​	​Liste der Bibliotheken für Erweiterungen​
superuser_reserved_connections​	​Anzahl der Verbindungen, die für den Superuser reserviert sind
​wal_buffers	​Größe des WAL-Buffers im Hauptspeicher

Kontrolle nach einem Reload

Wenn man nach einem Reload kontrollieren möchte, ob es nicht vielleicht doch eine Parameteränderung gab, die einen Restart erfordert hätte, dann hilft die View pg_settings mit der Spalte pending_restart: 

Änderungen an der pg_hba.conf

Bei Änderungen an den Access Control Lists (ACL) in der pg_hba.conf, reicht immer ein Reload der Konfiguration. Wenn es allerdings einen Fehler in der geänderten pg_hba.conf gibt, dann wird die Konfiguration nicht eingelesen. Dies ist allerdings nur in der Log-Datei des PostgreSQL-Clusters oder in der View pg_hba_file_rules erkennbar, denn der „pg_ctl reload“ bringt in diesem Fall leider keine Fehlermeldung.

Beispiel: 

Fazit

Es ist wichtig, die Auswirkungen von Parameteränderungen auf den PostgreSQL-Cluster zu verstehen, um unnötige Downtime zu minimieren und eine reibungslose Aktualisierung zu gewährleisten. Bei Änderungen an kritischen Parametern wie „shared_buffers“ oder „max_connections“ ist ein Cluster-Neustart erforderlich, während weniger kritische Einstellungen oft durch einen Reload aktualisiert werden können. Das Vermeiden von unnötigen Restarts erhöht die Verfügbarkeit der Datenbanken und der Applikationen. 

Seminarempfehlung