Monitoring logischer Replikation mit pg_stat_subscription: Zeitstempel interpretieren

From: <Simon(dot)Schneider(at)STADT-KOELN(dot)DE>
To: <pgsql-de-allgemein(at)lists(dot)postgresql(dot)org>
Cc: <kai(dot)koerwer(at)stadt-koeln(dot)de>
Subject: Monitoring logischer Replikation mit pg_stat_subscription: Zeitstempel interpretieren
Date: 2020-09-07 13:15:48
Message-ID: d2187a4036884c75aabaa64b69288b53@STADT-KOELN.DE
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Guten Tag,

ich möchte gerne überwachen, ob eine Replikation mit publication/subscription aktuell ist. Das Handbuch verweist mich auf den View pg_stat_subscription, bei dessen Interpretation meine Kollegen und ich unsicher sind. Falls ich hier an der falschen Stelle frage, sagt mir bitte Bescheid.

Situation:
- Main-Server mit pg 12.3, veröffentlicht eine publication
- Standby-Server mit pg 12.3, abonniert diese als subscription

Im View pg_stat_subscription [1] des Standby-Servers gibt es drei Spalten mit Zeitstempeln, die nach meiner Einschätzung folgendes bedeuten:
- latest_end_time: Zeitstempel im aktuellsten Eintrag im WAL des Main-Server
- last_msg_send_time: Wann der Main-Server zuletzt eine Nachricht abgeschickt hat
- last_msg_received_time: Wann der Standby-Server zuletzt eine Nachricht erhalten hat

Für Verwirrung sorgt die Beschreibung im Handbuch unter Tabelle 27.2: "latest_end_time - Time of last write-ahead log location reported to origin WAL sender" [1]. WAL sender ist ein Prozess auf dem Main-Server. Aber wer reportet dahin? Mein Kollege meint, damit sei ein Feedback vom Standby-Server gemeint, also dass der Sender weiß, wie weit die Replikation fortgeschritten ist. Ich denke, dass damit der Rest von pg gemeint ist, der ja ein WAL produziert, unabhängig ob das irgendwohin gesendet wird oder nicht.

Wessen Einschätzung trifft zu?
Kommen latest_end_time und last_msg_send_time von derselben Uhr?
Gibt es noch andere Dokumentation zum publication/subscription-mechanismus, die wir bisher übersehen haben? Relevant erscheinen uns die Abschnitte 30.6 [2] und 26.2.5.2 [3] im Handbuch. Ich würde ungern Protokoll und Ablauf aus dem Sourcecode extrahieren.

Vielen lieben Dank für die Zeit und Sorry für den Footer, den kann ich nicht abschalten.

[1] https://www.postgresql.org/docs/12/monitoring-stats.html#PG-STAT-SUBSCRIPTION
[2] https://www.postgresql.org/docs/12/logical-replication-monitoring.html
[3] https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-MONITORING

Im Auftrag
Simon Schneider

Stadt Köln - Die Oberbürgermeisterin
Berufsfeuerwehr, Amt für Feuerschutz, Rettungsdienst und Bevölkerungsschutz
Boltensternstr. 10
50735 Köln

Telefon: 0221/9748-9092
Telefax: 0221/9748-9004
E-Mail: simon(dot)schneider(at)stadt-koeln(dot)de
Internet: https://www.stadt-koeln.de

________________________________
________________________________

Monatlich aktuelle Informationen Ihrer Stadtverwaltung in unserem Newsletter! Newsletter Anmeldung<https://www.stadt-koeln.de/service/onlinedienste/newsletter-anmeldung?para=allgemein>

________________________________
________________________________

[https://styleguide.bundesregierung.de/resource/blob/72496/1760346/6d7f611945ca42908c50804510c5335b/breg-vorschaubild-01-unterstuetzt-842x595px-jpg-srgb-v01-data.png]<https://www.bundesregierung.de/breg-de/themen/corona-warn-app>
[https://www.stadt-koeln.de/images/footer_wahlhelferaufruf2020.jpg]<http://www.wahlhelfer.koeln/>

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Michael Mühlbeyer 2020-09-08 11:39:29 Re: Monitoring logischer Replikation mit pg_stat_subscription: Zeitstempel interpretieren
Previous Message Thomas Kellerer 2020-07-28 11:41:53 Re: Daten wöchentlich aggregieren aber einen Tag (z.B. Montag, aber egal) als Spalte liefern