Warum habe ich Replikationsverzögerungen und -fehler in meiner RDS für PostgreSQL-DB-Instance?

Kurzbeschreibung

Sie können Lesevorgänge für Ihre Amazon RDS für PostgreSQL-DB-Instance skalieren, indem Sie der Instance Read Replicas hinzufügen. RDS für PostgreSQL verwendet die native PostgreSQL-Streaming-Replikation, um eine schreibgeschützte Kopie einer Quell-DB-Instance zu erstellen. Diese Read-Replica-DB-Instance ist eine asynchron erstellte physische Replik der Quell-DB-Instance. Das bedeutet, dass das Replikat manchmal nicht mit der primären DB-Instance Schritt halten kann. Infolgedessen kann es zu einer Verzögerung der Replikation kommen. Die Replikat-DB wird durch eine spezielle Verbindung erstellt, die die Write-Ahead-Log-Daten (WAL) von der Quell-DB-Instance zur Read Replica überträgt. Daher überprüft die Read Replica die WAL-Protokolle, um die auf der primären Instance vorgenommenen Änderungen zu replizieren. Wenn die Read Replica die WAL auf der primären Instance nicht finden kann, wird die Read Replica aus den archivierten WAL-Daten in Amazon Simple Storage Service (Amazon S3) wiederhergestellt. Weitere Informationen finden Sie unter Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen.

Sie können die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie die Amazon RDS ReplicaLag-Metrik anzeigen. Diese Metrik zeigt, wie weit eine Read Replica hinter ihre Quell-DB-Instance zurückgefallen ist. Amazon RDS überwacht den Replikationsstatus Ihrer Read Replica. Anschließend wird das Feld Replication State in der Amazon-RDS-Konsole auf Fehler aktualisiert, wenn die Replikation aus irgendeinem Grund angehalten wird. Die ReplicaLag-Metrik gibt an, wie gut eine Read Replica mit der Quell-DB-Instance Schritt hält und wie viel Latenz zwischen der Quell-DB-Instance und einer bestimmten Lese-Instance besteht.

Lösung

Möglicherweise wird in den RDS für PostgreSQL-Fehlerprotokollen einer der folgenden Fehler angezeigt, wenn die Replikatverzögerung zunimmt:

• Die Streaming-Replikation wurde angehalten: Sie erhalten diesen Fehler, wenn die Streaming-Replikation zwischen der primären und den Replikat-Instances ausfällt. In diesem Fall wird die Replikation vom Archivspeicherort in Amazon S3 wiedergegeben, was zu einem weiteren Anstieg der Replikatverzögerung führt.
• Die Streaming-Replikation wurde beendet: Dieser Fehler wird angezeigt, wenn die Replikation für mehr als 30 aufeinanderfolgende Tage angehalten wird, entweder manuell oder aufgrund eines Replikationsfehlers. In diesem Fall beendet Amazon RDS die Replikation zwischen der primären DB-Instance und allen Read Replicas, um erhöhte Speicheranforderungen auf der primären Instance und längere Failover-Zeiten zu verhindern.

Die Read-Replica-Instance ist auch nach Beendigung der Replikation verfügbar. Die Replikation kann jedoch nicht fortgesetzt werden, da die von der Read Replica benötigten Transaktionsprotokolle nach Beendigung der Replikation aus der primären Instance gelöscht werden.

Die häufigsten Gründe für den Anstieg der Replikatverzögerung sind die folgenden:

• Konfigurationsunterschiede zwischen Primär- und Replica-Instances
• Starker Schreib-Workload auf der primären Instance
• Transaktionen, die schon lange laufen
• Exklusive Sperre für primäre Instance-Tabellen
• Beschädigte oder fehlende WAL-Datei
• Probleme mit dem Netzwerk
• Falsche Parametrierung
• Keine Transaktionen

Konfigurationsunterschiede zwischen primärer Instance und Read Replica

Falsche Konfigurationen der Replikat-Instance können die Replikationsleistung beeinträchtigen. Read Replica verarbeitet einen Schreib-Workload, der dem der Quell-Instance ähnlich ist, zusammen mit zusätzlichen Leseabfragen. Verwenden Sie daher Replikate derselben oder einer höheren Instance-Klasse und desselben Speichertyps als Quell-Instance. Da das Replikat dieselbe Schreibaktivität wie die Quell-Instance wiedergeben muss, kann die Verwendung eines Replikats einer Klasse mit niedrigerer Instance eine hohe Latenz für das Replikat verursachen und die Replikationsverzögerung erhöhen. Auch nicht übereinstimmende Speicherkonfigurationen erhöhen die Replikationsverzögerung.

