it-swarm.com.de

Logische Replikation nach Postgresql 11 - im Status "Aufholen" stecken

Ich verwende zwei Postgresql 11-Server - Master und Slave (Setup mit logischer Replikation).

Das Problem, mit dem ich konfrontiert bin, ist, dass heute nach Wochen ununterbrochener Arbeit der Sklave nicht mehr mit dieser Fehlermeldung synchronisiert ist:

2019-09-16 07:39:44.332 CEST [30117] ERROR:  could not send data to WAL stream: server closed the connection unexpectedly
                This probably means the server terminated abnormally
                before or while processing the request.
2019-09-16 07:39:44.539 CEST [12932] LOG:  logical replication apply worker for subscription "logical_from_master" has started
2019-09-16 07:39:44.542 CEST [27972] LOG:  background worker "logical replication worker" (PID 30117) exited with exit code 1

Ich habe diese Fehlermeldung schon einmal gesehen und mein Prozess bestand darin, wal_sender_timeout on master (mehr dazu hier: logische Replikation in postgresql - "Server hat die Verbindung unerwartet geschlossen" )

Also wollte ich die Replikation wiederherstellen, aber der Replikationsstatus bleibt beim Aufholen hängen:

master=# select * from pg_stat_replication;
  pid  | usesysid | usename | application_name  |  client_addr  | client_hostname | client_port |         backend_start         | backend_xmin |  state  |   sent_lsn   |  write_lsn   |  flush_lsn   |  replay_lsn  |    write_lag    |    flush_lag    |   replay_lag    | sync_priority | sync_state
-------+----------+---------+-------------------+---------------+-----------------+-------------+-------------------------------+--------------+---------+--------------+--------------+--------------+--------------+-----------------+-----------------+-----------------+---------------+------------
 86864 |    16680 | my_user    | logical_from_master | 10.10.10.10 |                 |       46110 | 2019-09-16 12:45:56.491325+02 |              | catchup | D55/FA04D4B8 | D55/F9E74158 | D55/F9E44CD8 | D55/F9E74030 | 00:00:03.603104 | 00:00:03.603104 | 00:00:03.603104 |             0 | async
(1 row)

Ich habe ein paar Mal versucht, den Slave neu zu starten, wobei verschiedene Kombinationen von Abonnements aktiviert und deaktiviert waren - nichts hilft, der Replikationsstatus bleibt auf catchup. Ich kann es sehen sent_lsn und write_lsn Werte ändern sich, so dass etwas gesendet wird ...

Dies ist meine Slave-Konfiguration:

wal_level=logical
max_replication_slots=2
max_logical_replication_workers=4

wal_receiver_timeout=1200000

Und das ist mein Meister:

wal_level=logical

max_replication_slots=10
max_wal_senders=10

# maximum wait time in milliseconds that the walsender process on the active master
# waits for a status message from the walreceiver process on the standby master.
wal_sender_timeout=1200000

Ich habe keine Ahnung, was ich tun soll (noch schlimmer, zu diesem Zeitpunkt habe ich keine Ahnung, was ich als nächstes überprüfen soll ...)

Können Sie mir helfen zu verstehen, was ich tun soll, damit mein Sklave aufholt, damit er wieder in den Zustand streaming zurückkehrt?


Bearbeiten (12 Stunden später)

Als ich am Morgen eincheckte, befand sich die Synchronisation noch im Zustand catchup

master=# select * from pg_stat_replication;
  pid  | usesysid | usename | application_name  |  client_addr  | client_hostname | client_port |         backend_start         | backend_xmin |  state  |   sent_lsn   |  write_lsn   |  flush_lsn   |  replay_lsn  | write_lag | flush_lag | replay_lag | sync_priority | sync_state
-------+----------+---------+-------------------+---------------+-----------------+-------------+-------------------------------+--------------+---------+--------------+--------------+--------------+--------------+-----------+-----------+------------+---------------+------------
 12965 |    16680 | my_user    | logical_from_master | 10.10.10.10 |                 |       46630 | 2019-09-17 06:40:18.801262+02 |              | catchup | D56/248E13A0 | D56/247E3908 | D56/247E3908 | D56/247E3908 |           |           |            |             0 | async
(1 row)

Aber als ich 60 Sekunden später noch einmal nachschaute, war die Ergebnismenge leer ...

Protokolle zeigen jetzt mehrere Inkarnationen desselben Fehlers:

2019-09-16 22:43:33.841 CEST [20260] ERROR:  could not receive data from WAL stream: server closed the connection unexpectedly
                This probably means the server terminated abnormally
                before or while processing the request.
2019-09-16 22:43:33.959 CEST [26087] LOG:  background worker "logical replication worker" (PID 20260) exited with exit code 1
2019-09-16 22:43:34.112 CEST [3510] LOG:  logical replication apply worker for subscription "logical_from_master" has started
(...)

Damit die Replikation auf dem Master als catchup angezeigt wird, muss ich jetzt zuerst den Slave neu starten ...


