wake-up-neo.net

Wie prüfe ich die Replikationsverzögerung in PostgreSQL?

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

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

Die Zeit ist jedoch in beiden Tabellen gleich .. Wie kann ich die Verzögerungszeit messen?

19
Alf162

Sie können die Verzögerung in Bytes von der Masterseite ziemlich einfach erhalten, indem Sie pg_xlog_location_diff verwenden, um den pg_current_xlog_insert_location des Masters mit dem replay_location für den pg_stat_replication-Eintrag dieses Backends zu vergleichen.

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

Zusätzlich wird Ihnen die Verzögerung in Sekunden nicht angezeigt. In aktuellen (mindestens Version 9.4) PostgreSQL-Versionen gibt es keinen Zeitstempel, der mit einem Commit- oder WAL-Datensatz verknüpft ist. Es gibt also keine Möglichkeit festzustellen, wie lange eine bestimmte LSN (xlog-Position) war.

Die einzige Möglichkeit, die Replik-Verzögerung in Sekunden für eine aktuelle PostgreSQL-Version abzurufen, 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 neuesten Eintrags in dieser Tabelle vergleichen, der auf dem Replikat sichtbar ist, um zu sehen, wie weit das Replikat hinterher liegt. Dadurch wird zusätzlicher WAL-Verkehr erzeugt, der dann in Ihrer archivierten WAL für PITR (PgBarman oder was auch immer) aufbewahrt werden muss. Daher sollten Sie die erhöhte Datennutzung mit der gewünschten Granularität der Verzögerungserkennung abgleichen.

PostgreSQL 9.5 kann Commit-Zeitstempel hinzufügen, mit denen Sie hoffentlich herausfinden können, wie lange ein bestimmtes Commit bereits passiert ist und wie weit sich eine Replik also in Sekundenbruchteilen an der Wanduhr befindet.

16
Craig Ringer

Alf162 erwähnte eine gute Lösung in den Kommentaren zu Craig Ringers Antwort; also füge ich dies zur Klarstellung hinzu.

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

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

Wenn der Master keine neuen Mutationen empfängt, gibt es keine WAL-Datensätze zum Streamen, und die auf diese Weise berechnete Verzögerung nimmt zu, ohne tatsächlich ein Signal für Verzögerungen bei der Replikation zu sein. Wenn sich der Master in mehr oder weniger kontinuierlicher Mutation befindet, wird er kontinuierlich WALs strömen, und die obige Abfrage ist eine feine Annäherung an die Zeitverzögerung für Änderungen am Master, die beim Slave wirksam werden. Die Genauigkeit wird offensichtlich davon beeinflusst, wie genau die Systemuhren der beiden Hosts synchronisiert sind.

16
dbenhur

Wenn in Ihrer Datenbank häufige Schreibvorgänge ausgeführt werden, ist die folgende Abfrage eine Annäherung, um die Slave-Verzögerung zu ermitteln

select now() - pg_last_xact_replay_timestamp() AS replication_delay;

Nachfolgend finden Sie eine genauere Abfrage zum Berechnen der Replikationsverzögerung für Datenbanken mit sehr wenigen Schreibvorgängen. Wenn der Master keinen Schreibvorgang an den Slave gesendet hat, kann pg_last_xact_replay_timestamp () konstant sein und 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;
6
Ramanan

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 ist nur wichtig, wenn "Empfang" nicht gleich "Wiederholung" ist. Führen Sie die Abfrage auf dem Slave aus

5
shurikk

stand 10 Release:

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

write_lag interval Zeit zwischen dem lokalen Löschen der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben hat (aber noch nicht) gespült oder angewendet). Dies kann verwendet werden, um die Verzögerung zu messen, die beim Festschreiben der Synchronous-Commit-Ebene für Remote-Schreibvorgänge aufgetreten ist, wenn dieser Server als Synchronous-Standby-Server konfiguriert wurde.

flush_lag interval Zeit zwischen dem lokalen Leeren der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben und geleert hat (aber noch nicht angewendet). Dies kann verwendet werden, um die Verzögerung zu messen, die synchronous_commit level remote_flush beim Festschreiben auftrat, wenn dieser Server als synchrones Standby konfiguriert wurde.

replay_lag interval Die Zeit zwischen dem lokalen Leeren der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben, geleert und angewendet hat . Dies kann verwendet werden, um die Verzögerung zu messen, die synchronous_commit level remote_apply beim Festschreiben auftrat, wenn dieser Server als synchrones Standby konfiguriert wurde.

(Formatierung von mir)

Leider scheinen neue Spalten nur für die synchrone Replikation geeignet zu sein (andernfalls würde der Master die exakte Verzögerung nicht kennen), so dass der asynchrone Replikationsverzögerungs-Chack anscheinend now()-pg_last_xact_replay_timestamp()...

3
Vao Tsun

auf Master können Sie select * from pg_stat_replication; tun
das gibt Ihnen:

|  sent_lsn   |  write_lsn  |  flush_lsn  | replay_lsn  

-+-------------+-------------+-------------+-------------

 | 8D/2DA48000 | 8D/2DA48000 | 8D/2DA48000 | 89/56A0D500 

diese können Ihnen sagen, wo sich Ihre Offsets befinden .

0
linehrr