Starker Schreib-Workload auf der primären Instance

Eine hohe Schreib-Workload auf der primären Instance kann zu einem hohen Zustrom von WAL-Dateien führen. Eine Erhöhung der Anzahl von WAL-Dateien und die Wiedergabe dieser Dateien auf Read Replicas können die gesamte Replikationsleistung verlangsamen. Wenn Sie eine Zunahme der Replikatverzögerung feststellen, sollten Sie daher unbedingt die Schreibaktivität auf der primären Instance überprüfen. Sie können CloudWatch-Metriken oder Enhanced Monitoring zur Analyse dieses Workloads verwenden. Zeigen Sie Werte für TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput und WriteLatency an, um festzustellen, ob die Quell-Instance unter einer starken Schreib-Workload steht. Sie können auch auf Durchsatzebene nach Engpässen suchen. Jeder Instance-Typ hat seinen dedizierten Durchsatz. Weitere Informationen finden Sie unter Hardwarespezifikationen für DB-Instance-Klassen.

Um dieses Problem zu vermeiden, kontrollieren und verteilen Sie die Schreibaktivität für die Quell-Instance. Anstatt viele Schreibaktivitäten gemeinsam durchzuführen, sollten Sie Ihre Aufgabe in kleinere Auftragspakete aufteilen und diese Bündel dann gleichmäßig auf mehrere Transaktionen verteilen. Sie können CloudWatch-Alerts für Metriken wie Writelatency und WriteIOPS verwenden, um über umfangreiche Schreibvorgänge auf der Quell-Instance informiert zu werden.

Transaktionen, die schon lange laufen

Aktive Transaktionen, die über einen längeren Zeitraum in der Datenbank ausgeführt werden, können den WAL-Replikationsprozess stören und dadurch die Replikationsverzögerung erhöhen. Überwachen Sie die Laufzeit aktiver Transaktionen daher unbedingt mit der PostgreSQL-Ansicht pg_stat_activity.

Führen Sie eine Abfrage für die primäre Instance ähnlich der folgenden aus, um die Prozess-ID (PID) der Abfrage zu ermitteln, die über einen längeren Zeitraum ausgeführt wird:

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';

Nachdem Sie die PID der Abfrage ermittelt haben, können Sie die Abfrage beenden.

Führen Sie für die primäre Instance eine Abfrage ähnlich der folgenden aus, um die Abfrage zu beenden:

SELECT pg_terminate_backend(PID);

Sie können die Abfrage auch neu schreiben oder optimieren, um Transaktionen zu vermeiden, die über einen längeren Zeitraum ausgeführt werden.

Exklusive Sperre für primäre Instance-Tabellen

Wenn Sie Befehle wie DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW (ohne CONCURRENTLY) auf der primären Instance ausführen, verarbeitet PostgreSQL eine Access Exclusive-Sperre. Diese Sperre hindert alle anderen Transaktionen für die Haltedauer der Sperre am Zugriff auf die Tabelle. Normalerweise bleibt die Tabelle gesperrt, bis die Transaktion beendet ist. Diese Sperraktivität wird in WAL aufgezeichnet und dann von der Read Replica wiedergegeben und gehalten. Je länger die Tabelle unter einer Access Exclusive-Sperre steht, desto länger ist die Replikationsverzögerung.

Um dieses Problem zu vermeiden, empfiehlt es sich, die Transaktionen zu überwachen, indem Sie regelmäßig die Katalogtabellen pg_locks und pg_stat_activity abfragen.

Beispiel:

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

Beschädigte oder fehlende WAL-Datei

Eine beschädigte oder fehlende WAL-Datei kann zu einer Verzögerung des Replikats führen. In diesem Fall wird in den PostgreSQL-Protokollen ein Fehler angezeigt, der besagt, dass die WAL nicht geöffnet werden kann. Möglicherweise wird auch der Fehler „Das angeforderte WAL-Segment XXX wurde bereits entfernt“ angezeigt.

Probleme mit dem Netzwerk

