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

Sicherstellen, dass das Replikat ausreichend bereitgestellt wird

Bei einer Replikatinstanz, die kleiner als die primäre Instanz ist (z. B. mit weniger vCPUs und Arbeitsspeicher), kann es zu einer Replikationsverzögerung 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ß ist wie die primäre Instanz, damit genügend Ressourcen für die 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 von Replikat- und primärer Instanz aufrufen und auf Unterschiede vergleichen.

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 bei der Replikation versucht wird, Ä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 aufgrund von lang andauernden Transaktionen zu beheben, empfehlen wir Folgendes:

  • Standby-Verzögerungs-Flags anpassen: Mit den Flags max_standby_archive_delay und max_standby_streaming_delay wird gesteuert, 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.
  • Aktivieren Sie das Flag hot_standby_feedback. Wenn Sie das Flag hot_standby_feedback im Replikat auf on setzen, kann dies helfen, da dadurch die VACUUM-Vorgänge auf der primären Instanz verzögert werden. Dies kann jedoch zu einer Tabellenüberlastung auf dem primären Knoten führen.

Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Hohe Netzwerklatenz

Eine hohe Netzwerkverzögerung weist darauf hin, dass WAL-Datensätze nicht schnell genug von der primären Instanz gesendet oder vom Replikat empfangen werden. Das kann folgende Ursachen haben:

  • Regionenübergreifende Replikation: Die Replikation zwischen verschiedenen Regionen kann zu einer höheren Netzwerklatenz führen.
  • Hohe primäre CPU-Auslastung. Wenn die CPU des primären Servers ü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.
  • Hohe CPU-Auslastung des Replikats. Wenn die CPU des Replikats über 90 % liegt, erhält der WAL-Empfängerprozess möglicherweise nicht genügend CPU-Zeit. Reduzieren Sie die Last auf das Replikat oder erhöhen Sie die CPU.
  • Probleme mit der Netzwerkbandbreite oder Engpässe bei der Festplatten-E/A Eine näher gelegene Region oder eine Festplattenkonfiguration mit höherem Durchsatz kann helfen. Ändern Sie den Wert des Flags wal_compression in der primären Instanz, um regionsü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 Höchstlimit von 25 Sekunden, auch wenn die tatsächliche Verzögerung höher ist.

Der Messwert network_lag ähnelt dem Messwert cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, mit dem die sent_location-Verzögerung in Byte gemessen wird, wie durch das Label replica_lag_type angegeben.

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 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.
  • 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 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)

Wie geht es weiter?