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.
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.
Ü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 |
---|---|
Replikationsverzögerung ( cloudsql.googleapis.com ) |
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 |
Verzögerung in Byte ( cloudsql.googleapis.com ) |
Die Anzahl der Byte, um die der Zustand des Replikats hinter dem Zustand der primären Datenbank zurückliegt.
|
Netzwerkverzögerung ( cloudsql.googleapis.com ) |
Die Zeit in Sekunden, die der Commit in der primären Datenbank benötigt, um den WAL-Empfänger im Replikat zu erreichen. Wenn |
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)