Probleme bei der Replikation beheben

AlloyDB hat eine Architektur, die Computing und Speicher trennt, sodass sie unabhängig voneinander skaliert werden können. Die primäre Instanz und die Lesepoolinstanzen verwenden zwar denselben zugrunde liegenden Speicher, die Replikation ist jedoch weiterhin ein wichtiger Prozess, um die Datenkonsistenz und Aktualität der Lesereplikate zu gewährleisten. In einem AlloyDB-Cluster werden Schreibvorgänge in der primären Instanz ausgeführt und dann im Write-Ahead-Log (WAL) aufgezeichnet. Diese Änderungen werden dann auf die Knoten des Lesepools repliziert. Wenn Sie Probleme beheben möchten, ist es wichtig, dass Sie die beiden Hauptschritte dieses Replikationsprozesses verstehen:

  • 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 den WAL dann sofort auf der Festplatte.
  • WAL-Anwendung (oder -Wiedergabe): Der persistierte WAL wird auf dem Replikat wiedergegeben. Das bedeutet, dass die Änderungen auf die Caches des Replikats angewendet werden.

Verzögerungen bei einem dieser Schritte tragen zur sogenannten Replikationsverzögerung bei. Dieser Begriff ist jedoch möglicherweise mehrdeutig. Genauer gesagt, kann die Replikationsverzögerung in die folgenden zwei Komponenten unterteilt werden:

  • Flush- oder Netzwerkverzögerung: Dies ist die Verzögerung beim WAL-Flush-Schritt. Dies ist die Zeit, die benötigt wird, um das WAL von der primären Instanz zu senden und im Replikat zu speichern.
  • Replay-Verzögerung: Dies ist die Verzögerung beim Anwenden des WAL. Das ist die Zeit, die das Replikat benötigt, um die Änderungen aus dem WAL anzuwenden.

Ob Sie sich mehr um den Flush- oder den Replay-Lag kümmern müssen, hängt von Ihrem Anwendungsfall ab:

  • Wenn Sie sich Sorgen um Datenverlust machen, z. B. bei sekundären Clustern, müssen Sie genau auf den Flush-Lag achten. Wenn die WAL noch nicht auf dem Replikat gespeichert ist und der primäre Server 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 auf die Flush-Verzögerung als auch auf die Replay-Verzögerung achten. Eine Verzögerung in einem der beiden Schritte – sei es beim Übertragen oder Anwenden des WAL – führt zu veralteten Daten auf Ihren Lesereplikaten.

Replikationsverzögerung prüfen

Sie können die Replikationsverzögerung Ihrer Lesepoolinstanzen in der Google Cloud Konsole ü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 Informationen dazu, wie Sie diese beheben können.

Ressourcenkonflikt

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

  • CPU- und Arbeitsspeicherbelastung: 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 Ressourcennutzung feststellen, müssen Sie möglicherweise die Lesepoolinstanzen hoch- oder herunterskalieren.
  • Größe der Lesepoolknoten: Wenn Ihre primäre Instanz viel größer als Ihre Lesepoolknoten ist, werden möglicherweise Replikationslogs schneller generiert, als die Leseknoten sie verarbeiten können. In solchen Fällen empfiehlt es sich, Leseknoten mit mehr Ressourcen zu verwenden.

Replikationskonflikte

Leseanfragen können den Replikationsprozess manchmal blockieren, da sie Ressourcen belegen, auf die der Replikationsprozess wartet. Wenn eine Leseanfrage eine Sperre für ein Datenbankobjekt enthält, das durch den Replay-Prozess aktualisiert werden muss, führt dies zu einem Sperrenkonflikt. Wenn eine Abfrage einen Pin für einen Datenpuffer enthält, der durch die Wiedergabe geändert werden muss, führt dies zu einem Konflikt mit dem Puffer-Pin. In beiden Fällen wird die Wiedergabe blockiert, bis die Ressource durch die Anfrage freigegeben wird.

Sie können diese Konflikte erkennen, indem Sie im Log-Explorer in der Datei postgres.log nach canceling statement due to conflict with recovery-Meldungen suchen.

