Wie überprüfen Sie die Replikationsverzögerung in PostgreSQL?

Question

Ich möchte Zeit zwischen Einfügen von Daten in Master-Tabelle und Slave-Tabelle mit Streaming-Replikation in PostgreSQL 9.3 messen. Dazu erstelle ich Tabelle test_time mit 2 Feldern id (seriell), t (Text). Danach hat einen Trigger:

cur_time:=to_char(current_timestamp, 'HH12:MI:SS:MS:US'); update test_time set t=cur_time where id=new.id;

Aber die Zeit ist das gleiche in beiden Tabellen. Wie kann ich Verzögerungszeit

Answer 1

Sie messen die Verzögerung in Bytes von der Master-Seite ganz einfach pg_xlog_location_diff mit bekommen können die Master-pg_current_xlog_insert_location mit dem replay_location für dieses Backend des pg_stat_replication Eintrag zu vergleichen.

Dies funktioniert nur, wenn es auf dem Master ausgeführt wird. Sie können es nicht von der Replik aus tun, da die Replik keine Ahnung hat, wie weit der Master voraus ist.

Zusätzlich wird dies nicht die Verzögerung in Sekunden. In aktuellen PostgreSQL-Versionen (ab 9.4) gibt es keinen Zeitstempel, der mit einem Commit oder einem WAL-Record verbunden ist. Es gibt also keine Möglichkeit zu sagen, wie lange eine gegebene LSN (xlog-Position) her war.

Die einzige Möglichkeit, die Replikverzögerung in Sekunden bei einer aktuellen PostgreSQL-Version zu erhalten, besteht darin, dass ein externer Prozess regelmäßig eine update in eine dedizierte Zeitstempeltabelle schreibt. So können Sie current_timestamp auf dem Replikat mit dem Zeitstempel des letzten Eintrags in der Tabelle vergleichen, der auf dem Replikat sichtbar ist, um zu sehen, wie weit das Replikat zurückliegt. Dies erzeugt zusätzlichen WAL-Verkehr, der dann in Ihrer archivierten WAL für PITR (PgBarman oder was auch immer) aufbewahrt werden muss, so dass Sie die erhöhte Datennutzung mit der Granularität der Lag-Erkennung, die Sie benötigen, ausgleichen sollten.

PostgreSQL 9.5 kann Commit-Zeitstempel hinzufügen, mit denen Sie hoffentlich herausfinden können, wie lange ein bestimmtes Commit bereits stattgefunden hat und wie weit ein Replikat in Wanduhr-Sekunden zurückliegt.

Answer 2

Alf162 erwähnt eine gute Lösung in den Kommentaren zu Craig Ringer's Antwort; also füge ich das zur Klärung hinzu.

PostgreSQL hat eine Verwaltungsfunktion pg_last_xact_replay_timestamp(), die den Zeitstempel der letzten während der Wiederherstellung wiedergegebenen Transaktion zurückgibt. Dies ist der Zeitpunkt, zu dem der WAL-Datensatz für diese Transaktion auf der Primärdatenbank festgeschrieben oder abgebrochen wurde.

So gibt diese Abfrage select now()-pg_last_xact_replay_timestamp() as replication_lag auf einem Slave eine Dauer zurück, die die Zeitdifferenz zwischen der aktuellen Uhr und dem Zeitstempel des letzten WAL-Datensatzes aus dem Replikationsstrom darstellt.

Beachten Sie, dass, wenn der Master keine neuen Mutationen erhält, keine WAL-Datensätze zu streamen sind und die auf diese Weise berechnete Verzögerung zunimmt, ohne tatsächlich ein Signal für Verzögerungen bei der Replikation zu sein. Wenn der Master unter mehr oder weniger kontinuierlicher Mutation steht, wird er kontinuierlich WALs streamen und die obige Abfrage ist eine feine Annäherung an die Zeitverzögerung für Änderungen auf dem Master, die sich auf dem Slave materialisieren. Die Genauigkeit hängt natürlich davon ab, wie genau die Systemuhren der beiden Hosts synchronisiert sind.

Answer 3

etwas andere Version der richtigen Antwort:

postgres=# SELECT 
    pg_last_xlog_receive_location() receive, 
    pg_last_xlog_replay_location() replay, 
    (
    extract(epoch FROM now()) - 
    extract(epoch FROM pg_last_xact_replay_timestamp()) 
)::int lag; 

    receive | replay | lag 
------------+------------+------- 
1/AB861728 | 1/AB861728 | 2027 

die Verzögerung nur wichtig ist, wenn „empfangen“ nicht gleich „replay“.Führen Sie die Abfrage auf dem Slave

Answer 4

Wenn Ihre Datenbank häufig schreibt hat, dann die folgende Abfrage eine enge Annäherung ist die Slave-Verzögerung

select now() - pg_last_xact_replay_timestamp() AS replication_delay; 

Im Folgenden finden Sie eine genauere Abfrage für die Berechnung der Replikationsverzögerung für Datenbanken zu bekommen, sehr wenige schreiben. Wenn der Master keinen Schreibvorgang an den Slave sendet, kann pg_last_xact_replay_timestamp() konstant sein und kann daher die Slave-Verzögerung unter Verwendung der obigen Abfrage nicht genau bestimmen.

SELECT CASE WHEN pg_last_xlog_receive_location() = 
pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - 
pg_last_xact_replay_timestamp()) END AS log_delay; 

Answer 5

als 10 release:

https://www.postgresql.org/docs/10/static/monitoring-stats.html#pg-stat-replication-view

write_lagIntervall Zeit zwischen dem letzten WAL lokal Spülung und Benachrichtigung empfängt, dass dieser Standby-Server hat geschrieben (aber nicht noch gespült oder angewendet). Dies kann verwendet werden, um die Verzögerung, die synchronous_commit Ebene remote_write aufgetreten während der Festschreibung messen, wenn dieser Server als eine synchrone Standby konfiguriert wurde.

flush_lagIntervall Zeit zwischen dem letzten WAL lokal Spülung und Benachrichtigung empfängt, dass dieser Standby-Server geschrieben und spülte sie (aber noch nicht angewandt es) hat. Dies kann verwendet werden, um die Verzögerung, die synchronous_commit Ebene remote_flush aufgetreten ist während der Festschreibung, wenn dieser Server als eine synchrone Standby konfiguriert wurde.

replay_lagIntervall Zeit zwischen dem letzten WAL lokal Spülung und Benachrichtigung empfängt, dass dieser Standby-Server geschrieben, gespült und angewandt hat. Dies kann verwendet werden, um die Verzögerung zu messen, die synchronous_commit level remote_apply beim Commit anfallen, wenn dieser Server als synchroner Standby konfiguriert wurde.

(Formatierung von mir)

Alas neuen Spalten scheinen nur synchrone Replikation entsprechen now()-pg_last_xact_replay_timestamp() ... bleiben