Probleme bei der Replikation beheben

Die Architektur von AlloyDB trennt Computing und Speicher, sodass beide unabhängig voneinander skaliert werden können. Obwohl die primäre Instanz und die Lesepoolinstanzen denselben zugrunde liegenden Speicher verwenden, ist die Replikation dennoch ein wichtiger Prozess, um die Datenkonsistenz und -aktualität in den Lesereplikaten aufrechtzuerhalten. In einem AlloyDB-Cluster werden Schreibvorgänge auf der primären Instanz ausgeführt und dann im Write-Ahead-Log (WAL) aufgezeichnet. Diese Änderungen werden dann auf die Lesepoolknoten repliziert. Wenn Sie die beiden Hauptschritte dieses Replikationsprozesses verstehen, können Sie Probleme leichter beheben:

  • WAL-Flush: Das Write-Ahead-Log (WAL), das die Änderungen an der Datenbank enthält, wird von der primären Instanz an das Replikat gesendet. Das Replikat speichert das WAL dann sofort auf dem Laufwerk.
  • WAL-Anwendung (oder -Wiedergabe): Das persistente WAL wird auf dem Replikat wiedergegeben, d. h., die Änderungen werden auf die Caches des Replikats angewendet.

Verzögerungen bei einem dieser Schritte tragen zur sogenannten Replikationsverzögerung bei. Dieser Begriff kann jedoch mehrdeutig sein. Genauer gesagt können wir die Replikationsverzögerung in die folgenden beiden Komponenten unterteilen:

  • Leerungs- oder Netzwerkverzögerung: Dies ist die Verzögerung im WAL-Leerungsschritt. Das ist die Zeit, die benötigt wird, um das WAL von der primären Instanz zu senden und im Replikat zu speichern.
  • Wiedergabeverzögerung: Dies ist die Verzögerung im WAL-Anwendungsschritt. Dies ist die Zeit, die das Replikat benötigt, um die Änderungen aus dem WAL anzuwenden.

Ob Sie sich mehr Gedanken über die Flush-Verzögerung oder die Wiedergabeverzögerung machen müssen, hängt von Ihrem Anwendungsfall ab:

  • Wenn Sie sich Sorgen um Datenverlust machen, z. B. bei sekundären Clustern, müssen Sie die Flush-Verzögerung genau im Auge behalten. Wenn das WAL noch nicht auf dem Replikat gespeichert ist und die primäre Instanz abstürzt, gehen die Änderungen aus Sicht des Replikats verloren.
  • Wenn Sie sich Sorgen um die Aktualität der Daten auf Ihren Lesereplikaten machen, müssen Sie sowohl die Flush-Verzögerung als auch die Replay-Verzögerung im Auge behalten. Eine Verzögerung bei einem der beiden Schritte – entweder bei der Übertragung des WAL oder bei der Anwendung – führt zu veralteten Daten auf Ihren Lesereplikaten.

Replikationsverzögerung prüfen

Sie können die Replikationsverzögerung Ihrer Lesepoolinstanzen in der Google Cloud Console überwachen. Weitere Informationen finden Sie unter Instanzen überwachen. Sie können auch die Replikationsverzögerung des Lesepools überwachen und Benachrichtigungen zu einem angegebenen Schwellenwert erhalten, indem Sie Benachrichtigungsrichtlinien mit Messwertschwellen erstellen.

Häufige Ursachen für Replikationsverzögerungen

Im Folgenden finden Sie einige häufige Ursachen für Replikationsverzögerungen und wie Sie diese beheben können.

Ressourcenkonflikt

Die Replikation kann auch durch Konflikte um Systemressourcen wie CPU und Arbeitsspeicher verlangsamt werden.

  • CPU- und Arbeitsspeicherauslastung: Eine hohe Lesearbeitslast auf einer Lesepoolinstanz kann mit dem Replikationsprozess um CPU- und Arbeitsspeicherressourcen konkurrieren. Sie können die CPU- und Arbeitsspeichernutzung Ihrer Instanzen in der Google Cloud Console prüfen. Wenn Sie eine hohe Ressourcenauslastung feststellen, müssen Sie Ihre Lesepoolinstanzen möglicherweise vertikal oder horizontal skalieren.
  • Größe der Lesepoolknoten: Wenn Ihre primäre Instanz viel größer als Ihre Lesepoolknoten ist, werden Replikationslogs möglicherweise schneller generiert, als die Leseknoten sie verarbeiten können. In solchen Fällen wird empfohlen, größere Leseknoten zu verwenden, um den Replikaten mehr Ressourcen zur Verfügung zu stellen.