Bearbeiten (als Antwort auf den Kommentar von @LaurenzAlbe)

Ich habe das Replikat gestern Morgen neu erstellt und festgestellt, dass die Replikation ab 19:53 Uhr erneut fehlschlägt. Protokolle für Master und Replikat unten:

2019-09-18 19:15:13.767 CEST [8611] LOG:  logical replication table synchronization worker for subscription "logical_replica_from_master", table "lasttable" has finished
2019-09-18 19:54:14.875 CEST [11469] ERROR:  could not send data to WAL stream: server closed the connection unexpectedly
                This probably means the server terminated abnormally
                before or while processing the request.
2019-09-18 19:54:14.969 CEST [10330] LOG:  logical replication apply worker for subscription "logical_replica_from_master" has started
2019-09-18 19:54:15.031 CEST [11217] LOG:  background worker "logical replication worker" (PID 11469) exited with exit code 1

Entsprechendes Protokoll vom Master:

2019-09-18 19:50:36.386 CEST,,,111051,,5d826e6a.1b1cb,1,,2019-09-18 19:50:34 CEST,138/28493452,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 8949 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 43798 remain, 43783 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 17925 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.04 s, system: 0.05 s, elapsed: 1.88 s",,,,,,,,,""
2019-09-18 19:51:36.402 CEST,,,1714,,5d826ea6.6b2,1,,2019-09-18 19:51:34 CEST,316/16529009,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 8949 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 43798 remain, 43795 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 17925 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.01 s, system: 0.07 s, elapsed: 1.87 s",,,,,,,,,""
2019-09-18 19:52:36.421 CEST,,,2649,,5d826ee2.a59,1,,2019-09-18 19:52:34 CEST,153/19807659,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 8949 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 43798 remain, 43795 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 17924 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.03 s, system: 0.05 s, elapsed: 1.87 s",,,,,,,,,""
2019-09-18 19:53:36.424 CEST,,,2945,,5d826f1e.b81,1,,2019-09-18 19:53:34 CEST,317/15405278,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 8949 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 43798 remain, 43795 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 17924 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.03 s, system: 0.05 s, elapsed: 1.88 s",,,,,,,,,""
2019-09-18 19:54:15.123 CEST,"core","my_db",3073,"10.194.132.16:50372",5d826f47.c01,1,"idle",2019-09-18 19:54:15 CEST,317/0,0,LOG,00000,"starting logical decoding for slot ""logical_replica_from_master""","Streaming transactions committing after D5B/7A4D40, reading WAL from D5B/7A4D40.",,,,,,,,"logical_replica_from_master"
2019-09-18 19:54:15.124 CEST,"core","my_db",3073,"10.194.132.16:50372",5d826f47.c01,2,"idle",2019-09-18 19:54:15 CEST,317/0,0,LOG,00000,"logical decoding found consistent point at D5B/7A4D40","There are no running transactions.",,,,,,,,"logical_replica_from_master"
2019-09-18 19:54:36.442 CEST,,,3152,,5d826f5a.c50,1,,2019-09-18 19:54:34 CEST,362/5175766,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 8949 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 43798 remain, 43795 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 17924 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.02 s, system: 0.06 s, elapsed: 1.88 s",,,,,,,,,""

Dann gegen Mitternacht auf Sklave:

2019-09-19 00:16:48.167 CEST [10330] ERROR:  could not send data to WAL stream: server closed the connection unexpectedly
                This probably means the server terminated abnormally
                before or while processing the request.
2019-09-19 00:16:48.276 CEST [19530] LOG:  logical replication apply worker for subscription "logical_replica_from_master" has started
2019-09-19 00:16:48.324 CEST [11217] LOG:  background worker "logical replication worker" (PID 10330) exited with exit code 1

und entsprechender Log-On-Master:

2019-09-19 00:15:41.104 CEST,,,74257,,5d82ac89.12211,1,,2019-09-19 00:15:37 CEST,78/34511468,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 13603 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 64816 remain, 64813 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 27234 hits, 0 misses, 1 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.003 MB/s
system usage: CPU: user: 0.03 s, system: 0.08 s, elapsed: 2.85 s",,,,,,,,,""
2019-09-19 00:16:13.688 CEST,,,35656,,5d382555.8b48,11190,,2019-07-24 11:31:01 CEST,,0,LOG,00000,"checkpoint complete: wrote 1748 buffers (0.0%); 0 WAL file(s) added, 0 removed, 1 recycled; write=174.932 s, sync=0.000 s, total=174.936 s; sync files=75, longest=0.000 s, average=0.000 s; distance=11366 kB, estimate=13499 kB",,,,,,,,,""
2019-09-19 00:16:41.121 CEST,,,75038,,5d82acc5.1251e,1,,2019-09-19 00:16:37 CEST,185/19338019,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 13603 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 64816 remain, 64813 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 27233 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.04 s, system: 0.07 s, elapsed: 2.85 s",,,,,,,,,""
2019-09-19 00:16:48.335 CEST,"core","my_db",75294,"10.194.132.16:50480",5d82acd0.1261e,1,"idle",2019-09-19 00:16:48 CEST,315/0,0,LOG,00000,"starting logical decoding for slot ""logical_replica_from_master""","Streaming transactions committing after D5B/1D1F1C0, reading WAL from D5B/1CA07F8.",,,,,,,,"logical_replica_from_master"
2019-09-19 00:16:48.335 CEST,"core","my_db",75294,"10.194.132.16:50480",5d82acd0.1261e,2,"idle",2019-09-19 00:16:48 CEST,315/0,0,LOG,00000,"logical decoding found consistent point at D5B/1CA07F8","There are no running transactions.",,,,,,,,"logical_replica_from_master"
2019-09-19 00:17:41.141 CEST,,,75484,,5d82ad01.126dc,1,,2019-09-19 00:17:37 CEST,330/18178915,0,LOG,00000,"automatic vacuum of table ""my_db.pg_toast.pg_toast_22314"": index scans: 0
pages: 0 removed, 13613 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 64866 remain, 64863 are dead but not yet removable, oldest xmin: 3141915780
buffer usage: 27254 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.04 s, system: 0.07 s, elapsed: 2.85 s",,,,,,,,,""

