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 für die Replikation immer aktive SQL Server-Verfügbarkeitsgruppen. Änderungen werden in das Transaktionslog der primären Instanz geschrieben. Die primäre Instanz leitet Transaktionen an alle sekundären Replikatinstanzen weiter, auf die die Änderungen angewendet werden. Der verwendete Verfügbarkeitsmodus ist der asynchrone Commit-Modus.

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 Gründe können mit network_lag metric überwacht werden. Der dritte Grund wird über den Messwert seconds_behind_master beobachtet. Ein hoher seconds_behind_master-Messwert bedeutet, dass das Replikat Replikationsänderungen nicht schnell genug anwenden kann. 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.

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.

Darüber hinaus können DDL-Anweisungen wie CREATE INDEX, ALTER INDEX und INDEX MAINTENANCE aufgrund der großen Anzahl von Transaktionslogeinträgen, die diese Anweisungen generieren können, Replikationsverzögerungen verursachen.

Ü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/database/replication/seconds_behind_master)	Die Anzahl der Sekunden, die der Zustand des Replikats hinter dem Zustand der primären Instanz zurückliegt. Dies ist die Differenz zwischen dem Zeitstempel des letzten redone-Logeintrags auf der sekundären Instanz und dem Zeitstempel des letzten gesendeten Logdatensatzes auf der primären Instanz.
Netzwerkverzögerung (cloudsql.googleapis.com/database/replication/network_lag)	Die Differenz zwischen dem Zeitstempel des letzten empfangenen Logeintrags auf dem Replikat und dem letzten gesendeten Logeintrag auf der primären Instanz.

Replikation prüfen

Prüfen Sie, ob die Replikation funktioniert, indem Sie den Wert des Messwerts cloudsql.googleapis.com/database/replication/state auf der primären Instanz prüfen. Wenn der Status Running lautet, ist die Replikation fehlerfrei.