Verzögerung der Replikation

MySQL | PostgreSQL | SQL Server

Auf dieser Seite wird beschrieben, wie Sie die Replikationsverzögerung bei Cloud SQL-Lesereplikaten beheben können.

Übersicht

Cloud SQL-Lesereplikate verwenden die PostgreSQL-Streamingreplikation. Änderungen werden in das Write-Ahead-Log (WAL) in der primären Instanz geschrieben. Der WAL-Sender sendet das WAL an den WAL-Empfänger im Replikat, wo die Änderungen angewendet werden.

Die Replikationsverzögerung kann in verschiedenen Szenarien auftreten:

Die primäre Instanz kann die Änderungen nicht schnell genug an das Replikat senden.
Das Replikat kann die Änderungen nicht schnell genug empfangen.
Das Replikat kann die Änderungen nicht schnell genug anwenden.

Die ersten beiden oben genannten Gründe können mit dem Messwert network_lag überwacht werden. Der dritte Grund wird über den Messwert replica_lag beobachtet. Ein hoher replica_lag bedeutet, dass das Replikat Replikationsänderungen nicht schnell genug anwenden kann. Die Gesamtverzögerung kann über den Messwert replica_byte_lag beobachtet werden, der Labels hat, die weitere Details angeben. Diese Messwerte werden unten im Abschnitt Replikationsverzögerung überwachen beschrieben.

Abfragen und Schema optimieren

In diesem Abschnitt werden einige gängige Abfrage- und Schemaoptimierungen vorgeschlagen, mit denen Sie die Replikationsleistung verbessern können.

Abfragen mit langer Ausführungszeit im Lesereplikat

Abfragen mit langer Ausführungszeit im Replikat können die Replikation für Cloud SQL blockieren. Es kann sinnvoll sein, separate Replikate für die Online-Transaktionsverarbeitung (OLTP) und die analytische Onlineverarbeitung (OLAP) zu verwenden und nur Abfragen mit langer Ausführungszeit an das OLAP-Replikat zu senden.

Sie können die Flags max_standby_archive_delay und max_standby_streaming_delay für Ihr Replikat anpassen.

Wenn Sie den Verdacht haben, dass VACUUM das Problem verursacht, und die Abfrage nicht abgebrochen werden kann, können Sie das Flag hot_standby_feedback im Replikat festlegen.

Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu Hot Standby.

Exklusive Sperren aufgrund von DDL

DDL-Befehle (Data Definition Language) wie ALTER TABLE und CREATE INDEX können aufgrund von exklusiven Sperren zu Replikationsverzögerungen im Replikat führen. Um Sperrenkonflikte zu vermeiden, sollten Sie die DDL-Ausführung zu Zeiten planen, in denen die Abfragelast auf den Replikaten geringer ist.

Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu Hot Standby.

Überlastetes Replikat

Wenn ein Lesereplikat zu viele Abfragen erhält, kann die Replikation blockiert werden. Ziehen Sie in Betracht, die Lesevorgänge auf mehrere Replikate aufzuteilen, um die Last auf den einzelnen Replikaten zu reduzieren.

Sie können Abfragespitzen vermeiden, indem Sie Replikatleseabfragen in Ihrer Anwendungslogik oder in einer Proxy-Ebene, falls Sie eine verwenden, drosseln.

Wenn es auf der primären Instanz zu Spitzen bei der Aktivität kommt, können Sie Updates verteilen.

Monolithische primäre Datenbank

Ziehen Sie eine vertikale Fragmentierung der primären Datenbank in Betracht, um zu verhindern, dass eine oder mehrere verzögerte Tabellen alle anderen Tabellen zurückhalten.

Replikationsverzögerung überwachen

Mit den Messwerten replica_lag und network_lag können Sie die Replikationsverzögerung überwachen und ermitteln, ob die Ursache der Verzögerung in der primären Datenbank, im Netzwerk oder im Replikat liegt.

Messwert Beschreibung

