Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen - Amazon Relational Database Service
Grundlegendes zu Parametern, die die Replikation steuernFestlegen der Parameter, die den gemeinsam genutzten Speicher steuern

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen

Wie in Konfiguration von Read Replicas mit PostgreSQL erläutert, verwendet RDS für PostgreSQL das native Streaming-Replikationsprotokoll von PostgreSQL, um WAL-Daten von der Quell-DB-Instance zu senden. Es sendet Quell-WAL-Daten an Lesereplikate sowohl für regionale als auch regionsübergreifende Lesereplikate. Mit Version 9.4 führte PostgreSQL physische Replikationsslots als unterstützenden Mechanismus für den Replikationsprozess ein.

Ein physischer Replikationsslot verhindert, dass eine Quell-DB-Instance WAL-Daten entfernt, bevor sie von allen Lesereplikaten verbraucht werden. Jedes Lesereplikat hat einen eigenen physischen Slot in der Quell-DB-Instance. Der Slot verfolgt das älteste WAL (nach logischer Sequenznummer, LSN), das möglicherweise vom Replikat benötigt wird. Nachdem alle Slots und DB-Verbindungen über eine bestimmte WAL (LSN) hinausgegangen sind, wird diese LSN zum Kandidaten für die Entfernung am nächsten Checkpunkt.

Amazon RDS verwendet Amazon S3, um WAL-Daten zu archivieren. Bei regionalen Lesereplikaten können Sie diese archivierten Daten verwenden, um das Lesereplikat bei Bedarf wiederherzustellen. Dies kann beispielsweise erforderlich werden, wenn die Verbindung zwischen Quell-DB und Lesereplikat aus irgendeinem Grund unterbrochen wird.

In der folgenden Tabelle finden Sie eine Zusammenfassung der Unterschiede zwischen PostgreSQL-Versionen und den unterstützenden Mechanismen für regional und regionsübergreifend, die von RDS für PostgreSQL verwendet werden.

Version Regional Regionsübergreifend
PostgreSQL 14.1 und höhere Versionen

  • Replikationsslots

  • Amazon-S3-Archiv

  • Replikationsslots
PostgreSQL 13 und niedrigere Versionen

  • Amazon-S3-Archiv

  • Replikationsslots

Weitere Informationen finden Sie unter Überwachen und Optimieren des Replikationsprozesses.

Grundlegendes zu Parametern, die die PostgreSQL-Replikation steuern

Die folgenden Parameter beeinflussen den Replikationsprozess und bestimmen, wie gut Lesereplikate mit der Quell-DB-Instance auf dem neuesten Stand bleiben:

max_wal_senders

Der Parameter max_wal_senders gibt die maximale Anzahl von Verbindungen an, die die Quell-DB-Instance gleichzeitig über das Streaming-Replikationsprotokoll unterstützen kann.

Der Standardwert variiert für Versionen von RDS für PostgreSQL:

  • Für die Versionen 13, 14 und 15 ist der Standardwert 20.

  • Für die Versionen 16 und höher ist der Standardwert 35.

Dieser Parameter sollte etwas höher als die tatsächliche Anzahl der Lesereplikate eingestellt werden. Wenn dieser Parameter für die Anzahl der Lesereplikate zu niedrig eingestellt ist, wird die Replikation beendet.

Weitere Informationen dazu finden Sie im Abschnitt max_wal_senders der PostgreSQL-Dokumentation.

Anmerkung

max_wal_senders ist ein statischer Parameter, der einen Neustart der DB-Instance erfordert, damit die Änderungen wirksam werden.

wal_keep_segments

Der Parameter wal_keep_segments gibt die Anzahl der Write-Ahead Log (WAL)-Dateien an, die die Quell-DB-Instance im pg_wal-Verzeichnis speichert. Die Standardeinstellung ist 32.

Wenn wal_keep_segments nicht auf einen ausreichend großen Wert für Ihre Bereitstellung festgelegt ist, kann ein Lesereplikat so weit zurückbleiben, dass das Streaming der Replikation anhält. In diesem Fall generiert Amazon RDS einen Replikationsfehler und beginnt mit der Wiederherstellung des Lesereplikats. Dies geschieht, indem es die archivierten WAL-Daten der Quell-DB-Instance von Amazon S3 wiedergibt. Dieser Wiederherstellungsprozess wird fortgeführt, bis das Lesereplikat ausreichend nah am aktuellen Stand angekommen ist, um mit dem Streaming der Replikation fortfahren zu können. Sie können diesen Prozess unter Beispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen in Aktion sehen, wie er vom PostgreSQL-Protokoll erfasst wurde.

Anmerkung