Replikationskonflikte

Leseabfragen können manchmal den Replikationsprozess blockieren, weil sie Ressourcen belegen, auf die der Replikationsprozess wartet. Wenn eine Leseabfrage eine Sperre für ein Datenbankobjekt enthält, das der Replay-Prozess aktualisieren muss, führt dies zu einem Sperrkonflikt. Wenn eine Abfrage einen Pin für einen Datenpuffer enthält, der für die Wiedergabe geändert werden muss, führt dies zu einem Puffer-Pin-Konflikt. In beiden Fällen wird die Wiedergabe blockiert, bis die Abfrage die Ressource freigibt.

Sie können diese Konflikte anhand von canceling statement due to conflict with recovery-Nachrichten in der Datei postgres.log im Log-Explorer identifizieren.

So können Sie Replikationskonflikte minimieren:

  • max_standby_streaming_delay reduzieren: Dieser Parameter bestimmt, wie lange der Wiedergabeprozess wartet, bevor Abfragen abgebrochen werden, die ihn blockieren. Der Standardwert beträgt 30 Sekunden. Wenn Sie diesen Wert verringern, kann die Replikationsverzögerung reduziert werden. Es kann jedoch auch dazu führen, dass mehr Leseabfragen abgebrochen werden. Sie können diesen Parameter anpassen, um die beste Balance für Ihre Anwendung zu finden.

  • Abfragen mit langer Ausführungszeit vermeiden: Abfragen mit langer Ausführungszeit in Lesepools können die Wahrscheinlichkeit von Replikationskonflikten erhöhen. Verschieben Sie Abfragen mit langer Ausführungszeit in einen anderen Lesepool, in dem eine geringe Replikationsverzögerung nicht so wichtig ist.

  • Prüfen Sie, ob alloydb.promote_cancel_to_terminate aktiv ist: Mit diesem Flag, das standardmäßig aktiviert ist, kann AlloyDB Abfrage-Backends, die nicht auf Abbruchanfragen reagieren, zwangsweise beenden. So lässt sich verhindern, dass nicht reagierende Back-Ends die Replikation über einen längeren Zeitraum blockieren.

Verzögerungsbasierte Drosselung von Leseabfragen

Mit AlloyDB können Sie auch festlegen, ob die verzögerungsbasierte Drosselung von Leseabfragen auf Leseknoten mit dem Flag google_storage.log_replay_throttle_read_transactions aktiviert werden soll. Wenn der Parameter auf den Standardwert on gesetzt ist, werden die Leseabfragen gedrosselt, indem das Starten neuer Abfragen und das Lesen neuer Puffer für bis zu eine Minute pausiert werden, wenn die Replikationsverzögerung eine Sekunde überschreitet. Diese Funktion verbessert die Replikationsverzögerung, indem sie der Wiederholung mehr Ressourcen zur Verfügung stellt, damit sie schneller aufholen kann. Dies kann jedoch die Latenz von Leseabfragen erhöhen. Wenn Ihre Anwendung nicht empfindlich auf Replikationsverzögerungen reagiert, können Sie die Latenz von Leseabfragen priorisieren, indem Sie google_storage.log_replay_throttle_read_transactions auf off setzen.

Sie können die Auswirkungen der Abfragedrosselung mit den folgenden Methoden überwachen:

  • Logs: Suchen Sie im Log-Explorer nach Delayed.*due to replica lag-Nachrichten in der Datei postgres.log, um festzustellen, wann Abfragen aufgrund von Replikationsverzögerungen verzögert werden.

  • Cloud Monitoring: Verwenden Sie den Messwert alloydb.googleapis.com/instance/postgresql/wait_count, um zu sehen, wie viele Abfragen gedrosselt wurden. Filtern Sie dazu den Messwert nach wait_event_name und suchen Sie nach HighLagThrottle. Wenn Sie die Gesamtzeit sehen möchten, für die Abfragen gedrosselt wurden, können Sie den Messwert alloydb.googleapis.com/instance/postgresql/wait_time mit demselben Filter verwenden. Weitere Informationen finden Sie in der Referenz zu System Insights-Messwerten.

  • Query Insights: Im Dashboard Query Insights wird in der Ansicht Aktive Abfragen das Warteereignis HighLagThrottle in der Spalte Warteereignis angezeigt, wenn eine Abfrage aufgrund einer Replikationsverzögerung gedrosselt wird. Weitere Informationen finden Sie unter Aktive Abfragen überwachen.

