Wie behebe ich Replikationsverzögerungen in meiner Amazon RDS für PostgreSQL DB-Instance?

Kurzbeschreibung

Wenn RDS für PostgreSQL-Lesereplikate hinter der primären Instance zurückfallen, kann es zu Replikationsverzögerungen kommen.

Das Lesereplikat verwendet die native Streaming-Replikation von PostgreSQL, um die Synchronisierung aufrechtzuerhalten. Der Write Ahead Log (WAL)-Empfänger auf dem Lesereplikat fordert die WAL-Daten von der primären Instance an. Wenn der WAL-Sender auf der primären Instance die angeforderten WAL-Daten nicht finden kann, sendet er einen Fehler an die sekundäre Instance. Anschließend versucht RDS für PostgreSQL, archivierte WAL-Daten aus Amazon Simple Storage Service (Amazon S3) wiederherzustellen. Wenn du die WAL-Daten von der primären Instance entfernst, kann die Replikation nicht fortgesetzt werden, da Amazon S3 die Wiederherstellung regionsübergreifender Replikate nicht unterstützt.

Weitere Informationen findest du unter Arbeiten mit Lesereplikaten für Amazon RDS für PostgreSQL.

Hinweis: Die folgende Lösung gilt für Probleme mit der Streaming-Replikation. Informationen zur logischen Replikation findest du unter Wie verwende ich die logische Replikation, um Tabellen zwischen meinen Amazon RDS für PostgreSQL-DB-Instances zu replizieren?

Lösung

Replikationsprobleme identifizieren

Prüfe zum Identifizieren deines spezifischen Replikationsproblems die folgenden Metriken:

• ReplicaLag in Amazon CloudWatch: Diese Metrik misst die Zeit in Sekunden, um die ein Lesereplikat hinter der Quell-DB-Instance zurückliegt.
• Replikationsstatus in der Amazon-RDS-Konsole: Wenn die Replikation stoppt, ändert sich dieses Feld in Error.
• oldestreplicationslotlag in PostgreSQL Version 14.1 und höher bei Verwendung von Replikationsslots: Diese Metrik zeigt die Menge der WAL-Daten in Byte an, die das am stärksten verzögerte Replikat noch nicht erhalten hat.

Du kannst auch die Parameter prüfen, die die PostgreSQL-Replikation steuern.

Wenn die Replikationsverzögerung zunimmt, erhältst du möglicherweise Ereignismeldungen wie die folgenden:

„Streaming replication has stopped.“ Diese Fehlermeldung bedeutet, dass die Streaming-Replikation zwischen der primären und der Replikat-Instance fehlgeschlagen ist. Die Replikation wechselt zur Wiedergabe aus dem Archiv in Amazon S3.

„Streaming replication has been terminated.“ Dieser Fehler tritt nach 30 aufeinanderfolgenden Tagen mit gestoppter Replikation auf. Amazon RDS beendet die Replikation, um eine übermäßige Speichernutzung zu verhindern.

Hinweis: Nachdem die Replikation gestoppt wurde, ist die Lesereplikat-Instance weiterhin verfügbar, aber du kannst die Replikation nicht fortsetzen. Um diesen Zustand zu beheben, erstelle das Lesereplikat neu.

Auf Konfigurationsabweichungen prüfen

Es empfiehlt sich, deine Lesereplikate so zu konfigurieren, dass sie den Spezifikationen der primären Instance entsprechen oder diese übertreffen. Eine kleinere Instance-Klasse oder ein anderer Speichertyp kann zu Verzögerungen führen. Das Replikat muss dieselbe Schreib-Workload wie die primäre Instance verarbeiten und zusätzlich Leseabfragen ausführen. Ändere bei Bedarf deine Lesereplikat-Instance..

Schreib-Workload der primären Instance und Lese-Workload des Replikats prüfen

Schreibvorgänge auf der primären Instance erzeugen viele WAL-Dateien. Überwache zum Identifizieren von Schreiblast die folgenden CloudWatch-Metriken und Enhanced-Monitoring-Werte:

• TransactionLogsDiskUsage
• TransactionLogsGeneration
• WriteIOPS
• WriteThroughput
• WriteLatency

Prüfe auf Durchsatzengpässe für deinen DB-Instance-Klassentyp. Um Probleme zu vermeiden, verteile Schreibaktivitäten auf mehrere Transaktionen. Du kannst CloudWatch-Alarme für WriteLatency und WriteIOPS konfigurieren, um umfangreiche Schreibvorgänge auf der Quell-Instance zu identifizieren.

Eine hohe Leseaktivität auf Replikaten kann die Wiedergabe von WAL-Dateien verlangsamen. Verwende zur Analyse hoher Workloads und zur Prüfung von Ressourcenkonflikten CloudWatch-Metriken oder Enhanced Monitoring auf der Replikat-Instance. Verteile den Leseverkehr bei Bedarf auf mehrere Lesereplikate.

Tabellensperren überwachen

