Datenbank in Recovery Modus nach Neustart

Hallo zusammen,

nach einem geplanten Wartungsfenster in dem wir unsere PostgreSQL Datenbanken von Version 15.7 auf 15.8 gepatched haben, treten nun bei 2 unserer 4 PostgreSQL Cluster Probleme auf (siehe folgenden Auszug aus dem Log):

2024-10-04 00:00:35.619 CEST [2075667] LOG: database system is ready to accept connections
2024-10-04 00:00:35.619 CEST [2988428] LOG: pg_wait_sampling collector started
2024-10-04 00:01:35.310 CEST [2075667] LOG: server process (PID 2988755) was terminated by signal 11: Segmentation fault
2024-10-04 00:01:35.310 CEST [2075667] DETAIL: Failed process was running: SELECT /* agent=‘pgstatmonitor’ */ “pg_stat_monitor”.“bucket”, “pg_stat_monitor”.“client_ip”, “pg_stat_monitor”.“query”, “pg_stat_monitor”.“calls”, “pg_stat_monitor”.“shared_blks_hit”, “pg_stat_monitor”.“shared_blks_read”, “pg_stat_monitor”.“shared_blks_dirtied”, “pg_stat_monitor”.“shared_blks_written”, “pg_stat_monitor”.“local_blks_hit”, “pg_stat_monitor”.“local_blks_read”, “pg_stat_monitor”.“local_blks_dirtied”, “pg_stat_monitor”.“local_blks_written”, “pg_stat_monitor”.“temp_blks_read”, “pg_stat_monitor”.“temp_blks_written”, “pg_stat_monitor”.“blk_read_time”, “pg_stat_monitor”.“blk_write_time”, “pg_stat_monitor”.“resp_calls”, “pg_stat_monitor”.“cpu_user_time”, “pg_stat_monitor”.“cpu_sys_time”, “pg_stat_monitor”.“rows”, “pg_stat_monitor”.“relations”, “pg_stat_monitor”.“datname”, “pg_stat_monitor”.“userid”, “pg_stat_monitor”.“top_queryid”, “pg_stat_monitor”.“planid”, “pg_stat_monitor”.“query_plan”, “pg_stat_monitor”.“top_query”, “pg_stat_monitor”.“application_name”, “pg_stat_monitor”.“cmd_type”, "pg_stat_mon
2024-10-04 00:01:35.310 CEST [2075667] LOG: terminating any other active server processes
2024-10-04 00:01:35.326 CEST [2988763] FATAL: the database system is in recovery mode
2024-10-04 00:01:35.329 CEST [2075667] LOG: all server processes terminated; reinitializing
2024-10-04 00:01:35.329 CEST [2075667] LOG: [pg_stat_monitor] pgsm_shmem_shutdown: Shutdown initiated.
2024-10-04 00:01:35.539 CEST [2988764] LOG: database system was interrupted; last known up at 2024-10-04 00:00:35 CEST
2024-10-04 00:01:35.694 CEST [2988764] LOG: database system was not properly shut down; automatic recovery in progress
2024-10-04 00:01:35.698 CEST [2988764] LOG: redo starts at 7D/6B00F900
2024-10-04 00:01:35.698 CEST [2988764] LOG: invalid record length at 7D/6B00F938: wanted 24, got 0
2024-10-04 00:01:35.698 CEST [2988764] LOG: redo done at 7D/6B00F900 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2024-10-04 00:01:35.701 CEST [2988765] LOG: checkpoint starting: end-of-recovery immediate wait
2024-10-04 00:01:35.706 CEST [2988765] LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.006 s; sync files=3, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB

Diese Meldungen kommen fast minütlich. Die Datenbanken sind dann für kurze Zeit verfügbar und versetzen sich wieder in den Recovery Modus.

Meine Vermutung warum das Problem aufgetreten ist, ist folgende: Wir haben die systemd Prozesse der PostgreSQL Cluster über einen SIGINT beendet, was dazu führte, dass offene Sessions einfach abrupt abgebrochen wurden. Im Log war dies auch zu sehen, das am besagten Tag mehrere Transaktionen abgebrochen wurden auf den betroffenen Clustern. Zukünftig werden wir die Prozesse über einen SIGTERM beenden.

Meine Frage wäre nun: Gibt es einen Weg, wie ich die PostgreSQL Cluster in solch einem Fall wieder reparieren kann?

Viele Grüße

Ist der Crash immer bei einer Abfrage auf pg_stat_monitor? Wenn ja, würde ich das Problem bei dieser externen Extension vermuten. Ein einfacher Weg, das zu testen, ist es, die Extension zu entfernen oder nicht mehr zu verwenden. Wenn das die Abstürze behebt, ist die Sache klar.
Das heißt noch nicht, daß es ein Bug von pg_stat_monitor ist. Aber die sinnvolle Vorgangsweise ist, das Problem bei den Autoren zu melden. Wenn die zur Erkenntnis kommen, daß es ein PortgreSQL-Problem ist, kann man es dort melden.

In der Dokumentation von pg_stat_monitor steht nichts.

Auf jeden Fall ist es wichtig, einen Stack Trace vom Crash anzufertigen. Das ist hier beschrieben. Um den Stack Trace sinnvoll zu machen, müssen die Debugging-Symbole für PostgreSQL installiert sein. So ein Stack Trace ist ein wichtiges Diagnosehilfsmittel, um den Fehler einzugrenzen.

1 „Gefällt mir“

Hi,

vielen Dank für den Hinweis mit pg_stat_monitor. Für mich sah es so aus, als hätte das Cluster komplett einen Fehler, aber mit der Neuinstallation von pg_stat_monitor konnte ich den Fehler beheben.

Vielen Dank und viele Grüße

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.