Bearbeiten

Die folgende Fehlermeldung (auf dem Master) erscheint genau nach wal_sender_timeout time (ab dem Zeitpunkt, an dem die Replikation auf dem Slave aktiviert ist):

2019-09-19 13:33:58.015 CEST,"core","nzdb",112432,"10.194.132.16:50886",5d8362f5.1b730,5,"idle",2019-09-19 13:13:57 CEST,379/2076197,0,LOG,00000,"terminating walsender process due to replication timeout",,,,,"slot ""logical_replica_from_master"", output plugin ""pgoutput"", in the change callback, associated LSN D5B/6782CF0",,,"WalSndCheckTimeOut, walsender.c:2100","logical_replica_from_master"

Bearbeiten

Ich habe diesem Server mehr RAM] hinzugefügt, aber die Beobachtung ist immer noch dieselbe - nach wal_sender_timeout Arbeiter auf Slave protokolliert den oben erwähnten Fehler und auf Master bleibt mir folgendes in pg_stat_replication:

  pid  | usesysid | usename |              application_name              |  client_addr  | client_hostname | client_port |         backend_start         | backend_xmin |  state  | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state
-------+----------+---------+--------------------------------------------+---------------+-----------------+-------------+-------------------------------+--------------+---------+----------+-----------+-----------+------------+-----------+-----------+------------+---------------+------------
 87820 |    16680 | core    | logical_replica_from_master_27004_sync_21691 | 10.10.10.10 |                 |       55548 | 2019-09-19 15:31:40.032662+02 |   3142872730 | startup |          |           |           |            |           |           |            |             0 | async
(1 row)

Dann nach einer sehr langen Zeit ist es wieder auf dem Laufenden, aber mit anderen sent_lsn

Wenn ich INSERT ausführe, um die Tabelle auf dem Master zu testen, werden auf dem Slave keine Änderungen angezeigt.

6
Greg0ry

Wie Sie bereits herausgefunden haben, ist Ihre Master-Datenbank zu beschäftigt, als dass ein einzelner Replikationsmitarbeiter alle Änderungen verarbeiten könnte.

Sie müssen Ihre Tabellen gruppieren. Stellen Sie jedoch sicher, dass Tabellen mit Fremdschlüsseln mit demselben Worker behandelt werden. Andernfalls kann es vorkommen, dass durch Fremdschlüsseleinschränkungen verhindert wird, dass Daten in eine Tabelle eingefügt werden, da die Tabelle fremd ist Die wichtigsten Punkte bei wurden noch nicht aktualisiert.

1
Rafel Bennassar

Ich habe unterschätzt, wie beschäftigt die Master-Datenbank war, und das liegt daran, dass ich im Juli beobachtet habe, dass die Replikation fehlerfrei funktioniert. Anscheinend ist Juli der Monat der Feiertage, sodass die Datenbank nur minimal weniger belastet wurde, damit sich das Problem nicht manifestiert.

Einer meiner Kollegen wies darauf hin, dass mehrere Prozesse gleichzeitig in diese Datenbank schreiben, sodass ein einzelner WAL-Absender möglicherweise einfach nicht mit dem Informationsvolumen fertig wird. Dies war ein sehr gültiger Rat und danach kratzte ich mir am Kopf und versuchte zu überlegen, warum ich überhaupt nicht darüber nachgedacht habe. @jjanes berührte Base auch im ersten Kommentar dazu. Ich habe zu viel Vertrauen in die Anpassung von Postgres auch mit Standardoptionen an so unterschiedliche Workloads gesetzt.

Was ich jetzt mache, ist, die Verwendung von CREATE PUBLICATION .. FOR ALL TABLES Zu vermeiden und stattdessen mehrere Veröffentlichungen mit mehreren entsprechenden Abonnements auf der Replikatseite zu erstellen.

0
Greg0ry