Verzögerung der Replikation

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 aufgeführten Szenarien können mit dem Messwert network_lag überwacht werden. Das dritte Szenario wird mit dem Messwert replica_lag beobachtet. Ein hoher Wert für replica_lag bedeutet, dass das Replikat Replikationsänderungen nicht schnell genug anwenden kann. Die Gesamtverzögerung kann mit dem Messwert replica_byte_lag beobachtet werden, der Labels hat, die weitere Details angeben. Weitere Informationen zu diesen Messwerten finden Sie unter Replikationsverzögerung überwachen.

Replikat ausreichend bereitstellen

Bei einer Replikatinstanz, die kleiner als die primäre Instanz ist (z. B. mit weniger vCPUs und Arbeitsspeicher), kann es zu Replikationsverzögerungen kommen. Ein kleineres Replikat hat möglicherweise auch andere Standardkonfigurationsflags als eine größere primäre Instanz. Wir empfehlen, dass die Replikatinstanz mindestens so groß wie die primäre Instanz ist, damit genügend Ressourcen zur Verarbeitung der Replikationslast vorhanden sind.

Eine hohe CPU-Auslastung auf dem Replikat kann ebenfalls zu Replikationsverzögerungen führen. Wenn die CPU-Auslastung des Replikats hoch ist (z. B. über 90%), sollten Sie die CPU-Kapazität des Replikats erhöhen.

Mit dem Befehl SHOW ALL können Sie die Konfiguration des Replikats und der primären Instanz aufrufen und die Konfigurationen vergleichen, um Unterschiede zu erkennen.

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. Dies kann passieren, wenn die Replikation versucht, Änderungen (z. B. aus einem VACUUM-Vorgang) auf Zeilen anzuwenden, die von einer Abfrage auf dem Replikat gelesen werden.

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.

Um Replikationsverzögerungen oder ‑blockierungen zu beheben, die durch Transaktionen mit langer Ausführungszeit verursacht werden, empfehlen wir Folgendes:

  • Standby-Verzögerungsflags anpassen Mit den max_standby_archive_delay und max_standby_streaming_delay Flags wird festgelegt, wie lange ein Replikat wartet, bevor Standby-Abfragen abgebrochen werden, die mit der Replikation in Konflikt stehen. Angemessene Werte liegen oft zwischen 30 und 60 Sekunden. In der Ansicht pg_stat_database_conflicts finden Sie Informationen zu Abfragekonflikten.
  • Das Flag hot_standby_feedback aktivieren. Wenn Sie das hot_standby_feedback Flag auf on im Replikat setzen, können Sie die Vacuum-Vorgänge auf der primären Instanz verzögern. Dies kann jedoch zu einer Tabellenüberlastung auf der primären Instanz führen. Es ist also ein Kompromiss.

Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Hohe Netzwerkverzögerung

Eine hohe Netzwerkverzögerung bedeutet, dass WAL-Einträge nicht schnell genug von der primären Instanz gesendet oder vom Replikat empfangen werden. Dies kann folgende Ursachen haben:

  • Regionenübergreifende Replikation Bei der Replikation zwischen verschiedenen Regionen kann es zu einer höheren Netzwerklatenz kommen.
  • Hohe CPU-Auslastung der primären Instanz Wenn die CPU-Auslastung der primären Instanz über 90 % liegt, erhält der WAL-Senderprozess möglicherweise nicht genügend CPU-Zeit. Reduzieren Sie die Last auf der primären Instanz oder erhöhen Sie die CPU-Kapazität.
  • Hohe CPU-Auslastung des Replikats Wenn die CPU-Auslastung des Replikats über 90 % liegt, erhält der WAL-Empfängerprozess möglicherweise nicht genügend CPU-Zeit. Reduzieren Sie die Last auf dem Replikat oder erhöhen Sie die CPU-Kapazität.
  • Probleme mit der Netzwerkbandbreite oder Engpässe bei der Laufwerk-E/A Eine näher gelegene Region oder eine Laufwerkskonfiguration mit höherem Durchsatz kann helfen. Ändern Sie den Wert des wal_compression Flags in der primären Instanz , um den regionenübergreifenden Traffic zu reduzieren.
Sie können die Netzwerkverzögerung mit dem Messwert cloudsql.googleapis.com/database/replication/network_lag überwachen. Dieser Messwert hat ein Limit von 25 Sekunden, auch wenn die tatsächliche Verzögerung höher ist.

Dieser Messwert network_lag ähnelt dem Messwert cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, der die Verzögerung von sent_location in Byte misst, die durch das Label replica_lag_type angegeben wird.

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.

Ü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.

MesswertBeschreibung
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 zeigt nicht die Gesamtverzögerung an.
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.
  • float_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 der network_lag null oder vernachlässigbar, aber der replica_lag hoch ist, bedeutet dies, dass der WAL-Empfänger die Replikationsänderungen nicht schnell genug anwenden kann.

Da network_lag auf die nächste Sekunde aufgerundet wird, kann ein gemeldeter Wert von 1 Sekunde eine zugrunde liegende Verzögerung von einer oder zwei Millisekunden bis zu einer vollen Sekunde darstellen.

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)

Wie geht es weiter?