RDS for PostgreSQL verarbeitet eine Sperre vom Typ Access Exclusive, wenn du die folgenden Befehle auf der primären Instance ausführst: DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL und REFRESH MATERIALIZED VIEW ohne CONCURRENTLY. Weitere Informationen findest du unter Explizites Sperren auf der PostgreSQL-Website.

Die Sperre Access Exclusive verhindert für die Dauer der Sperre den Zugriff anderer Transaktionen auf die Tabelle. Die Tabelle bleibt gesperrt, bis die Transaktion endet. Das WAL zeichnet die Sperraktivität auf, und das Lesereplikat gibt diese Aktivität wieder und hält sie aufrecht. Je länger die Tabelle mit einer Sperre vom Typ Access Exclusive gesperrt bleibt, desto größer wird die Replikationsverzögerung.

Um dieses Problem zu vermeiden, empfiehlt es sich, die Katalogtabellen pg_locks und pg_stat_activity regelmäßig abzufragen.

Führe zum Überwachen von Sperren den folgenden Befehl aus:

SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Die Ausgabe zeigt Informationen über blockierte Abfragen und die Prozesse an, die sie blockieren.

RDS für PostgreSQL-Replikationsparameter prüfen

Prüfe zur Vermeidung von Replikationsproblemen die Parameter, die die Replikation von RDS for PostgreSQL steuern. Aktualisiere die Parameterwerte bei Bedarf.

Um die Gesamtzahl deiner Replikationsverbindungen zu unterstützen, kannst du max_replication_slots konfigurieren. Der Standardwert variiert je nach Instance-Klasse. Dieser Wert muss der Gesamtzahl deiner Replikate entsprechen oder größer sein.

Die Parameter max_standby_streaming_delay und max_standby_archive_delay auf der Replikat-Instance können dabei helfen, lang laufende Leseabfragen abzuschließen. Wenn auf dem Replikat ausgeführte Leseabfragen die Quelldaten verändern, pausieren diese Parameter die WAL-Wiedergabe. Wenn du den Wert auf –1 setzt, wartet die WAL-Wiedergabe, bis die Leseabfrage abgeschlossen ist. Diese Pause kann jedoch die Replikationsverzögerung unbegrenzt erhöhen und aufgrund der WAL-Akkumulation auf der Quelle zu hohem Speicherverbrauch führen.

Zur Gewährleistung der Replikationsstabilität verwaltet RDS for PostgreSQL mehrere Parameter automatisch: max_connections, max_worker_processes, max_wal_senders, max_prepared_transactions und max_locks_per_transaction. Auf deinem Replikat setzt RDS für PostgreSQL diese Parameter so, dass sie den Werten der primären Instance entsprechen oder diese überschreiten.

Der Parameter hot_standby_feedback ermöglicht es Replikaten, Abfragekonflikte an die primäre Instance zu melden. RDS für PostgreSQL deaktiviert diesen Parameter standardmäßig. Wenn du den Parameter aktivierst, kann es bei Tabellen auf der primären Instance zu Bloat kommen. Wenn du die folgende Fehlermeldung erhältst, verwende den Parameter hot_standby_feedback:

„ERROR: canceling statement due to conflict with recover. Detail: User query might have needed to see row versions that must be removed“

Best Practices für die Replikation von RDS for PostgreSQL und regionsübergreifende Lesereplikate prüfen

Die folgenden Ursachen können ebenfalls zu Replikationsverzögerungen führen:

• Netzwerkunterbrechungen zwischen Instances
• Beschädigte oder fehlende WAL-Dateien
• Instance-Skalierungsvorgänge
• Wartungsaktivitäten
• Zeiträume ohne Transaktionen
  Hinweis: Weitere Informationen findest du unter Arbeiten mit Lesereplikaten für Amazon RDS für PostgreSQL.

Informationen zu diesen Szenarien findest du unter Best Practices für die Replikation von Amazon RDS für PostgreSQL und Best Practices für regionsübergreifende Lesereplikate von Amazon RDS für PostgreSQL.

Transaktionen überwachen

Führe zum Prüfen aktiver Transaktionen auf der primären Instance, die sich auf die Replikation auswirken könnten, den folgenden Befehl aus:

SELECT datname, pid, usename, client_addr, backend_start, xact_start, current_timestamp - xact_start AS xact_runtime, state, backend_xmin FROM pg_stat_activity WHERE state='active' OR state='idle in transaction';

Die Ausgabe zeigt aktuell ausgeführte Transaktionen und deren Dauer an. Lang laufende Transaktionen können die Replikationsleistung beeinträchtigen.

Führe zum Beenden einer problematischen Abfrage den folgenden Befehl aus:

SELECT pg_terminate_backend(PID);

Hinweis: Ersetze PID durch die Prozess-ID der Abfrage, die du beenden möchtest.

Ähnliche Informationen

Replikation auf der PostgreSQL-Website

Verwendung der logischen Replikation zur Replikation von verwaltetem Amazon RDS für PostgreSQL und Amazon Aurora auf selbstverwaltetes PostgreSQL