PostgreSQL-Parameteränderungen: Wann Restart, wann Reload?

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: 

postgres=# select name from pg_settings where context='postmaster' order by name; 
                   name 
------------------------------------------ 
 archive_mode 
 autovacuum_freeze_max_age 
 autovacuum_max_workers 
 autovacuum_multixact_freeze_max_age 
 bonjour 
 bonjour_name 
 cluster_name 
 [...] 
 wal_buffers 
 wal_decode_buffer_size 
 wal_level 
 wal_log_hints 
(57 rows)  

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

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: 

postgres=# select pg_reload_conf(); 
 pg_reload_conf 
---------------- 
 t 
(1 row) 

postgres=# select name,setting from pg_settings where pending_restart; 
      name      | setting 
----------------+--------- 
 shared_buffers | 98304 
(1 row) 

Ä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: 

dbserver:/home/postgres [PG16]$ pg_ctl reload 
server signaled 
 
dbserver:/pgdata/PG16/log [PG16]$ tail -4 postgresql-Sat.log 
2024-01-13 21:13:06.444 CET []-[]-[] [1173] LOG:  received SIGHUP, reloading configuration files 
2024-01-13 21:13:06.446 CET []-[]-[] [1173] LOG:  invalid IP mask "scram-sha-256": Name or service not known 
2024-01-13 21:13:06.446 CET []-[]-[] [1173] CONTEXT:  line 127 of configuration file "/pgdata/PG16/pg_hba.conf" 
2024-01-13 21:13:06.446 CET []-[]-[] [1173] LOG:  /pgdata/PG16/pg_hba.conf was not reloaded 
 
postgres=# select * from pg_hba_file_rules where error is not null; 
-[ RECORD 1 ]----------------------------------------------------------- 
rule_number | 
file_name   | /pgdata/PG16/pg_hba.conf 
line_number | 127 
type        | 
database    | 
user_name   | 
address     | 
netmask     | 
auth_method | 
options     | 
error       | invalid IP mask "scram-sha-256": Name or service not known  

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