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. # Arbeiten mit Read Replicas in Amazon RDS für PostgreSQL Sie können Lesevorgänge für Ihre DB-Instances von Amazon RDS für PostgreSQL skalieren, indem Sie den Instances Lesereplikate hinzufügen. Wie bei anderen Datenbank-Engines von Amazon RDS verwendet RDS für PostgreSQL die nativen Replikationsmechanismen von PostgreSQL, um Lesereplikate im Hinblick auf Änderungen an der Quell-DB auf dem neuesten Stand zu halten. Allgemeine Informationen zu Lesereplikaten und Amazon RDS finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten in RDS für PostgreSQL. ## Read Replica-Beschränkungen unter PostgreSQL Für PostgreSQL-Lesereplikate gelten folgende Beschränkungen: + PostgreSQL-Lesereplikate sind schreibgeschützt. Auch wenn ein Lesereplikat keine beschreibbare DB-Instance ist, können Sie es zu einer eigenständigen RDS-for-PostgreSQL-DB-Instance hochstufen. Der Prozess kann jedoch nicht rückgängig gemacht werden. + Sie können kein Lesereplikat aus einem anderen Lesereplikat erstellen, falls auf Ihrer RDS-for-PostgreSQL-DB-Instance eine frühere PostgreSQL-DB-Version als 14.1 ausgeführt wird. RDS für PostgreSQL unterstützt kaskadierende Lesereplikate nur in RDS für PostgreSQL Version 14.1 und höher. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). + Wenn Sie ein PostgreSQL-Lesereplikat hochstufen, wird es zu einer beschreibbaren DB-Instance. Es empfängt keine Write-Ahead Log (WAL)-Dateien von einer DB-Quell-Instance mehr und ist keine schreibgeschützte Instance mehr. Sie können neue Lesereplikate aus der hochgestuften DB-Instance erstellen wie für jede andere RDS-for-PostgreSQL-DB-Instance. Weitere Informationen finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md). + Wenn Sie ein PostgreSQL-Lesereplikat aus einer Replikationskette (eine Reihe kaskadierender Lesereplikate) heraus hochstufen, erhalten alle vorhandenen Downstream-Lesereplikate weiterhin automatisch WAL-Dateien von der hochgestuften Instance. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). + Wenn keine Benutzertransaktionen auf der Quell-DB-Instance laufen, meldet das zugehörige PostgreSQL-Lesereplikat eine Replikationsverzögerung von bis zu fünf Minuten. Die Replikatverzögerung wird berechnet als `currentTime - lastCommitedTransactionTimestamp`, was bedeutet, dass, wenn keine Transaktionen verarbeitet werden, der Wert der Replikatverzögerung für einen bestimmten Zeitraum steigt, bis das Write-Ahead-Log (WAL)-Segment wechselt. Standardmäßig wechselt RDS für PostgreSQL das WAL-Segment alle 5 Minuten, was zu einem Transaktionsdatensatz und einer Verringerung der gemeldeten Verzögerung führt. + Sie können keine automatisierten Backups für PostgreSQL-Lesereplikate für RDS für PostgreSQL Versionen vor 14.1 aktivieren. Automatisierte Backups für Lesereplikate werden nur für RDS für PostgreSQL 14.1 und höhere Versionen unterstützt. Erstellen Sie für RDS für PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen. + Point-in-time Recovery (PITR) wird für Read Replicas nicht unterstützt. Sie können PITR nur mit einer primären (Writer-) Instance und nicht mit einem Lesereplikat verwenden. Weitere Informationen hierzu finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md). + Lesereplikate für PostgreSQL-Version 12 und niedriger werden während des 60–90-tägigen Wartungsfensters automatisch neu gestartet, um die Passwortrotation anzuwenden. Wenn das Replikat vor dem geplanten Neustart die Verbindung zur Quelle verliert, wird es trotzdem neu gestartet, um die Replikation fortzusetzen. Bei PostgreSQL-Version 13 und höher kann es bei Lesereplikaten während der Passwortrotation zu kurzen Unterbrechungen und erneuten Verbindungen bei der Replikation kommen. # Konfiguration von Read Replicas mit PostgreSQL RDS for 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 Replikation der Quell-DB-Instance. Sie wird von einer speziellen Verbindung erstellt, die Write-Ahead Log (WAL)-Daten zwischen der Quell-DB-Instance und dem Lesereplikat übermittelt. Weitere Informationen finden Sie unter [Streaming-Replikation](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) in der PostgreSQL-Dokumentation. PostgreSQL streamt Datenbankänderungen asynchron über diese sichere Verbindung, während sie auf der Quell-DB-Instance vorgenommen werden. Sie können die Kommunikation von Ihren Clientanwendungen zur Quell-DB-Instance oder zu allen Lesereplikaten verschlüsseln, indem Sie den Parameter `ssl` auf `1` festlegen. Weitere Informationen finden Sie unter [Verwenden von SSL mit einer PostgreSQL-DB-Instance](PostgreSQL.Concepts.General.SSL.md). PostgreSQL verwendet eine *Replikations*-Rolle, um die Streaming-Replikation durchzuführen. Die Rolle besitzt Berechtigungen, kann jedoch nicht für das Ändern von Daten verwendet werden. PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation. Sie können ein PostgreSQL-Lesereplikat erstellen, ohne den Betrieb oder die Benutzer der Quell-DB-Instance zu beeinträchtigen. Amazon RDS legt die erforderlichen Parameter und Berechtigungen für die Quell-DB-Instance und das Lesereplikat ohne Auswirkungen auf den Service fest. Ein Snapshot von der Quell-DB-Instance wird erstellt und zum Erstellen des Lesereplikats verwendet. Wenn Sie das Lesereplikat irgendwann in der Zukunft löschen, tritt kein Ausfall auf. Sie können bis zu 15 Lesereplikate von einer Quell-DB-Instance innerhalb derselben Region erstellen. Ab RDS for PostgreSQL 14.1 können Sie auch bis zu drei Ebenen von Lesereplikaten in einer Kette (Kaskade) aus einer Quell-DB-Instance erstellen. Weitere Informationen finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). In allen Fällen müssen für die Quell-DB-Instance automatisierte Backups konfiguriert sein. Dazu legen Sie den Aufbewahrungszeitraum für Sicherungen in Ihrer DB-Instance auf einen anderen Wert als 0 fest. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md). Sie können Lesereplikate für Ihre DB-Instance von RDS for PostgreSQL in derselben AWS-Region wie Ihre Quell-DB-Instance erstellen. Dies wird als *regionale* Replikation bezeichnet. Sie können Read Replicas auch in einer anderen AWS-Regionen als der Quell-DB-Instance erstellen. Dies wird als *regionsübergreifende* Replikation bezeichnet. Weitere Informationen zum Einrichten von regionsübergreifenden Lesereplikaten finden Sie unter [Erstellen einer Read Replica in einem anderen AWS-Region](USER_ReadRepl.XRgn.md). Die verschiedenen Mechanismen, die den Prozess für die regionale und regionsübergreifende Replikation unterstützen, unterscheiden sich je nach RDS-for-PostgreSQL-Version geringfügig, wie in [Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md) erläutert. Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über die selbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie unbedingt auch die Lesereplikate. Amazon RDS überschreibt alle nicht-kompatiblen Parameter in einem Lesereplikat, wenn diese das Lesereplikat vom Hochfahren abhalten. Nehmen Sie beispielsweise an, dass der Wert des Parameters `max_connections` auf der Quell-DB-Instance höher als auf dem Lesereplikat ist. In diesem Fall aktualisiert Amazon RDS den Parameter auf dem Lesereplikat, sodass er denselben Wert wie auf der Quell-DB-Instance hat. Read Replicas von RDS for PostgreSQL haben Zugriff auf externe Datenbanken, die über Foreign Data Wrappers (FDWs) auf der Quell-DB-Instance verfügbar sind. Angenommen, Ihre RDS-for-PostgreSQL-DB-Instance verwendet den Wrapper `mysql_fdw` für den Zugriff auf Daten von RDS for MySQL. In diesem Fall können Ihre Lesereplikate auch auf diese Daten zugreifen. Zu den weiteren unterstützten FDWs gehören, und. `oracle_fdw` `postgres_fdw` `tds_fdw` Weitere Informationen finden Sie unter [Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md). ## Verwenden von RDS-for-PostgreSQL-Lesereplikate mit Multi-AZ-Konfigurationen Sie können ein Lesereplikat aus einer Single-AZ- oder Multi-AZ-DB-Instance erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten mit einem Standby-Replikat zu verbessern. Ein *Standby-Replikat* ist ein dediziertes Lesereplikat, das die Workload übernehmen kann, wenn die Quell-DB ausfällt. Sie können Ihr Standby-Replikat nicht dazu verwenden, Leseverkehr bereitzustellen. Sie können jedoch Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie unter [Bereitstellungen von Multi-AZ-DB-Instances für Amazon RDS](Concepts.MultiAZSingleStandby.md). Wenn die Quell-DB-Instance einer Multi-AZ-Bereitstellung ein Failover auf eine Standby-Instance vornimmt, wechseln die zugehörigen Lesereplikate zur Verwendung der Standby-Instance (jetzt primär) als Replikationsquelle. Die Lesereplikate müssen möglicherweise je nach RDS-for-PostgreSQL-Version wie folgt neu gestartet werden: + **PostgreSQL 13 und höhere Versionen** – Ein Neustart ist nicht erforderlich. Die Lesereplikate werden automatisch mit der neuen Primär-Instance synchronisiert. In einigen Fällen legt Ihre Clientanwendung jedoch die Details des Domain Name Service (DNS) für Ihre Lesereplikate im Zwischenspeicher ab. Falls ja, setzen Sie den Wert time-to-live (TTL) auf weniger als 30 Sekunden. Damit wird verhindert, dass das Lesereplikat eine veraltete IP-Adresse beibehält (wodurch verhindert wird, dass es mit der neuen Primär-Instance synchronisiert wird). Weitere Informationen über diese und andere bewährte Methoden finden Sie unter [Grundlegende Anleitungen für den Amazon-RDS-Betrieb](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance). + **PostgreSQL 12 und alle früheren Versionen** – Die Lesereplikate werden nach einem Failover auf das Standby-Replikat automatisch neu gestartet, da der Standby (jetzt primär) eine andere IP-Adresse und einen anderen Instance-Namen hat. Durch den Neustart wird das Lesereplikat mit der neuen Primär-Instance synchronisiert. Weitere Informationen zu Failover finden Sie unter [Failover einer Multi-AZ-DB-Instance für Amazon RDS](Concepts.MultiAZ.Failover.md). Weitere Informationen dazu, wie Lesereplikate in einer Multi-AZ-Bereitstellung funktionieren, finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Wenn Sie Failover-Unterstützung für ein Lesereplikat bereitstellen möchten, können Sie ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt dann eine Standby-Version des Replikats in einer anderen Availability Zone. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist. # Logische Dekodierung auf einem Lesereplikat RDS für PostgreSQL unterstützt die logische Replikation aus Standbys mit PostgreSQL 16.1. Auf diese Weise können Sie eine logische Dekodierung aus einem schreibgeschützten Standby erstellen, wodurch die Last für die primäre DB-Instance reduziert wird. Sie können eine höhere Verfügbarkeit für Ihre Anwendungen erreichen, die Daten zwischen mehreren Systemen synchronisieren müssen. Dieses Feature steigert die Leistung Ihres Data Warehouse und Ihrer Datenanalyse. Außerdem sorgen Replikationsslots in einem bestimmten Standby dafür, dass dieses Standby zur primären Instance hochgestuft wird. Das bedeutet, dass im Falle eines Failovers einer primären DB-Instance oder der Hochstufung einer Standby-Instance zur neuen primären Instance die Replikationsslots bestehen bleiben und die ehemaligen Standby-Subscriber davon nicht betroffen sind. **So erstellen Sie eine logische Dekodierung auf einem Lesereplikat** 1. **Logische Replikation aktivieren** – Um eine logische Dekodierung auf einem Standby zu erstellen, müssen Sie die logische Replikation auf Ihrer Quell-DB-Instance und deren physischem Replikat aktivieren. Weitere Informationen finden Sie unter [Konfiguration von Read Replicas mit PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md). + **So aktivieren Sie die logische Replikation für eine neu erstellte DB-Instance von RDS für PostgreSQL** – Erstellen Sie eine neue benutzerdefinierte DB-Parametergruppe und legen Sie den statischen Parameter `rds.logical_replication` auf `1` fest. Ordnen Sie dann diese DB-Parametergruppe der Quell-DB-Instance und ihrem physischen Lesereplikat zu. Weitere Informationen finden Sie unter [Verknüpfen einer DB-Parametergruppe mit einer DB-Instance in Amazon RDS](USER_WorkingWithParamGroups.Associating.md). + **So aktivieren Sie die logische Replikation für eine bestehende DB-Instance von RDS für PostgreSQL** – Ändern Sie die benutzerdefinierte DB-Parametergruppe der Quell-DB-Instance und ihres physischen Lesereplikats, um den statischen Parameter `rds.logical_replication` auf `1` festzulegen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **Anmerkung** Sie müssen die DB-Instances neu starten, um diese Parameteränderungen anzuwenden. Sie können die folgende Abfrage verwenden, um die Werte für `wal_level` und `rds.logical_replication` auf der Quell-DB-Instance und ihrem physischen Lesereplikat zu überprüfen. ``` Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication'); name | setting -------------------------+--------- rds.logical_replication | on wal_level | logical (2 rows) ``` 1. **Tabelle in der Quelldatenbank erstellen** – Stellen Sie in Ihrer Quell-DB-Instance eine Verbindung zur Datenbank her. Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird](USER_ConnectToPostgreSQLInstance.md). Verwenden Sie die folgenden Abfragen, um eine Tabelle in Ihrer Quelldatenbank zu erstellen und Werte einzufügen: ``` Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY); CREATE TABLE ``` ``` Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000)); INSERT 0 10000 ``` 1. **Publikation für die Quelltabelle erstellen** – Verwenden Sie die folgende Abfrage, um eine Publikation für die Tabelle in der Quell-DB-Instance zu erstellen. ``` Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test; CREATE PUBLICATION ``` Verwenden Sie eine SELECT-Abfrage, um die Details der Publikation zu überprüfen, die sowohl auf der Quell-DB-Instance als auch auf der physischen Lesereplikat-Instance erstellt wurde. ``` Postgres=>SELECT * from pg_publication; oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot -------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------ 16429 | testpub | 16413 | f | t | t | t | t | f (1 row) ``` 1. **Abonnement aus einer logischen Replikat-Instance erstellen** – Erstellen Sie eine weitere DB-Instance von RDS für PostgreSQL als logische Replikat-Instance. Stellen Sie sicher, dass die VPC richtig eingerichtet ist, damit diese logische Replikat-Instance auf die physische Lesereplikat-Instance zugreifen kann. Weitere Informationen finden Sie unter [Amazon VPC und Amazon RDS](USER_VPC.md). Wenn Ihre Quell-DB-Instance inaktiv ist, können Verbindungsprobleme auftreten, und die primäre DB-Instance sendet die Daten nicht in die Standby-Instance. ``` Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port dbname=source_db_name user=user password=password' PUBLICATION testpub; NOTICE: created replication slot "testsub" on publisher CREATE SUBSCRIPTION ``` ``` Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY); CREATE TABLE ``` Verwenden Sie eine SELECT-Abfrage, um die Details des Abonnements auf der logischen Replikat-Instance zu überprüfen. ``` Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription; oid | subname | subenabled | subslotname | subpublications -------+---------+------------+-------------+----------------- 16429 | testsub | t | testsub | {testpub} (1 row) postgres=> select count(*) from LR_test; count ------- 10000 (1 row) ``` 1. **Status des logischen Replikationsslots überprüfen** – Sie können den physischen Replikationsslot nur auf Ihrer Quell-DB-Instance sehen. ``` Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn ---------------------------------------------+-----------+--------------------- rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical | (1 row) ``` Auf Ihrer Lesereplikat-Instance können Sie jedoch den logische Replikationsslot und die Änderungen am Wert `confirmed_flush_lsn` sehen, wenn die Anwendung aktiv logische Änderungen verarbeitet. ``` Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn -----------+-----------+--------------------- testsub | logical | 0/500002F0 (1 row) ``` ``` Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots; slot_name | slot_type | confirmed_flush_lsn -----------+-----------+--------------------- testsub | logical | 0/5413F5C0 (1 row) ``` # Verwendung von kaskadierenden Lesereplikaten mit RDS für PostgreSQL Ab Version 14.1 unterstützt RDS für PostgreSQL kaskadierende Lesereplikate. Mit *kaskadierenden Lesereplikaten* können Sie Lesereplikate skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für PostgreSQL verursachen. Aktualisierungen des WAL-Protokolls werden von der Quell-DB-Instance nicht an jedes Lesereplikat gesendet. Stattdessen sendet jedes Lesereplikat Replica einer kaskadierenden Serie WAL-Log-Updates an das nächste Lesereplikat in der Reihe. Damit wird die Belastung der Quell-DB-Instance reduziert. Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für PostgreSQL WAL-Daten an das erste Lesereplikat in der Kette. Dieses Lesereplikat sendet dann WAL-Daten an das zweite Replikat in der Kette usw. Das Endergebnis ist, dass alle Lesereplikate in der Kette die Änderungen von der DB-Instance von RDS für PostgreSQL aufweisen, jedoch ohne Overhead ausschließlich auf der Quell-DB-Instance zu verursachen. Sie können eine Reihe von bis zu drei Lesereplikaten in einer Kette von einer Quell-DB-Instance von RDS für PostgreSQL erstellen. Angenommen, Sie haben eine DB-Instance von RDS for PostgreSQL 14.1, `rpg-db-main`. Sie haben die folgenden Möglichkeiten: + Beginnend mit `rpg-db-main` erstellen Sie das erste Lesereplikat in der Kette `read-replica-1`. + Als Nächstes erstellen Sie ab `read-replica-1` das nächste Lesereplikat in der Kette `read-replica-2`. + Schließlich erstellen Sie ab `read-replica-2` das nächste Lesereplikat in der Kette `read-replica-3`. Sie können kein weiteres Lesereplikat über dieses dritte kaskadierende Lesereplikat hinaus in der Reihe für `rpg-db-main` erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für PostgreSQL bis zum Ende einer Reihe kaskadierender Lesereplikate kann aus höchstens vier DB-Instances bestehen. Damit die Kaskadierung von Lesereplikaten funktioniert, aktivieren Sie automatische Backups auf Ihrem RDS für PostgreSQL. Erstellen Sie zuerst das Lesereplikat und aktivieren Sie dann automatische Backups auf der DB-Instance von RDS für PostgreSQL. Der Prozess ist der gleiche wie bei anderen Amazon-RDS-DB-Engines. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md). Wie bei jedem Lesereplikat können Sie ein Lesereplikat, das Teil einer Kaskade ist, hochstufen. Wenn Sie ein Lesereplikat aus einer Kette von Lesereplikaten hochstufen, wird dieses Replikat aus der Kette entfernt. Angenommen, Sie möchten einen Teil der Workload von Ihrer `rpg-db-main`-DB-Instance zu einer neuen Instance verschieben, die nur von der Buchhaltung verwendet wird. Ausgehend von der Kette von drei Lesereplikaten aus dem Beispiel entscheiden Sie sich, `read-replica-2` hochzustufen. Die Kette ist wie folgt betroffen: + Durch Hochstufen von `read-replica-2` wird es aus der Replikationskette entfernt. + Es ist jetzt eine vollständige read/write DB-Instance. + Die Replizierung auf `read-replica-3` wird fortgesetzt wie vor der Hochstufung. + Ihre `rpg-db-main` setzt die Replizierung auf `read-replica-1` fort. Weitere Informationen über das Hochstufen von Lesereplikaten finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md). **Anmerkung** RDS für PostgreSQL unterstützt keine Hauptversions-Upgrades für kaskadierende Replikate. Bevor Sie ein Hauptversions-Upgrade durchführen, müssen Sie kaskadierende Replikate entfernen. Sie können sie nach Abschluss des Upgrades auf Ihrer Quell-DB-Instance und den Replikaten der ersten Ebene neu erstellen. Für kaskadierende Lesereplikate unterstützt RDS für PostgreSQL 15 Lesereplikate für jede Quell-DB-Instance auf der ersten Replikationsebene und 5 Lesereplikate für jede Quell-DB-Instance auf der zweiten und dritten Replikationsebene. # Erstellen regionsübergreifender kaskadierender Lesereplikate mit RDS für PostgreSQL RDS für PostgreSQL unterstützt regionsübergreifende kaskadierende Lesereplikate. Sie können ein regionsübergreifendes Replikat aus der Quell-DB-Instance erstellen und dann daraus Replikate derselben Region generieren. Sie können auch ein Replikat derselben Region aus der Quell-DB-Instance erstellen und dann daraus regionsübergreifende Replikate erzeugen. **Erstellen eines regionsübergreifenden Replikats und anschließendes Erstellen eines Replikats derselben Region** Sie können eine DB-Instance von RDS für PostgreSQL mit Version 14.1 oder höher verwenden, `rpg-db-main`, um folgende Vorgänge durchzuführen: 1. Beginnen Sie mit `rpg-db-main` (USA-OST-1) und erstellen Sie das erste regionsübergreifende Lesereplikat in der Kette, `read-replica-1` (USA-WEST-2). 1. Verwenden Sie das erste regionsübergreifende `read-replica-1` (USA-WEST-2) und erstellen Sie das zweite Lesereplikat in der Kette, `read-replica-2` (USA-WEST-2). 1. Verwenden Sie `read-replica-2` und erstellen Sie das dritte Lesereplikat in der Kette, `read-replica-3` (USA-WEST-2). **Erstellen eines Replikats derselben Region und anschließendes Erstellen eines regionsübergreifenden Replikats** Sie können eine DB-Instance von RDS für PostgreSQL mit Version 14.1 oder höher verwenden, `rpg-db-main`, um folgende Vorgänge durchzuführen: 1. Beginnen Sie mit `rpg-db-main` (USA-OST-1) und erstellen Sie das erste Lesereplikat in der Kette, `read-replica-1` (USA-OST-1). 1. Verwenden Sie `read-replica-1` (USA-OST-1) und erstellen Sie das erste regionsübergreifende Lesereplikat in der Kette, `read-replica-2` (USA-WEST-2). 1. Verwenden Sie `read-replica-2` (USA-WEST-2) und erstellen Sie das dritte Lesereplikat in der Kette, `read-replica-3` (USA-WEST-2). **Einschränkungen bei der Erstellung regionsübergreifender Lesereplikate** + Eine regionsübergreifende kaskadierende Kette von Datenbankreplikaten kann sich über maximal zwei Regionen mit maximal vier Ebenen erstrecken. Die vier Ebenen umfassen die Datenbankquelle und drei Lesereplikate. **Vorteile der Verwendung von kaskadierenden Lesereplikaten** + Verbesserte Leseskalierbarkeit: Durch die Verteilung von Leseabfragen auf mehrere Replikate trägt die kaskadierende Replikation zum Lastenausgleich bei. Dies verbessert die Leistung, insbesondere bei leseintensiven Anwendungen, indem die Belastung der Writer-Datenbank verringert wird. + Geografische Verteilung: Kaskadierende Replikate können sich an verschiedenen geografischen Standorten befinden. Dies reduziert die Latenz für Benutzer, die sich weit von der Primärdatenbank entfernt befinden, und bietet ein lokales Lesereplikat, was die Leistung und das Benutzererlebnis verbessert. + Hochverfügbarkeit und Notfallwiederherstellung: Im Falle eines Ausfalls des primären Servers können Replikate zu primären Servern hochgestuft werden, wodurch die Kontinuität gewährleistet ist. Durch die kaskadierende Replikation wird dies noch weiter verbessert, indem mehrere Ebenen von Failover-Optionen bereitgestellt werden, wodurch sich die allgemeine Ausfallsicherheit des Systems verbessert. + Flexibilität und modulares Wachstum: Wenn das System wächst, können neue Replikate auf verschiedenen Ebenen hinzugefügt werden, ohne dass die Primärdatenbank umfassend neu konfiguriert werden muss. Dieser modulare Ansatz ermöglicht ein skalierbares und verwaltbares Wachstum der Replikationseinrichtung. **Bewährte Methode für die Verwendung regionsübergreifender Lesereplikate** + Bevor Sie ein Replikat hochstufen, erstellen Sie zusätzliche Replikate. Das spart Zeit und ermöglicht eine effiziente Bewältigung der Workload. # Funktionsweise der Streaming-Replikation für verschiedene RDS-for-PostgreSQL-Versionen Wie in [Konfiguration von Read Replicas mit PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md) 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 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | | PostgreSQL 13 und niedrigere Versionen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | Weitere Informationen finden Sie unter [Überwachen und Optimieren des Replikationsprozesses](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md). ## 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\$1wal\$1senders** 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\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) der PostgreSQL-Dokumentation. `max_wal_senders` ist ein statischer Parameter, der einen Neustart der DB-Instance erfordert, damit die Änderungen wirksam werden. **wal\$1keep\$1segments** 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 ReplikationsunterbrechungenBeispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen](#USER_PostgreSQL.Replication.example-how-it-works) in Aktion sehen, wie er vom PostgreSQL-Protokoll erfasst wurde. 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\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) und [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) in der PostgreSQL-Dokumentation. **max\$1slot\$1wal\$1keep\$1size** 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](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots). Weitere Informationen zu diesem Parameter finden Sie unter [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-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\$1connections + max\$1worker\$1processes + max\$1wal\$1senders + max\$1prepared\$1transactions + max\$1locks\$1per\$1transaction 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. # Überwachen und Optimieren des Replikationsprozesses Wir empfehlen dringend, Ihre RDS-for-PostgreSQL-DB-Instance und Lesereplikate routinemäßig zu überwachen. Sie müssen sicherstellen, dass Ihre Lesereplikate mit den Änderungen an der Quell-DB-Instance Schritt halten. Amazon RDS stellt Ihre Lesereplikate transparent wieder her, wenn Unterbrechungen des Replikationsprozesses auftreten. Es ist jedoch am besten, wenn keine Wiederherstellung erforderlich ist. Die Wiederherstellung mit Replikationsslots ist schneller als die Verwendung des Amazon-S3-Archivs, aber jeder Wiederherstellungsprozess kann die Leseleistung beeinträchtigen. Um festzustellen, wie gut Ihre Lesereplikate mit der Quell-DB-Instance Schritt halten, können Sie folgende Schritte ausführen: + **Prüfen Sie den Wert für `ReplicaLag` zwischen Quell-DB-Instance und Replikaten.** *Replikatverzögerung* ist die Zeit in Sekunden, die ein Lesereplikat hinter seiner Quell-DB-Instance zurückbleibt. Diese Metrik gibt das Ergebnis der folgenden Abfrage zurück. ``` SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag"; ``` Die Replikatverzögerung ist ein Hinweis darauf, wie gut ein Lesereplikat mit der Quell-DB-Instance Schritt hält. Dies ist die Latenz zwischen der Quell-DB-Instance und einem bestimmten Lesereplikat. Ein hoher Wert für die Replikatverzögerung kann auf eine Nichtübereinstimmung zwischen den DB-Instance-Klassen oder Speichertypen (oder beiden) hinweisen, die von der Quell-DB-Instance und ihren Lesereplikaten verwendet werden. Die DB-Instance-Klasse und die Speichertypen für die DB-Quellinstance und alle Lesereplikate sollten identisch sein. Replikatverzögerung kann auch das Ergebnis intermittierender Verbindungsprobleme sein. Sie können die Replikationsverzögerung in Amazon überwachen, CloudWatch indem Sie sich die Amazon `ReplicaLag` RDS-Metrik ansehen. Für weitere Informationen über `ReplicaLag` und andere Metriken für Amazon RDS finden Sie unter [CloudWatch Amazon-Metriken für Amazon RDS](rds-metrics.md). + **Im PostgreSQL-Protokoll finden Sie Informationen, mit denen Sie Ihre Einstellungen anpassen können.** Das PostgreSQL-Protokoll erfasst an jedem Checkpoint die Anzahl der recycelten Transaktionsprotokolldateien, wie im folgenden Beispiel gezeigt. ``` 2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s; sync files=10, longest=0.013 s, average=0.001 s ``` Sie können diese Informationen verwenden, um herauszufinden, wie viele Transaktionsdateien in einem bestimmten Zeitraum recycelt werden. Sie können die Einstellung für `wal_keep_segments` bei Bedarf ändern. Angenommen, das PostgreSQL-Protokoll zeigt bei `checkpoint complete` für ein 5-Minuten-Intervall `35 recycled` an. In diesem Fall reicht der `wal_keep_segments`-Standardwert 32 nicht aus, um mit der Streaming-Aktivität Schritt zu halten, und wir empfehlen Ihnen, den Wert dieses Parameters zu erhöhen. + **Verwenden Sie Amazon CloudWatch , um Metriken zu überwachen, mit denen Replikationsprobleme vorhergesagt werden können.** Anstatt das PostgreSQL-Protokoll direkt zu analysieren, können Sie Amazon verwenden, CloudWatch um die gesammelten Metriken zu überprüfen. Sie können beispielsweise den Wert der Metrik `TransactionLogsGeneration` überprüfen, um zu sehen, wie viele WAL-Daten von der Quell-DB-Instance generiert werden. In einigen Fällen kann die Worklaod Ihrer DB-Instance WAL-Daten in großer Menge erzeugen. In diesem Fall müssen Sie möglicherweise die DB-Instance-Klasse für Ihre Quell-DB-Instance und Lesereplikate ändern. Die Verwendung einer Instance-Klasse mit hoher Netzwerkleistung (10 Gbit/s) kann die Verzögerung von Replikaten verringern. ## Überwachen von Replikationsslots für Ihre RDS-for-PostgreSQL-DB-Instance Alle Versionen von RDS für PostgreSQL verwenden Replikationsslots für regionsübergreifende Lesereplikate. RDS für PostgreSQL 14.1 und höhere Versionen verwenden Replikationsslots für regionale Lesereplikate. Regionale Lesereplikate nutzen Amazon S3 auch dazu, WAL-Daten zu archivieren. Mit anderen Worten, wenn Ihre DB-Instance und Lesereplikate PostgreSQL 14.1 oder höher ausführen, stehen sowohl Replikationsslots als auch Amazon-S3-Archive für die Wiederherstellung des Lesereplikats zur Verfügung. Die Wiederherstellung eines Lesereplikats Replica mit seinem Replikationsslots ist schneller als die Wiederherstellung aus dem Amazon-S3-Archiv. Wir empfehlen daher, die Replikationsslots und zugehörige Metriken zu überwachen. Sie können die Replikationsslots auf Ihren RDS-for-PostgreSQL-DB-Instances anzeigen, indem Sie die Ansicht `pg_replication_slots` wie folgt abfragen. ``` postgres=> SELECT * FROM pg_replication_slots; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase ---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+----------- rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f (1 row) ``` Der `wal_status` `reserved` bedeutet, dass die Menge der vom Slot gespeicherten WAL-Daten innerhalb der Grenzen des Parameters `max_wal_size` liegt. Mit anderen Worten: Der Replikationsslots ist angemessen dimensioniert. Folgende Statuswerte sind außerdem möglich: + `extended` – Der Slot überschreitet die Einstellung `max_wal_size`, die WAL-Daten werden jedoch beibehalten. + `unreserved` – Der Slot verfügt nicht mehr über alle erforderlichen WAL-Daten. Ein Teil davon wird am nächsten Checkpoint entfernt. + `lost` – Einige erforderliche WAL-Daten wurden entfernt. Der Slot ist nicht mehr nutzbar. Die Status `unreserved` und `lost` von `wal_status` werden nur angezeigt, wenn `max_slot_wal_keep_size` nicht negativ ist. Die Ansicht `pg_replication_slots` zeigt Ihnen den aktuellen Status Ihrer Replikationsslots an. Um die Leistung Ihrer Replikationsslots zu bewerten, können Sie Amazon verwenden CloudWatch und die folgenden Metriken überwachen: + **`OldestReplicationSlotLag`** – Zeigt die Menge an Daten für das Write-Ahead-Protokoll (WAL) auf der Quelle an, die nicht vom Replikat mit der größten Verzögerung verbraucht wurde. + **`TransactionLogsDiskUsage`** – Zeigt an, wie viel Speicher für WAL-Daten verwendet wird. Wenn ein Lesereplikat erheblich zurückbleibt, kann der Wert dieser Metrik erheblich steigen. Weitere Informationen zur Verwendung von Amazon CloudWatch und seinen Metriken für RDS for PostgreSQL finden Sie unter. [Überwachung von Amazon RDS mit Amazon CloudWatch](monitoring-cloudwatch.md) Weitere Informationen zur Überwachung des Streamings der Replikation auf Ihren RDS-for-PostgreSQL-DB-Instances finden Sie unter [Bewährte Methoden für die Amazon-RDS-PostgreSQL-Replikation](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) im *AWS -Datenbank-Blog*. # Konfigurieren der verzögerten Replikation mit RDS für PostgreSQL ## Übersicht und Vorteile Mit der verzögerten Replikation in RDS für PostgreSQL können Sie die Replikation von Datenänderungen von der Primärdatenbank auf einen oder mehrere Standby-Server (Lesereplikate) absichtlich verzögern. Dies bietet wertvollen Schutz vor beschädigten Daten, versehentlichem Datenverlust und fehlerhaften Transaktionen, die andernfalls sofort auf alle Replikate übertragen werden könnten. Die verzögerte Replikation wird für die folgenden Versionen von RDS für PostgreSQL unterstützt: + 14.19 und höhere 14-Versionen + 15.14 und höhere 15-Versionen + 16.10 und höhere 16 Versionen + 17.6 und höhere 17-Versionen Durch die Einführung einer Zeitverzögerung beim Replikationsprozess erhalten Sie die Möglichkeit, datenbezogene Vorfälle zu erkennen und darauf zu reagieren, bevor sie sich auf Ihren gesamten DB-Cluster auswirken. Hauptvorteile der verzögerten Replikation: + Ermöglicht die Wiederherstellung nach versehentlichen Löschvorgängen, Aktualisierungen oder anderen logischen Fehlern. + Bietet einen Puffer gegen die Ausbreitung beschädigter Daten im DB-Cluster. + Bietet einen möglichen zusätzlichen Wiederherstellungspunkt als Ergänzung zu herkömmlichen Backup-Strategien. + Ermöglicht es Ihnen, den Verzögerungszeitraum anhand der spezifischen Anforderungen und der Risikotoleranz Ihres Unternehmens zu konfigurieren. ## Aktivieren und Konfigurieren der verzögerten Replikation Führen Sie diese Schritte aus, um die verzögerte Replikation auf einem Lesereplikat von RDS für PostgreSQL zu aktivieren: **Anmerkung** Verwenden Sie für kaskadierte Lesereplikate denselben Parameter `recovery_min_apply_delay` und führen Sie die unten beschriebenen Schritte aus. **So aktivieren Sie die verzögerte Replikation** 1. Erstellen Sie eine neue benutzerdefinierte Parametergruppe oder ändern Sie eine vorhandene Parametergruppe. Weitere Informationen finden Sie unter [DB-Parametergruppen für DB-Instances von Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md). 1. Konfigurieren Sie den Parameter `recovery_min_apply_delay` in der Parametergruppe: + Legen Sie den Wert auf die gewünschte Verzögerung in Millisekunden fest. Zum Beispiel 3 600 000 für eine Verzögerung von 1 Stunde. + Zulässiger Bereich: 0 bis 86 400 000 ms (0 bis 24 Stunden) + Standard: 0 1. Wenden Sie die Parametergruppe auf die Lesereplikat-Instance an, die Sie für die verzögerte Replikation konfigurieren möchten. 1. Starten Sie die Lesereplikat-Instance neu, damit die Änderungen wirksam werden. **Anmerkung** Der `recovery_min_apply_delay`-Parameter ist dynamisch. Wenn Sie eine vorhandene Parametergruppe ändern, die bereits mit der Instance verknüpft ist, werden die Änderungen sofort wirksam, ohne dass ein Neustart erforderlich ist. Wenn Sie jedoch eine neue Parametergruppe auf die Instance anwenden, müssen Sie einen Neustart vornehmen, damit die Änderungen wirksam werden. ## Verwalten der Wiederherstellung von verzögerten Replikationen Eine verzögerte Replikation ist besonders nützlich in Szenarien, in denen herkömmliche point-in-time Wiederherstellungsmethoden möglicherweise unzureichend oder zu zeitaufwändig sind. Während des Zeitraums der verzögerten Replikation können Sie die folgenden PostgreSQL-Funktionen zum Verwalten des Wiederherstellungsprozesses verwenden: + `pg_wal_replay_pause()`: Fordert die Unterbrechung des Wiederherstellungsprozesses für das verzögerte Replikat an. + `pg_wal_replay_resume()`: Startet den Wiederherstellungsprozess neu, sofern er zuvor unterbrochen wurde. + `pg_is_wal_replay_paused()`: Überprüft, ob der Wiederherstellungsprozess derzeit unterbrochen ist. + `pg_get_wal_replay_pause_state()`: Ruft den aktuellen Status des Wiederherstellungsprozesses ab (nicht unterbrochen, Unterbrechung angefordert oder unterbrochen). Benutzer mit der Rolle `rds_superuser` haben EXECUTE-Berechtigungen für `pg_wal_replay_pause()` und `pg_wal_replay_resume()`. Wenn andere Datenbankbenutzer Zugriff auf diese Funktionen benötigen, müssen Sie ihnen die Rolle `rds_superuser` gewähren. Weitere Informationen zur `rds_superuser`-Rolle finden Sie unter [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md). Für den Zugriff auf andere Funktionen wie `pg_is_wal_replay_paused()` und `pg_get_wal_replay_pause_state()` ist die Rolle `rds_superuser` nicht erforderlich. Sie können die folgenden Wiederherstellungszielparameter verwenden, um den Zeitpunkt, bis zu dem das verzögerte Replikat wiederhergestellt wird, genau zu steuern. Diese Parameter sind statisch und erfordern einen Neustart der Datenbank, damit die Änderungen wirksam werden: + recovery\$1target + recovery\$1target\$1lsn + recovery\$1target\$1name + recovery\$1target\$1time + recovery\$1target\$1xid + recovery\$1target\$1inclusive **Wichtig** Sie können jeweils nur einen Wiederherstellungszielparameter angeben. Die Konfiguration mehrerer Wiederherstellungszielparameter in der Konfigurationsdatei führt zu einem Fehler. ## Überlegungen zur Planung Berücksichtigen Sie bei der Planung der verzögerten Replikation mit RDS für PostgreSQL folgende Aspekte: + Während der automatischen Rotation der `rdsrepladmin`-Anmeldeinformationen (die alle 90 Tage erfolgt) können verzögerte Lesereplikate vorübergehend in den Status `REPLICATION_ERROR` wechseln. Wenn das verzögerte Replikat über genügend WAL-Protokolle verfügt, um die konfigurierte Verzögerung beizubehalten, kann der WAL-Empfängerprozess unterbrochen werden, was zu einer WAL-Akkumulation auf der Quelle führt. Sie sollten den Replikationsstatus auf dem Replikat und die Speichernutzung auf der Quelle überwachen, um zu verhindern, dass der Speicherplatz voll wird. + Wenn bei verzögerten Lesereplikaten Systemereignisse (wie Hochfahren oder Neustart) auftreten, wechseln sie in den Status `REPLICATION_ERROR`, in dem der WAL-Empfängerprozess inaktiv bleibt, bis der konfigurierte Verzögerungszeitraum abläuft. Dieses Verhalten kann zu einer WAL-Akkumulation auf der Quell-Instance führen, was möglicherweise einen vollen Speicher verursachen kann. Berücksichtigen Sie die folgenden vorbeugenden Maßnahmen: + Konfigurieren Sie CloudWatch Alarme, um die Speicherauslastung auf den Quell-Instances zu überwachen. + Aktivieren Sie die automatische Speicherskalierung, um eine unerwartete WAL-Expansion zu verarbeiten. + Legen Sie den Parameter `max_slot_wal_keep_size` auf der Quell-Instance fest, um die WAL-Beibehaltung pro Replikations-Slot zu begrenzen. + Überwachen Sie die Replikationsverzögerung und den Status des Replikations-Slots regelmäßig. + Längere Verzögerungen erhöhen die Anzahl der WAL-Protokolle auf den Replikaten und belegen dadurch mehr Speicherplatz. Überwachen Sie den Speicherplatz mithilfe von CloudWatch Alarmen, aktivieren Sie die auto-scaling oder catch Sie bei Bedarf Replikate nach. + Bei der Heraufstufung eines verzögerten Lesereplikats wird der Parameter `recovery_min_apply_delay` nicht berücksichtigt und alle ausstehenden WAL-Datensätze werden sofort angewendet. + Der Parameter `recovery_min_apply_delay` ist unabhängig von den einzelnen Ebenen einer kaskadierenden Replikationseinrichtung. Durch das Festlegen einer Verzögerung für ein Replikat nimmt die Verzögerung kaskadierter Replikate nicht zu. Weitere Informationen finden Sie in der [Dokumentation zu Lesereplikaten von RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) und in der [Dokumentation zur Notfallwiederherstellung von RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html). ## Grundlagen zu Einschränkungen Die verzögerte Replikation für Amazon RDS für PostgreSQL hat die folgenden Einschränkungen: + Für Blau/Grün-Bereitstellungen gelten bei der Konfiguration der verzögerten Replikation die folgenden Einschränkungen: + **Grüne Quell-Instance** – Der Parameter `recovery_min_apply_delay parameter` wird ignoriert, auch wenn er in der Parametergruppe konfiguriert ist. Alle Verzögerungseinstellungen auf der grünen Quell-Instance werden nicht wirksam. + **Grüne Replikat-Instance** – Der Parameter `recovery_min_apply_delay parameter` wird vollständig unterstützt und auf die PostgreSQL-Konfigurationsdatei angewendet. Die Verzögerungseinstellungen funktionieren während des Umstellungs-Workflows erwartungsgemäß. + Blue/Green RDS-Bereitstellungen für wichtige Versions-Upgrades + Bei Hauptversions-Upgrades werden alle verzögerten Lesereplikate automatisch beendet, damit die Quell-Instance mit dem Upgrade fortfahren kann, um für minimale Ausfallzeiten zu sorgen. Nachdem die Quell-Instance das Upgrade abgeschlossen hat, müssen Sie die verzögerten Replikate manuell neu erstellen. + Die verzögerte Replikation ist mit den folgenden Features nicht kompatibel. + Logische Replikation von RDS für PostgreSQL + Multi-AZ-Cluster von RDS für PostgreSQL (einschließlich der eingehenden und ausgehenden Replikation) + Aurora PostgreSQL # Problembehebung für Lesereplikate von RDS für PostgreSQL Im Folgenden finden Sie Tipps zur Problembehebung für einige häufige Probleme mit Lesereplikaten von RDS für PostgreSQL. **Beenden der Abfrage, die die Lesereplikatsverzögerung verursacht hat** Transaktionen, die im Transaktionsstatus entweder aktiv oder im Leerlauf sind und ü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. Achten Sie daher darauf, die Laufzeit dieser Transaktionen mit der PostgreSQL-Ansicht `pg_stat_activity` zu überwachen. Führen Sie eine Abfrage auf der primären 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'; ``` ``` SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,* FROM pg_stat_activity WHERE state = 'idle in transaction' AND xact_start is not null ORDER BY 1 DESC; ``` Nachdem Sie die PID der Abfrage identifiziert haben, können Sie wählen, ob Sie die Abfrage beenden möchten. Führen Sie eine Abfrage auf der primären Instance ähnlich der folgenden aus, um die Abfrage zu beenden, die über einen längeren Zeitraum ausgeführt wird: ``` SELECT pg_terminate_backend(PID); ```