So können Sie Replikationskonflikte vermeiden:

  • max_standby_streaming_delay reduzieren: Mit diesem Parameter wird festgelegt, wie lange der Replay-Prozess wartet, bevor blockierende Abfragen abgebrochen werden. Der Standardwert beträgt 30 Sekunden. Durch Verringern dieses Werts kann die Replikationsverzögerung reduziert werden, es kann aber auch dazu führen, dass mehr Leseanfragen abgebrochen werden. Sie können diesen Parameter anpassen, um das beste Gleichgewicht für Ihre Anwendung zu finden.

  • Lange laufende Abfragen vermeiden: Lange laufende Abfragen in Lesepools können die Wahrscheinlichkeit von Replikationskonflikten erhöhen. Sie sollten Abfragen mit langer Ausführungszeit in einen anderen Lesepool verschieben, 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 kann verhindert werden, dass nicht reagierende Back-Ends die Replikation über längere Zeiträume blockieren.

Drosselung von Leseanfragen basierend auf Verzögerung

Mit dem Flag google_storage.log_replay_throttle_read_transactions können Sie auch festlegen, ob die verzögerungsbasierte Drosselung von Leseanfragen auf Leseknoten aktiviert werden soll. Wenn der Parameter auf den Standardwert on festgelegt ist, werden die Leseanfragen gedrosselt, indem neue Anfragen pausiert und neue Puffer bis zu einer Minute lang gelesen werden, wenn die Replikationsverzögerung eine Sekunde überschreitet. Diese Funktion ist ein Kompromiss, der die Replikationsverzögerung verbessert, indem dem Replay mehr Ressourcen zur Verfügung gestellt werden, damit es schneller aufholen kann. Dies kann jedoch die Latenz von Leseanfragen erhöhen. Wenn Ihre Anwendung nicht empfindlich auf die Replikationsverzögerung reagiert, können Sie die Latenz von Leseanfragen priorisieren, indem Sie google_storage.log_replay_throttle_read_transactions auf off setzen.

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

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

  • Cloud Monitoring: Verwenden Sie den Messwert alloydb.googleapis.com/instance/postgresql/wait_count, um zu sehen, wie viele Anfragen gedrosselt wurden. Filtern Sie dazu den Messwert nach wait_event_name und suchen Sie nach HighLagThrottle. Wenn Sie die Gesamtzeit sehen möchten, in der 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 Messwerten für Systemstatistiken.

  • Query Insights: Im Dashboard Query Insights wird in der Ansicht Aktive Abfragen das Warteereignis HighLagThrottle in der Spalte Warteereignis angezeigt, wenn eine Abfrage aufgrund von 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 Anzahl von Replikationslogs generieren, die die Lesepoolinstanzen überlasten und zu Replikationsverzögerungen führen können. Sie können den Schreibtraffic für Ihre primäre Instanz in der Google Cloud Console überwachen.

Große Transaktionen

Transaktionen, bei denen eine große Anzahl von Zeilen geändert wird, z. B. durch das 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 einige Zeit dauern, bis diese Datensätze auf den Lesepoolknoten wiedergegeben werden. Dies führt zu einer vorübergehenden Erhöhung der Replikationsverzögerung.

Um dieses Problem zu vermeiden, sollten Sie keine sehr großen Batchvorgänge wie Löschvorgänge in einer einzelnen Transaktion ausführen. Teilen Sie diese Vorgänge stattdessen in kleinere, häufigere Transaktionen auf. Dadurch wird die Größe der einzelnen COMMIT- und ABORT-Datensätze reduziert, sodass der Replikationsstream flüssiger bleibt und der maximale Replikationsrückstand verringert wird.

Probleme beheben, die die Replikation verhindern

Bevor es zu einer Replikationsverzögerung kommen kann, muss ein funktionierender Lesepool vorhanden sein. Die folgenden Probleme können die Replikation vollständig verhindern, indem sie entweder die Erstellung eines Lesepools verhindern oder ein Lesereplikat zum Absturz bringen.

Abstürze von Lesepoolinstanzen

In PostgreSQL 14 kann eine langlaufende Transaktion auf der primären Instanz, die eine lange Liste exklusiver Sperren enthält, dazu führen, dass die Arbeitsspeichernutzung eines Lesereplikats ansteigt, was schließlich zum Absturz der Lesepoolinstanz führen kann.

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

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

Die Speicherarchitektur von AlloyDB sorgt dafür, dass die Verzögerung beim Leeren des Lesepools nicht durch die Größenänderung von Instanzen beeinträchtigt wird. Das gilt jedoch nicht für die Wiederholung. Ob ein Replay möglich ist, hängt von der Last ab, die auf dem Replikat liegt. 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 das Wiedergeben oder Verarbeiten von Aufzeichnungen, die noch nicht im Cache gespeichert sind, länger dauert. In diesem Fall kann es sein, dass die Wiedergabeverzögerung vorübergehend zunimmt.