Probleme bei der Replikation beheben

AlloyDB hat eine Architektur, die Rechenleistung und Speicher trennt, sodass sie unabhängig 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, lässt sich die Replikationsverzögerung in die folgenden zwei Komponenten unterteilen:

  • Flush- oder Netzwerkverzögerung: Dies ist die Verzögerung beim WAL-Flush-Schritt. Das ist die Zeit, die benötigt wird, um den WAL von der primären Instanz zu senden und im Replikat zu speichern.
  • Replay-Verzögerung: Dies ist die Verzögerung beim Anwenden von 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 – sowohl beim Übertragen als auch beim 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 Lese-Arbeitslast 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 die Ressourcennutzung hoch ist, 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 einer größeren Größe zu verwenden, um den Replikaten mehr Ressourcen zur Verfügung zu stellen.

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: Dieser Parameter bestimmt, wie lange der Replay-Prozess wartet, bevor blockierende Anfragen 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.

  • Vermeiden Sie Abfragen mit langer Ausführungszeit: Abfragen mit langer Ausführungszeit in Lesepools können die Wahrscheinlichkeit von Replikationskonflikten erhöhen. Sie können 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 latenzbasierte Drosselung von Leseanfragen auf Lesen-Knoten 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.

Hohes Write-Ahead-Log-Volumen aufgrund der Erstellung von ScaNN-Indizes

Beim Erstellen des ScaNN-Index können große Mengen von WAL-Datensätzen für das Schreiben ganzer Seiten generiert werden. Dies kann zu Verzögerungen beim Senden von WAL-Datensätzen von Ihrer primären Instanz an Leseinstanzen führen. Wenn die Replikationsverzögerung mit dem Erstellen des ScaNN-Index für eine große Anzahl von Einbettungen zusammenhängt, können Sie wal_compression aktivieren, um Netzwerk- und Festplatten-E/A zu sparen und die Replikationsverzögerung zu verringern. Dies kann zu einem geringen zusätzlichen CPU-Overhead führen.

wal_compression komprimiert nur Datensätze für das Schreiben ganzer Seiten und hat keine Auswirkungen auf die meisten WAL-Einträge. Das Ändern dieses Flags erfordert keinen Neustart und führt zu keinen Ausfallzeiten.

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 Replikations-Lag 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 verhindern, dass die Replikation überhaupt stattfindet, entweder indem die Erstellung eines Lesepools verhindert wird oder indem ein Lesereplikat abstürzt.

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ößenanpassung von Instanzen beeinträchtigt wird. Das gilt jedoch nicht für die Wiederholung. Ob die Replikation wiedergegeben werden kann, hängt von der Last ab, die auf der Replik 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 Datensätzen, die noch nicht im Cache gespeichert sind, länger dauert. In diesem Fall kann es sein, dass sich die Replay-Verzögerung vorübergehend erhöht.