In PostgreSQL Version 13 wird der Parameter wal_keep_segments als wal_keep_size bezeichnet. Er dient dem gleichen Zweck wie wal_keep_segments, der Standardwert wird jedoch in Megabyte (MB) (2 048 MB) und nicht als Anzahl der Dateien angegeben. Weitere Informationen finden Sie unter wal_keep_segments und wal_keep_size in der PostgreSQL-Dokumentation.

max_slot_wal_keep_size

Der Parameter max_slot_wal_keep_size steuert die Menge an WAL-Daten, die die RDS-for-PostgreSQL-DB-Instance im Verzeichnis pg_wal für Slots speichert. Dieser Parameter wird für Konfigurationen verwendet, die Replikationsslots nutzen. Der Standardwert für diesen Parameter ist -1, was bedeutet, dass es keine Begrenzung gibt, wie viele WAL-Daten auf der Quell-DB-Instance gespeichert werden. Weitere Informationen zur Überwachung Ihrer Replikationsslots finden Sie unter Überwachen von Replikationsslots für Ihre RDS-for-PostgreSQL-DB-Instance.

Weitere Informationen zu diesem Parameter finden Sie unter max_slot_wal_keep_size in der PostgreSQL-Dokumentation.

Sobald ein Stream, der WAL-Daten an ein Lesereplikat leitet, unterbrochen wird, wechselt PostgreSQL in den Wiederherstellungsmodus. Es stellt das Lesereplikat mithilfe archivierter WAL-Daten von Amazon S3 oder mithilfe der WAL-Daten, die mit dem Replikationsslot verknüpft sind, wieder her. Sobald dieser Vorgang abgeschlossen ist, nimmt PostgreSQL das Streaming der Replikation wieder auf.

Beispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen

Im folgenden Beispiel finden Sie die Protokolldetails, die den Wiederherstellungsprozess für ein Lesereplikat veranschaulichen. Das Beispiel stammt von einer RDS for PostgreSQL-DB-Instance, auf der PostgreSQL Version 12.9 in derselben Version AWS-Region wie die Quell-DB ausgeführt wird, sodass keine Replikationsslots verwendet werden. Der Wiederherstellungsprozess ist derselbe wie für andere RDS-for-PostgreSQL-DB-Instances, die eine frühere PostgreSQL-Version als 14.1 mit regionalen Lesereplikaten ausführen.

Wenn das Lesereplikat den Kontakt zur Quell-DB-Instance verloren hat, zeichnet Amazon RDS das Problem im Protokoll als FATAL: could not receive data from WAL stream-Nachricht zusammen mit dem ERROR: requested WAL segment ... has already been removed auf. Wie in der fett gedruckten Zeile gezeigt, stellt Amazon RDS das Replikat wieder her, indem es eine archivierte WAL-Datei wiedergibt. 

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Wenn Amazon RDS genügend archivierte WAL-Daten wiedergegeben hat, damit das Replikat aufholt, wird das Streaming an das Lesereplikat fortgesetzt. Wenn das Streaming fortgesetzt wird, schreibt Amazon RDS einen Eintrag ähnlich wie folgenden in die Protokolldatei.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

Festlegen der Parameter, die den gemeinsam genutzten Speicher steuern

Die von Ihnen festgelegten Parameter bestimmen die Größe des gemeinsam genutzten Speichers für die Nachverfolgung von Transaktionen IDs, Sperren und vorbereiteten Transaktionen. Die Struktur des gemeinsam genutzten Speichers einer Standby-Instance muss der einer primären Instance entsprechen oder größer sein. Dadurch wird sichergestellt, dass der gemeinsam genutzte Speicher der Ersteren während der Wiederherstellung nicht knapp wird. Wenn die Parameterwerte des Replikats niedriger sind als die Parameterwerte der primären Instance, passt Amazon RDS die Replikatparameter automatisch an und startet die Engine neu.

Die betroffenen Parameter sind:

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Um RDS-Neustarts von Replikaten aufgrund von unzureichendem Speicher zu vermeiden, empfehlen wir, die Parameteränderungen in Form eines fortlaufenden Neustarts auf jedes Replikat anzuwenden. Sie müssen die folgenden Regeln anwenden, wenn Sie die Parameter festlegen:

  • Erhöhen der Parameterwerte:

    • Sie sollten immer zuerst die Parameterwerte aller Lesereplikate erhöhen und einen fortlaufenden Neustart aller Replikate durchführen. Wenden Sie dann die Parameteränderungen auf die primäre Instance an und führen Sie dann einen Neustart aus.

  • Verringern der Parameterwerte:

    • Sie sollten zuerst die Parameterwerte der primären Instance verringern und einen Neustart durchführen. Wenden Sie dann die Parameteränderungen auf alle zugehörigen Lesereplikate an und führen Sie einen fortlaufenden Neustart durch.