Eine Netzwerkunterbrechung zwischen der primären und der Replikat-Instance kann Probleme bei der Streaming-Replikation verursachen, die zu einer erhöhten Replikatverzögerung führen können.

Falsche Parametrierung

Das falsche Festlegen einiger benutzerdefinierter Parameter in der Serverkonfigurationsparametergruppe kann zu einer erhöhten Replikatverzögerung führen. Im Folgenden sind einige der Parameter aufgeführt, die Sie korrekt festlegen müssen:

• wal_keep_segments: Dieser Parameter gibt die Anzahl der WAL-Dateien an, die die primäre Instance im Verzeichnis pg_wal aufbewahrt. Der Standardwert für diesen Parameter ist auf 32 festgelegt. Wenn dieser Parameter nicht auf einen Wert festgelegt ist, der für Ihre Bereitstellung hoch genug ist, fällt die Read Replica möglicherweise zurück, wodurch die Streaming-Replikation angehalten wird. In diesem Fall generiert RDS einen Replikationsfehler und beginnt mit der Wiederherstellung der Read Replica, indem die archivierten WAL-Daten der primären Instance von S3 erneut abgespielt werden. Dieser Wiederherstellungsprozess wird fortgesetzt, bis die Read Replica die Streaming-Replikation fortsetzen kann.
  Hinweis: In PostgreSQL Version 13 heißt der wal_keep_segments-Parameter wal_keep_size. Dieser Parameter dient demselben Zweck wie wal_keep_segments. Der Standardwert für diesen Parameter ist jedoch in MB (2048 MB) und nicht in der Anzahl der Dateien definiert.
• max_wal_senders: Dieser Parameter gibt die maximale Anzahl von Verbindungen an, die die primäre Instance gleichzeitig über das Streaming-Replikationsprotokoll unterstützen kann. Der Standardwert für diesen Parameter für RDS für PostgreSQL 13 und höhere Versionen ist 20. Dieser Parameter sollte auf einen Wert gesetzt werden, der etwas höher ist als die tatsächliche Anzahl der Read Replicas. Wenn dieser Parameter auf einen Wert festgelegt wird, der unter der Anzahl der Read Replicas liegt, wird die Replikation angehalten.
• hot_standby_feedback: Dieser Parameter gibt an, ob die Replikat-Instance Feedback zu Abfragen an die primäre Instance sendet, die derzeit in der Replikat-Instance ausgeführt werden. Durch Aktivieren dieses Parameters kuratieren Sie die folgende Fehlermeldung an der Quell-Instance und verschieben den VACUUM-Vorgang für verwandte Tabellen, sofern die Leseabfrage in der Replikat-Instance nicht abgeschlossen ist. Daher kann eine Replikat-Instance, bei der hot_standby_feedback aktiviert ist, Abfragen mit langer Laufzeit bedienen. Durch diesen Parameter können jedoch Tabellen in der Quell-Instance aufgebläht werden. Achten Sie darauf, Abfragen mit langer Ausführungsdauer in Replikat-Instances zu überwachen, um schwerwiegende Probleme wie Out-of-Storage und Transaction ID Wraparound in der primären Instance zu vermeiden.

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

• max_standby_streaming_delay/max_standby_archive_delay: Sie können Parameter wie max_standby_archive_delay oder max_standby_streaming_delay auf der Replikat-Instance aktivieren, um lang andauernde Leseabfragen abzuschließen. Diese Parameter unterbrechen die WAL-Wiedergabe im Replikat, wenn die Quelldaten geändert werden, wenn Leseabfragen auf dem Replikat ausgeführt werden. Ein Wert von -1 für diese Parameter lässt die WAL-Wiedergabe warten, bis die Leseabfrage abgeschlossen ist. Diese Pause erhöht jedoch die Replikationsverzögerung auf unbestimmte Zeit und führt aufgrund der WAL-Akkumulation zu einem hohen Speicherverbrauch an der Quelle.

Keine Transaktionen

Wenn keine Benutzertransaktionen auf der Quell-DB-Instance stattfinden, meldet das PostgreSQL-Lesereplikat eine Replikationsverzögerung von bis zu fünf Minuten.

---

Relevante Informationen

Arbeiten mit Read Replicas für Amazon RDS für PostgreSQL

PostgreSQL-Dokumentation für die Serverkonfiguration