Arbeiten mit Read Replicas in Amazon RDS for PostgreSQL - Amazon Relational Database Service
Logische Dekodierung auf einer Read ReplicaRead Replica-Beschränkungen unter PostgreSQLKonfiguration von Read Replicas mit PostgreSQLFunktionsweise der Replikation für verschiedene RDS-for-PostgreSQL-VersionenÜberwachen und Optimieren des ReplikationsprozessesProblembehandlung für RDS for PostgreSQL Read Replica

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 for PostgreSQL

Sie können Lesevorgänge für Ihre Amazon RDS for PostgreSQL PostgreSQL-DB-Instances skalieren, indem Sie den Instances Read Replicas hinzufügen. Wie andere Amazon RDS-Datenbank-Engines verwendet RDS for PostgreSQL native Replikationsmechanismen von PostgreSQL, um Read Replicas über Änderungen in der Quell-DB auf dem neuesten Stand zu halten. Allgemeine Informationen zu Lesereplikaten und Amazon RDS finden Sie unter Arbeiten mit DB-Instance-Lesereplikaten.

Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten in RDS for PostgreSQL.

Logische Dekodierung auf einer Read Replica

RDS for PostgreSQL unterstützt logische Replikation aus dem Standbymodus mit PostgreSQL 16.1. Auf diese Weise können Sie eine logische Dekodierung aus einer schreibgeschützten Standby-Instanz erstellen, wodurch die Belastung der primären 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. Diese Funktion steigert die Leistung Ihres Data Warehouse und Ihrer Datenanalyse.

Außerdem sorgen Replikationsslots in einem bestimmten Standby-Modus dafür, dass dieser Standby-Server zu einem Primärserver heraufgestuft wird. Das bedeutet, dass im Falle eines Failovers einer primären DB-Instance oder der Heraufstufung einer Standby-Instanz zur neuen primären Instanz die Replikationssteckplätze bestehen bleiben und die ehemaligen Standby-Abonnenten davon nicht betroffen sind.

Um eine logische Dekodierung auf einer Read Replica zu erstellen

  1. Logische Replikation aktivieren — Um eine logische Dekodierung in einem Standby-Modus 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.

    • Um die logische Replikation für eine neu erstellte RDS for PostgreSQL-DB-Instance zu aktivieren, erstellen Sie eine neue benutzerdefinierte DB-Parametergruppe und setzen Sie den statischen Parameter rds.logical_replication auf. 1 Ordnen Sie dann diese DB-Parametergruppe der Quell-DB-Instance und ihrer physischen Read Replica zu. Weitere Informationen finden Sie unter Verknüpfen einer DB-Parametergruppe mit einer DB-Instance.

    • Um die logische Replikation für eine bestehende RDS for PostgreSQL-DB-Instance zu aktivieren, ändern Sie die benutzerdefinierte DB-Parametergruppe der Quell-DB-Instance und ihrer physischen Read Replica, um den statischen Parameter auf zu setzen. rds.logical_replication 1 Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Parametergruppe.

    Anmerkung

    Sie müssen die DB-Instance neu starten, um diese Parameteränderungen zu übernehmen.

    Sie können die folgende Abfrage verwenden, um die Werte für wal_level und rds.logical_replication auf der Quell-DB-Instance und ihrer physischen Read Replica 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)

  2. Eine Tabelle in der Quelldatenbank erstellen — Connect der Datenbank in Ihrer Quell-DB-Instance her. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird.

    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

  3. Eine 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 Read Replica-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)

  4. Erstellen Sie ein Abonnement aus einer logischen Replikatinstanz — Erstellen Sie eine weitere RDS for PostgreSQL-DB-Instance als logische Replikatinstanz. Stellen Sie sicher, dass die VPC korrekt eingerichtet ist, um sicherzustellen, dass diese logische Replikatinstanz auf die physische Read Replica-Instanz zugreifen kann. Weitere Informationen finden Sie unter Amazon VPC VPCs und Amazon RDS. Wenn Ihre Quell-DB-Instance inaktiv ist, können Verbindungsprobleme auftreten und die Primär-DB-Instance sendet die Daten nicht in den Standby-Modus.

    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)

  5. Überprüfen Sie den Status des logischen Replikationssteckplatzes — Sie können nur den physischen Replikationssteckplatz 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 Read Replica-Instance können Sie jedoch den Steckplatz für die logische Replikation sehen, und der confirmed_flush_lsn Wert ändert sich, 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)

Read Replica-Beschränkungen unter PostgreSQL

Für PostgreSQL-Lesereplikate gelten folgende Beschränkungen:

Anmerkung