Hohe Arbeitslast

Ein plötzlicher Anstieg der Schreibarbeitslast auf der primären Instanz kann eine große Menge an Replikationslogs generieren, was die Lesepoolinstanzen überlasten und zu Replikationsverzögerungen führen kann. Sie können den Schreib-Traffic auf Ihrer primären Instanz in der Google Cloud Console überwachen.

Hohes Volumen an Write-Ahead-Logs aufgrund der Erstellung des ScaNN-Index

Beim Erstellen des ScaNN-Index können große Mengen an WAL-Einträgen für ganzseitige Schreibvorgänge generiert werden. Dies kann zu Verzögerungen beim Senden von WAL-Einträgen von Ihrer primären Instanz an Leseinstanzen führen. Wenn die Replikationsverzögerung auf die Erstellung des ScaNN-Index für eine große Anzahl von Einbettungen zurückzuführen ist, können Sie wal_compression auf der primären Instanz aktivieren, um Netzwerk- und Laufwerks-E/A zu sparen und die Replikationsverzögerung zu reduzieren. Dies kann zu einem geringen zusätzlichen CPU-Overhead führen.

wal_compression komprimiert nur Datensätze mit vollständigen Seitenschreibvorgängen und hat keine Auswirkungen auf die meisten WAL-Datensätze. Das Ändern dieses Flags erfordert keinen Neustart und verursacht keine Ausfallzeiten.

Große Transaktionen

Transaktionen, die eine große Anzahl von Zeilen ändern, z. B. durch Löschen mehrerer Tabellen oder großer Tabellen, generieren außergewöhnlich große COMMIT- oder ABORT-Einträge im Write-Ahead-Log (WAL). Es kann sehr lange dauern, bis diese Einträge auf den Lesepoolknoten wiedergegeben werden, was zu einer vorübergehenden Erhöhung der Replikationsverzögerung führt.

Um dies zu vermeiden, sollten Sie sehr große Batchvorgänge wie Löschvorgänge nicht in einer einzigen Transaktion ausführen. Teilen Sie diese Vorgänge stattdessen in kleinere, häufigere Transaktionen auf. Dadurch wird die Größe einzelner COMMIT- und ABORT-Einträge reduziert, sodass der Replikationsstream flüssiger bleibt und die maximale Replikationsverzögerung verringert wird.

Probleme beheben, die die Replikation verhindern

Damit eine Replikationsverzögerung auftreten kann, muss ein funktionierender Lesepool vorhanden sein. Die folgenden Probleme können die Replikation vollständig verhindern, entweder weil kein Lesepool erstellt werden kann oder weil ein Lesereplikat abstürzt.

Abstürze von Lesepoolinstanzen

In PostgreSQL 14 kann eine Transaktion mit langer Ausführungszeit auf der primären Instanz, die eine lange Liste exklusiver Sperren enthält, dazu führen, dass die Speichernutzung eines Lesereplikats zunimmt. Dies kann schließlich zum Absturz der Lesepoolinstanz führen.

Sie können dieses Problem beheben, indem Sie die Transaktion mit langer Ausführungszeit auf der primären Instanz beenden.

Auswirkungen der Größenanpassung von Instanzen auf die Replikationsverzögerung

Die AlloyDB-Speicherarchitektur sorgt dafür, dass die Verzögerung beim Leeren des Lesepools nicht durch die Größenänderung von Instanzen beeinträchtigt wird. Für die Wiederholung gilt das jedoch nicht. Die Fähigkeit des Replikats zur Wiedergabe hängt von der Last ab. Wenn Sie die Instanzkonfiguration aktualisieren, z. B. durch Ändern der Größe, hat das Replikat je nach Arbeitslast möglicherweise keinen vollständig aufgewärmten Cache, wenn der Vorgang abgeschlossen ist. Das bedeutet, dass die Wiedergabe oder Verarbeitung von Datensätzen, die noch nicht im Cache gespeichert wurden, langsamer ist. In diesem Fall kann sich die Wiedergabeverzögerung vorübergehend erhöhen.