Messwert	Beschreibung
Replikationsverzögerung (`cloudsql.googleapis.com/database/replication/replica_lag`)	Die Anzahl der Sekunden, die der Zustand des Replikats hinter dem Zustand der primären Instanz zurückliegt. Dies ist die Differenz zwischen der aktuellen Zeit und dem ursprünglichen Zeitstempel, bei dem die primäre Datenbank die Transaktion übergeben hat, die derzeit auf das Replikat angewendet wird. Insbesondere können Schreibvorgänge als verzögert gewertet werden, selbst wenn sie vom Replikat empfangen wurden, wenn das Replikat den Schreibvorgang noch nicht auf die Datenbank angewendet hat. Dieser Messwert wird mit `now() - pg_last_xact_replay_timestamp()` im Replikat berechnet. Dies ist eine Näherung. Wenn die Replikation unterbrochen wird, weiß das Replikat nicht, wie weit die primäre Datenbank voraus ist, und dieser Messwert würde nicht die Gesamtverzögerung anzeigen.
Verzögerung in Byte (`cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag`)	Die Anzahl der Byte, um die der Zustand des Replikats hinter dem Zustand der primären Datenbank zurückliegt. `replica_byte_lag` exportiert vier Zeitachsen und das Label `replica_lag_type` kann eine der folgenden Informationen angeben: sent_location: Gibt an, wie viele Byte des WAL generiert, aber noch nicht an das Replikat gesendet wurden. write_location: Schreibverzögerung minus der Sendeverzögerung gibt die WAL-Byte im Netzwerk an, die gesendet, aber noch nicht in das Replikat geschrieben wurden. flush_location: Löschverzögerung minus Schreibverzögerung gibt die WAL-Byte an, die im Replikat geschrieben, aber noch nicht im Replikat gelöscht wurden. replay_location:: Gibt die Gesamtverzögerung in Byte an. Wiedergabeverzögerung minus Löschverzögerung gibt den Rückstand bei der Wiedergabe an.
Netzwerkverzögerung (`cloudsql.googleapis.com/database/replication/network_lag`)	Die Zeit in Sekunden, die der Commit in der primären Datenbank benötigt, um den WAL-Empfänger im Replikat zu erreichen. Wenn `network_lag` null oder vernachlässigbar, `replica_lag` aber hoch ist, bedeutet dies, dass der SQL-Thread die Replikationsänderungen nicht schnell genug anwenden kann.

Replikationsverzögerung
(cloudsql.googleapis.com/database/replication/replica_lag)

Die Anzahl der Sekunden, die der Zustand des Replikats hinter dem Zustand der primären Instanz zurückliegt. Dies ist die Differenz zwischen der aktuellen Zeit und dem ursprünglichen Zeitstempel, bei dem die primäre Datenbank die Transaktion übergeben hat, die derzeit auf das Replikat angewendet wird. Insbesondere können Schreibvorgänge als verzögert gewertet werden, selbst wenn sie vom Replikat empfangen wurden, wenn das Replikat den Schreibvorgang noch nicht auf die Datenbank angewendet hat.

Dieser Messwert wird mit now() - pg_last_xact_replay_timestamp() im Replikat berechnet. Dies ist eine Näherung. Wenn die Replikation unterbrochen wird, weiß das Replikat nicht, wie weit die primäre Datenbank voraus ist, und dieser Messwert würde nicht die Gesamtverzögerung anzeigen.

Verzögerung in Byte
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

Die Anzahl der Byte, um die der Zustand des Replikats hinter dem Zustand der primären Datenbank zurückliegt. replica_byte_lag exportiert vier Zeitachsen und das Label replica_lag_type kann eine der folgenden Informationen angeben:

sent_location: Gibt an, wie viele Byte des WAL generiert, aber noch nicht an das Replikat gesendet wurden.
write_location: Schreibverzögerung minus der Sendeverzögerung gibt die WAL-Byte im Netzwerk an, die gesendet, aber noch nicht in das Replikat geschrieben wurden.
flush_location: Löschverzögerung minus Schreibverzögerung gibt die WAL-Byte an, die im Replikat geschrieben, aber noch nicht im Replikat gelöscht wurden.
replay_location:: Gibt die Gesamtverzögerung in Byte an. Wiedergabeverzögerung minus Löschverzögerung gibt den Rückstand bei der Wiedergabe an.

Netzwerkverzögerung
(cloudsql.googleapis.com/database/replication/network_lag)

Die Zeit in Sekunden, die der Commit in der primären Datenbank benötigt, um den WAL-Empfänger im Replikat zu erreichen.

Wenn network_lag null oder vernachlässigbar, replica_lag aber hoch ist, bedeutet dies, dass der SQL-Thread die Replikationsänderungen nicht schnell genug anwenden kann.

Replikation prüfen

Führen Sie die folgende Anweisung für das Replikat aus, um zu prüfen, ob die Replikation funktioniert:

select status, last_msg_receipt_time from pg_stat_wal_receiver;

Wenn die Replikation erfolgt, sehen Sie den Status streaming und eine aktuelle "last_msg_reservation_time":

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status   |     last_msg_receipt_time
-----------+-------------------------------
 streaming | 2020-01-21 20:19:51.461535+00
(1 row)

Wenn die Replikation nicht erfolgt, wird ein leeres Ergebnis zurückgegeben:

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
 status | last_msg_receipt_time
--------+-----------------------
(0 rows)