Eine Read Replica für RDS for PostgreSQL Multi-AZ- und Single-AZ-DB-Instance, auf der PostgreSQL Version 12 und früher ausgeführt wird, wird automatisch neu gestartet, um die Passwortrotation während des Wartungsfensters von 60 bis 90 Tagen anzuwenden.

  • 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 for PostgreSQL unterstützt kaskadierende Lesereplikate nur in RDS for PostgreSQL Version 14.1 und höher. Weitere Informationen finden Sie unter Verwendung von kaskadierenden Lesereplikaten mit RDS for PostgreSQL.

  • 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.

  • Wenn Sie eine PostgreSQL-Read Replica innerhalb einer Replikationskette (einer Reihe von kaskadierenden Read Replicas) heraufstufen, empfangen alle vorhandenen Downstream-Read Replicas weiterhin automatisch WAL-Dateien von der hochgestuften Instanz. Weitere Informationen finden Sie unter Verwendung von kaskadierenden Lesereplikaten mit RDS for PostgreSQL.

  • 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 for PostgreSQL Versionen vor 14.1 aktivieren. Automatisierte Backups für Lesereplikate werden nur für RDS for PostgreSQL 14.1 und höhere Versionen unterstützt. Erstellen Sie für RDS for PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen.

  • P oint-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 zu einer bestimmten Zeit.

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 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 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 for PostgreSQL. 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.

Sie können Read Replicas für Ihre RDS for PostgreSQL-DB-Instance genauso erstellen AWS-Region wie Ihre Quell-DB-Instance. Dies wird als regionale Replikation bezeichnet. Sie können Read Replicas auch in einer anderen Datenbank als der AWS-Regionen Quell-DB-Instance erstellen. Dies wird als regionsübergreifende Replikation bezeichnet. Weitere Informationen zum Einrichten von regionsübergreifenden Lesereplikaten finden Sie unter Erstellen eines Lesereplikats in einer anderen AWS-Region. 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 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.

RDS-for-PostgreSQL-Lesereplikate haben Zugriff auf externe Datenbanken, die über Fremddaten-Wrapper (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. Andere unterstützte FDWs sind oracle_fdw, postgres_fdw und tds_fdw. Weitere Informationen finden Sie unter Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS for PostgreSQL.

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 Multi-AZ-DB-Instance-Bereitstellungen.

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. Wenn 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.

  • 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-Prozess bei Amazon RDS. Weitere Informationen dazu, wie Lesereplikate in einer Multi-AZ-Bereitstellung funktionieren, finden Sie unter Arbeiten mit DB-Instance-Lesereplikaten.

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.

Verwendung von kaskadierenden Lesereplikaten mit RDS for PostgreSQL

Ab Version 14.1 unterstützt RDS for 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 for 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 for 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 for 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 for 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 for 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 for PostgreSQL. Erstellen Sie zuerst das Lesereplikat und aktivieren Sie dann automatische Backups auf der DB-Instance von RDS for PostgreSQL. Der Prozess ist der gleiche wie bei anderen Amazon-RDS-DB-Engines. Weitere Informationen finden Sie unter Erstellen eines Lesereplikats.

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 DB-Instance mit Lese-/Schreibzugriff.

    • 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.

Anmerkung

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.

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

Wie in Konfiguration von Read Replicas mit PostgreSQL erläutert, verwendet RDS for 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 for PostgreSQL verwendet werden.

Regional Regionsübergreifend
PostgreSQL 14.1 and higher versions

  • Replikationsslots

  • Amazon-S3-Archiv

  • Replikationsslots
PostgreSQL 13 and lower versions

  • 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 für RDS for PostgreSQL 13 und höhere Versionen ist 20. 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.

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 die gelesene Replik mithilfe archivierter WAL-Daten von Amazon S3 oder mithilfe der WAL-Daten wieder her, die dem Replikationsslot zugeordnet sind. 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 Transaktions-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.

Ü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 Amazon- CloudWatch Metriken für Amazon RDS.

  • 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 for PostgreSQL verwenden Replikationsslots für regionsübergreifende Lesereplikate. RDS for 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.

Der Status unreserved und der lost Status von wal_status werden nur angezeigt, wenn der Wert nicht negativ max_slot_wal_keep_size 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 – Listet den Slot mit der größten Verzögerung auf (der am weitesten hinter der primären Instance liegt). Diese Verzögerung kann mit dem Lesereplikat, aber auch mit der Verbindung verbunden sein.

  • 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. Überwachen von Amazon RDS-Metriken mit Amazon CloudWatch 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 im AWS -Datenbank-Blog.

Problembehandlung für RDS for PostgreSQL Read Replica

Im Folgenden finden Sie Ideen zur Fehlerbehebung für einige häufig auftretende Probleme mit Read Replica in RDS for PostgreSQL.

Beenden Sie die Abfrage, die den Read Replica-Lag verursacht hat

Transaktionen, die im Transaktionsstatus entweder aktiv oder inaktiv 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 pg_stat_activity PostgreSQL-Ansicht zu überwachen.

Führen Sie eine Abfrage auf der primären Instanz ä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 Instanz aus, die der folgenden ähnelt, um die Abfrage zu beenden, die für eine lange Zeit läuft:

SELECT pg_terminate_backend(PID);