Probleme bei der Replikation beheben

AlloyDB hat eine Architektur, die Computing 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) im freigegebenen Speicher aufgezeichnet. Diese Änderungen werden dann in die In-Memory-Caches der Read-Pool-Instanzen 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. 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. Dies ist die Zeit, die benötigt wird, um das WAL von der primären Instanz zu senden und auf dem 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 beispielsweise bei regionenübergreifenden Replikaten Sorgen um Datenverlust machen, müssen Sie die Flush-Verzögerung genau im Blick behalten. 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 genau auf die Replay-Verzögerung achten. Eine hohe Replay-Verzögerung bedeutet, dass die Daten in Ihren Lesereplikaten veraltet sind.

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 intensive Lese-Arbeitslast auf einer Lesepool-Instanz 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 des Lesepoolknotens: Wenn Ihre primäre Instanz viel größer als Ihre Lesepoolknoten ist, werden möglicherweise schneller Replikationslogs 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 beispielsweise eine Sperre für ein Datenbankobjekt hat, das vom Replikationsprozess aktualisiert werden muss, wird die Replikation blockiert, bis die Sperre aufgehoben wird. Diese werden als Puffer-Pin-Konflikte bezeichnet.

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 Replikationsprozess 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 können Abfragen mit langer Ausführungszeit in einen anderen Lesepool verschieben, in dem eine geringe Replikationsverzögerung nicht so wichtig ist.

  • alloydb.promote_cancel_to_terminate aktivieren: Mit diesem Flag, das standardmäßig aktiviert ist, werden Abfrage-Back-Ends, die nicht auf Abbruchanfragen reagieren, von AlloyDB zwangsweise beendet. So kann verhindert werden, dass nicht reagierende Back-Ends die Replikation über längere Zeiträume blockieren.

Temporäre Drosselung von Leseanfragen

Mit dem Flag google_storage.log_replay_throttle_read_transactions können Sie auch festlegen, ob die latenzbasierte Drosselung einer Leseanfrage 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 Leselatenz 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 Abfragebegrenzung 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

Große Transaktionen, z. B. COMMIT- oder ABORT-Datensätze, die sich auf eine große Anzahl von Zeilen auswirken, können lange dauern, bis sie auf die Instanzen des Lesepools repliziert werden. In PostgreSQL 14 kann eine lang andauernde Transaktion, die eine lange Liste exklusiver Sperren enthält, dazu führen, dass die Arbeitsspeichernutzung des 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.

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.

Probleme beim Erstellen von Lesepools

Wenn die Erstellung eines Lesepools fehlschlägt, wird möglicherweise eine Failed to create read pool-Meldung in den AlloyDB-Logs in Cloud Logging angezeigt. Dies kann passieren, wenn der Cluster das maximale Speicherlimit erreicht hat und die primäre Instanz keinen weiteren Speicherplatz zuweisen kann. AlloyDB skaliert den Speicher zwar automatisch, aber Sie müssen möglicherweise untersuchen, was Speicherplatz verbraucht, und unnötige Daten löschen oder den Support kontaktieren, um eine Erhöhung Ihres Speicherkontingents zu beantragen.

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 möglich ist, 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 Aufzeichnungen, die noch nicht im Cache gespeichert sind, länger dauert. In diesem Fall kann es sein, dass die Wiedergabeverzögerung vorübergehend zunimmt.