Postgresql Cluster ist instabil

Ich hoffe jemand kann mir mit meinem aktuellen Postgresl Cluster Problem helfen. Ich habe den Cluster nach dieser Anleitung erstellt. -> https://github.com/vitabaks/postgresql_cluster Mein aktuelles Problem besteht darin, dass der Cluster nicht stabil und nicht einwandfrei läuft. Wenn ich den im folgenden Bild angezeigten Befehl ausführe, zeigt er mir an, dass er schon über 200TL hat. Der Wert sollte jedoch bei 0 liegen und nicht über 200.

image

Wenn ich die history von dem Cluster auf sql3 abfrage (Leader), sehe ich wie einige failovers/switchovers manchmal innerhalb weniger Minuten oder Stunden stattfinden.

Ich habe die Log Dateien von TL 242 auf dem sql3 (Leader) als Beispiel hier abgefragt und aufgelistet.

2020-07-08 15:39:03 CEST [9606-9] LOG: received immediate shutdown request
2020-07-08 15:39:09 CEST [9618-1] xx.xxx.xxx.66(23258) replicator@[unknown] WARNING: terminating connection because of crash of another server process
2020-07-08 15:39:09 CEST [9618-2] xx.xxx.xxx.66(23258) replicator@[unknown] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-07-08 15:39:09 CEST [9618-3] xx.xxx.xxx.66(23258) replicator@[unknown] HINT: In a moment youshould be able to reconnect to the database and repeat your command.
2020-07-08 15:39:09 CEST [9623-1] [local] postgres@postgres WARNING: terminating connection because of crash of another server process
2020-07-08 15:39:09 CEST [9623-2] [local] postgres@postgres DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-07-08 15:39:09 CEST [9623-3] [local] postgres@postgres HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-07-08 15:39:09 CEST [9619-1] xx.xxx.xxx.67(2330) replicator@[unknown] WARNING: terminating connection because of crash of another server process
2020-07-08 15:39:09 CEST [9619-2] xx.xxx.xxx.67(2330) replicator@[unknown] DETAIL: The postmasterhas commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-07-08 15:39:09 CEST [9619-3] xx.xxx.xxx.67(2330) replicator@[unknown] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-07-08 15:39:09 CEST [9629-1] WARNING: terminating connection because of crash of another server process
2020-07-08 15:39:09 CEST [9629-2] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2020-07-08 15:39:09 CEST [9629-3] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2020-07-08 15:39:09 CEST [9606-10] LOG: archiver process (PID 9630) exited with exit code 1
2020-07-08 15:39:09 CEST [9606-11] LOG: database system is shut down
2020-07-08 15:39:10 CEST [20437-1] LOG: database system was interrupted; last known up at 2020-07-08 12:57:43 CEST
2020-07-08 15:39:10 CEST [20438-1] [local] postgres@postgres FATAL: the database system is starting up
2020-07-08 15:39:10 CEST [20440-1] [local] postgres@postgres FATAL: the database system is starting up
2020-07-08 15:39:10 CEST [20437-2] WARNING: specified neither primary_conninfo nor restore_command
2020-07-08 15:39:10 CEST [20437-3] HINT: The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2020-07-08 15:39:10 CEST [20437-4] LOG: entering standby mode
2020-07-08 15:39:10 CEST [20437-5] LOG: database system was not properly shut down; automatic recovery in progress
2020-07-08 15:39:10 CEST [20437-6] LOG: redo starts at 0/31000108
2020-07-08 15:39:10 CEST [20437-7] LOG: consistent recovery state reached at 0/32000000
2020-07-08 15:39:10 CEST [20434-7] LOG: database system is ready to accept read only connections
2020-07-08 15:39:11 CEST [20437-8] LOG: received promote request
2020-07-08 15:39:11 CEST [20437-9] LOG: redo done at 0/310001F0
2020-07-08 15:39:11 CEST [20437-10] LOG: selected new timeline ID: 254
2020-07-08 15:39:11 CEST [20437-11] LOG: archive recovery complete
2020-07-08 15:39:11 CEST [20441-1] LOG: checkpoint starting: force
2020-07-08 15:39:11 CEST [20434-8] LOG: database system is ready to accept connections
2020-07-08 15:39:11 CEST [20441-2] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.006 s, sync=0.000 s, total=0.088 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16383 kB, estimate=16383 kB
2020-07-08 15:39:12 CEST [20441-3] LOG: checkpoint starting: immediate force wait
2020-07-08 15:39:12 CEST [20441-4] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.000 s, total=0.027 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=14745 kB*

Irgendwie passiert das viel zu häufig. In der ersten Zeile ist zu erkennen, dass der Cluster eine Anfrage bekommt sich herunterzufahren. Aber leider kann ich nicht herausfinden woher und von wem. Seit ich diesem Problem begegnet bin, bin ich mir nict sicher wie ich dieses lösen kann und hoffe auf die Hilfe der Community, das zu lösen. Vielleicht gibt es jemand mit einem ähnlichen Problem und es wird auch anderen noch helfen.

  • was hast Du an RAM, max_connections und work_mem?
  • sind irgend welche Extensions installiert, die NICHT aus Contrib stammen?
  • gibt es im Systemlog (also Linux) Out Of Memory - Kills?

Wichtig ist, rauszubekommen, warum da Prozesse wegsterben. Eine falsche Konfiguration von work_mem und max_connections wird immer wieder gern verwendet, um dies hinzubekommen.

Vielen Dank schon mal für deine Antwort.
Also RAM ist : ich habe 3 nodes a 4GB RAM
max_connections: 100
work_mem: 128MB

es sind keine Extansions installiert. Im Systemlog gibt es auch keinen Out Of Memory - Kills.
was wären denn die passenden Werte für die Konfiguration ?

Moin,

okay, wenn keine OOM im Log zu sehen sind, gibt es wohl auch keine.

Mit Patroni kann ich nicht viel sagen, wird von uns nicht unterstützt. Gibt es denn da ein Log, was erhellend sein könnte?

Hey leider nein… werde aber mal weiter suchen, ob ich etwas finde. Vielen Dank für deine Mühe.