Arbeiten mit Read Replicas für Amazon RDS for Postgre SQL - Amazon Relational Database Service
Logische Dekodierung auf einer Read ReplicaLesen Sie die Einschränkungen von Replikaten mit Postgre SQLLesen Sie die Replikatkonfiguration mit Postgre SQLVerwenden von kaskadierenden LesereplikatenErstellen von regionsübergreifenden kaskadierenden Read ReplicasWie funktioniert die Replikation RDS für verschiedene SQL Postgre-VersionenÜberwachen und Optimieren des ReplikationsprozessesProblembehandlung RDS für die SQL Postgre-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 für Amazon RDS for Postgre SQL

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

Im Folgenden finden Sie spezifische Informationen zur Arbeit mit Read Replicas RDS für Postgre. SQL

Logische Dekodierung auf einer Read Replica

RDSfor Postgre SQL unterstützt mit Postgre 16.1 die logische Replikation aus dem Standbymodus. SQL 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 Lesen Sie die Replikatkonfiguration mit Postgre SQL.

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

    • Um die logische Replikation für eine bestehende SQL DB-Instance RDS für Postgre 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 in Amazon RDS.

    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 Verbindung zu einer DB-Instance herstellen, auf der die SQL Postgre-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. Ein Abonnement aus einer logischen Replikatinstanz erstellen — Erstellen Sie eine weitere RDS für SQL Postgre-DB-Instance als logische Replikatinstanz. Stellen Sie sicher, dass die Einrichtung korrekt VPC ist, um sicherzustellen, dass diese logische Replikatinstanz auf die physische Read Replica-Instance zugreifen kann. Weitere Informationen finden Sie unter Amazon VPC 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-Einschränkungen mit Postgre SQL

Die folgenden Einschränkungen gelten für Postgre-Read ReplicasSQL:

Anmerkung

Eine Read Replica RDS für Postgre SQL Multi-AZ- und Single-AZ-DB-Instances, auf denen Postgre SQL 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. Wenn die Verbindung vom Replikat zur Quelle vor dem geplanten Neustart unterbrochen wird, wird die Instance trotzdem neu gestartet, damit die Replikation fortgesetzt werden kann.

  • Postgre-Read-Replicas sind SQL schreibgeschützt. Obwohl es sich bei einer Read Replica nicht um eine beschreibbare DB-Instance handelt, können Sie sie zu einer eigenständigen DB-Instance für Postgre-DB heraufstufen. RDS SQL Der Prozess kann jedoch nicht rückgängig gemacht werden.

  • Sie können keine Read Replica aus einer anderen Read Replica erstellen, wenn auf Ihrer RDS for SQL Postgre-DB-Instance eine Postgre-Version vor 14.1 ausgeführt wird. SQL RDSfor Postgre SQL unterstützt kaskadierende Read Replicas nur für Postgre-Version 14.1 und höhere VersionenRDS. SQL Weitere Informationen finden Sie unter Verwenden von kaskadierenden Read Replicas mit für Postgre RDS SQL.

  • Wenn Sie eine SQL Postgre-Read Replica heraufstufen, wird sie zu einer beschreibbaren DB-Instance. Sie empfängt keine Write-Ahead-Log (WAL) -Dateien mehr von einer Quell-DB-Instance und ist keine schreibgeschützte Instance mehr. Sie können neue Read Replicas aus der beworbenen DB-Instance erstellen, wie Sie es für jede RDS Postgre-DB-Instance tun. SQL Weitere Informationen finden Sie unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance.

  • Wenn Sie eine SQL Postgre-Read Replica innerhalb einer Replikationskette heraufstufen (eine Reihe von kaskadierenden Read Replicas), empfangen alle vorhandenen Downstream-Read Replicas weiterhin automatisch Dateien von der hochgestuften Instance. WAL Weitere Informationen finden Sie unter Verwenden von kaskadierenden Read Replicas mit für Postgre RDS SQL.

  • Wenn auf der Quell-DB-Instance keine Benutzertransaktionen ausgeführt werden, meldet die zugehörige SQL Postgre-Read Replica eine Replikationsverzögerung von bis zu fünf Minuten. Die Replikatverzögerung wird wie folgt berechnetcurrentTime - lastCommitedTransactionTimestamp, was bedeutet, dass, wenn keine Transaktionen verarbeitet werden, der Wert der Replikatverzögerung für einen bestimmten Zeitraum zunimmt, bis das Write-Ahead-Log-Segment () wechselt. WAL Standardmäßig RDS SQL wechselt Postgre das WAL Segment alle 5 Minuten, was zu einem Transaktionsdatensatz und einer Verringerung der gemeldeten Verzögerung führt.

  • Für SQL Postgre-Versionen vor 14.1 können Sie automatische Backups für SQL Postgre-Read Replicas nicht aktivieren. RDS Automatisierte Backups für Read Replicas werden nur RDS für Postgre SQL 14.1 und höhere Versionen unterstützt. Erstellen Sie RDS für Postgre SQL 13 und frühere Versionen einen Snapshot aus einer Read Replica, wenn Sie eine Sicherungskopie davon erstellen möchten.

  • Point-in-time recovery (PITR) wird für Read Replicas nicht unterstützt. Sie können es nur PITR mit einer primären (Writer-) Instanz verwenden, nicht mit einer Read Replica. Weitere Informationen hierzu finden Sie unter Wiederherstellung einer DB-Instance zu einem bestimmten Zeitpunkt für Amazon RDS.

Lesen Sie die Replikatkonfiguration mit Postgre SQL

RDSfor Postgre SQL verwendet die SQL native Streaming-Replikation von Postgre, 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 durch eine spezielle Verbindung erstellt, die Write-Ahead-Log-Daten (WAL) von der Quell-DB-Instance an die Read Replica überträgt. Weitere Informationen finden Sie unter Streaming-Replikation in der Postgre-Dokumentation. SQL

Postgre streamt SQL asynchron Datenbankänderungen an diese sichere Verbindung, wenn 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 Verwendung SSL mit einer SQL Postgre-DB-Instance.

Postgre SQL verwendet eine Replikationsrolle, um die Streaming-Replikation durchzuführen. Die Rolle besitzt Berechtigungen, kann jedoch nicht für das Ändern von Daten verwendet werden. Postgre SQL verwendet einen einzigen Prozess für die Replikation.

Sie können eine SQL Postgre-Lesereplik 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 die Read Replica für Sie fest, ohne den Service zu beeinträchtigen. 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 Postgre SQL 14.1 können Sie auch bis zu drei Ebenen von Read Replica in einer Kette (Kaskade) aus einer Quell-DB-Instance erstellen. RDS Weitere Informationen finden Sie unter Verwenden von kaskadierenden Read Replicas mit für Postgre RDS SQL. 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 Postgre-DB-Instance genauso AWS-Region wie RDS für Ihre SQL Quell-DB-Instance erstellen. Dies wird als regionale Replikation bezeichnet. Sie können Read Replicas auch in einer anderen Datenbank 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. Die verschiedenen Mechanismen, die den Replikationsprozess für regionsinterne und regionsübergreifende Replikationen unterstützen, unterscheiden sich je nach der RDS für Postgree verwendeten SQL Version geringfügig, wie unter beschrieben. Wie funktioniert die Streaming-Replikation RDS für verschiedene Postgre-Versionen SQL

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 inkompatiblen Parameter auf einer Read Replica, wenn sie verhindern, dass die Read Replica gestartet wird. 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 RDS aktualisiert Amazon den Parameter auf der Read Replica auf denselben Wert wie auf der Quell-DB-Instance.

RDSBei Postgre haben SQL Read Replicas Zugriff auf externe Datenbanken, die über Foreign Data Wrapper (FDWs) auf der Quell-DB-Instance verfügbar sind. Nehmen wir zum Beispiel an, dass Ihre RDS for SQL Postgre-DB-Instance den mysql_fdw Wrapper verwendet, um auf Daten von My zuzugreifen. RDS SQL In diesem Fall können Ihre Lesereplikate auch auf diese Daten zugreifen. Zu den weiteren unterstützten FDWs gehören oracle_fdwpostgres_fdw, und. tds_fdw Weitere Informationen finden Sie unter Arbeiten mit den unterstützten Foreign Data Wrappern für RDS SQL.

RDSFür SQL Postgree-Read Replicas mit Multi-AZ-Konfigurationen verwenden

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

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 Read Replicas müssen je nach Postgre-Version möglicherweise wie folgt RDS neu gestartet werden: SQL

  • Postgre SQL 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 kann es jedoch vorkommen, dass Ihre Client-Anwendung die Domain Name Service (DNS) -Details für Ihre Read Replicas zwischenspeichert. 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 RDSGrundlegende Betriebsrichtlinien von Amazon.

  • Postgre SQL 12 und alle früheren Versionen — Die Read Replicas werden nach einem Failover auf das Standby-Replikat automatisch neu gestartet, da das Standby-Replikat (jetzt primär) eine andere IP-Adresse und einen anderen Instanznamen 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. Weitere Informationen dazu, wie Lesereplikate in einer Multi-AZ-Bereitstellung funktionieren, finden Sie unter Arbeiten mit DB-Instance-Lesereplikaten.

Um Failover-Unterstützung für eine Read Replica bereitzustellen, können Sie die Read Replica als Multi-AZ-DB-Instance erstellen, sodass Amazon eine Standby-Version Ihres Replikats in einer anderen Availability Zone (AZ) RDS erstellt. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

Verwenden von kaskadierenden Read Replicas mit für Postgre RDS SQL

Ab Version 14.1 unterstützt RDS for SQL Postgre kaskadierende Read Replicas. Mit Cascading Read Replicas können Sie Lesevorgänge skalieren, ohne dass Ihre Quelle für die Postgre-DB-Instance unnötig unnötig belastet wird. RDS SQL Aktualisierungen des WAL Protokolls werden nicht von der Quell-DB-Instance an jede Read Replica gesendet. Stattdessen sendet jede Read Replica in einer kaskadierenden Serie WAL Protokollaktualisierungen an die nächste Read Replica in der Serie. Damit wird die Belastung der Quell-DB-Instance reduziert.

Bei kaskadierenden Read Replicas sendet Ihre RDS for SQL Postgre-DB-Instance WAL Daten an die erste Read Replica in der Kette. Diese Read Replica sendet dann WAL Daten an das zweite Replikat in der Kette und so weiter. Das Endergebnis ist, dass alle Read Replicas in der Kette die Änderungen aus der SQL For-Postgre-DB-Instance enthalten, jedoch ohne den Overhead ausschließlich RDS für die Quell-DB-Instance.

Sie können eine Reihe von bis zu drei Read Replicas in einer Kette aus einer Quelle RDS für die SQL Postgre-DB-Instance erstellen. Nehmen wir zum Beispiel an, Sie haben eine RDS für Postgre SQL 14.1 DB-Instance,. 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 von einer SQL Quell-DB-Instance RDS für Postgre bis zum Ende einer Reihe von kaskadierenden Read Replicas kann aus höchstens vier DB-Instances bestehen.

Damit kaskadierende Read Replicas funktionieren, aktivieren Sie automatische Backups auf Ihrem for Postgre. RDS SQL Erstellen Sie zuerst die Read Replica und aktivieren Sie dann automatische Backups auf der for Postgre-DB-Instance. RDS SQL Der Prozess ist derselbe 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 Read Replicas SQL unterstützt Postgre 15 Read Replicas für jede Quell-DB-Instance auf der ersten Replikationsebene und 5 Read Replicas für jede Quell-DB-Instance auf der zweiten und dritten Replikationsebene. RDS

Erstellen von regionsübergreifenden kaskadierenden Read Replicas mit für Postgre RDS SQL

RDSfor Postgre SQL unterstützt regionsübergreifende kaskadierende Read Replicas. Sie können ein regionsübergreifendes Replikat aus der Quell-DB-Instance und anschließend regionsgleiche Replikate daraus erstellen. Sie können auch ein regionsübergreifendes Replikat aus der Quell-DB-Instance und anschließend regionsübergreifende Replikate daraus erstellen.

Erstellen Sie ein regionsübergreifendes Replikat und anschließend regionsübergreifende Replikate

Sie können eine RDS für SQL Postgre-DB-Instance mit Version 14.1 oder höher verwenden, um Folgendes zu tun: rpg-db-main

  1. Beginnen Sie mit rpg-db-main (US- EAST -1) und erstellen Sie die erste regionsübergreifende Read Replica in der Kette, read-replica-1 (US- -2). WEST

  2. Erstellen Sie mit der ersten regionsübergreifenden Kopie read-replica-1 (US- WEST -2) die zweite Read Replica in der Kette read-replica-2 (US- -2). WEST

  3. Verwenden Sieread-replica-2, um das dritte Read Replica in der Kette read-replica-3 (US- WEST -2) zu erstellen.

Erstellen Sie ein Replikat derselben Region und anschließend regionsübergreifende Replikate

Sie können eine RDS für SQL Postgre-DB-Instance mit Version 14.1 oder höher verwenden, um Folgendes zu tun: rpg-db-main

  1. Beginnen Sie mit rpg-db-main (US- EAST -1) und erstellen Sie die erste Lesereplik in der Kette, read-replica-1 (US- EAST -1).

  2. Erstellen Sie mit read-replica-1 (US- EAST -1) die erste regionsübergreifende Read Replica in der Kette, read-replica-2 (US- WEST -2).

  3. Erstellen Sie mit read-replica-2 (US- WEST -2) die dritte Read Replica in der Kette, read-replica-3 (US- WEST -2).

Einschränkungen bei der Erstellung regionsübergreifender Read Replicas

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

Vorteile der Verwendung von kaskadierenden Read Replicas

  • 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 eine lokale Lesereplik, was die Leistung und das Benutzererlebnis verbessert.

  • Hochverfügbarkeit und Notfallwiederherstellung — Im Falle eines Ausfalls des Primärservers können Replikate auf Primärserver 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 die allgemeine Ausfallsicherheit des Systems verbessert wird.

  • 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 überschaubares Wachstum der Replikationseinrichtung.

Weitere Informationen zu den Vorteilen der Replikation finden Sie unter Über die Replikation in der Cloud SQL.

Bewährte Methode für die Verwendung von regionsübergreifenden Read Replicas

  • Bevor Sie ein Replikat heraufstufen, erstellen Sie zusätzliche Replikate. Das spart Zeit und ermöglicht eine effiziente Bewältigung der Arbeitslast.

Wie funktioniert die Streaming-Replikation RDS für verschiedene Postgre-Versionen SQL

Wie unter beschriebenLesen Sie die Replikatkonfiguration mit Postgre SQL, SQL verwendet RDS for Postgre das native Streaming-Replikationsprotokoll SQL von Postgre, um WAL Daten von der Quell-DB-Instance zu senden. Es sendet WAL Quelldaten an Read Replicas sowohl für regionsinterne als auch für regionsübergreifende Read Replicas. Mit Version 9.4 SQL führte Postgre physische Replikationssteckplätze als unterstützenden Mechanismus für den Replikationsprozess ein.

Ein physischer Replikationssteckplatz verhindert, dass eine Quell-DB-Instance WAL Daten entfernt, bevor sie von allen Read Replicas verbraucht wurden. Jedes Lesereplikat hat einen eigenen physischen Slot in der Quell-DB-Instance. Der Steckplatz zeichnet die älteste WAL (anhand der logischen SequenznummerLSN) auf, die möglicherweise für das Replikat benötigt wird. Wenn alle Steckplätze und DB-Verbindungen einen bestimmten Wert WAL (LSN) überschritten haben, kann dieser LSN Wert beim nächsten Checkpoint entfernt werden.

Amazon RDS verwendet Amazon S3 zur Archivierung WAL von Daten. 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 den SQL Postgre-Versionen und den von for Postgre verwendeten Unterstützungsmechanismen für regionsübergreifend und regionsübergreifend. RDS SQL

Version Regional Regionsübergreifend
Postgre 14.1 SQL und höhere Versionen

  • Replikationsslots

  • Amazon-S3-Archiv

  • Replikationsslots
Postgre SQL 13 und niedrigere Versionen

  • Amazon-S3-Archiv

  • Replikationsslots

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

Grundlegendes zu den Parametern, die die Postgre-Replikation SQL 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. Die Standardeinstellung RDS für Postgre SQL 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 finden Sie unter max_wal_senders in der Postgre-Dokumentation. SQL

wal_keep_segments

Der wal_keep_segments Parameter gibt die Anzahl der Write-Ahead-Logdateien (WAL) an, die die Quell-DB-Instance im Verzeichnis aufbewahrt. pg_wal 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 RDS generiert Amazon einen Replikationsfehler und beginnt mit der Wiederherstellung der Read Replica. Dazu werden die archivierten WAL Daten der Quell-DB-Instance aus Amazon S3 wiedergegeben. 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 in Aktion sehen, wie er in der SQL Postgre-Anmeldung aufgezeichnet wurde. Beispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen

Anmerkung

In SQL Postgre-Version 13 hat der wal_keep_segments Parameter einen Namen. wal_keep_size 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 Postgre-Dokumentation. SQL

max_slot_wal_keep_size

Der max_slot_wal_keep_size Parameter steuert die WAL Datenmenge, die die RDS for Postgre-DB-Instance im Verzeichnis speichert, um Steckplätze zu bedienenSQL. pg_wal Dieser Parameter wird für Konfigurationen verwendet, die Replikationsslots nutzen. Der Standardwert für diesen Parameter ist-1, was bedeutet, dass es keine Begrenzung dafür gibt, wie viele WAL Daten auf der Quell-DB-Instance gespeichert werden. Weitere Informationen zur Überwachung Ihrer Replikationsslots finden Sie unter Überwachung der Replikationsslots RDS für Ihre SQL Postgre-DB-Instance.

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

Immer wenn der Stream, der WAL Daten für eine Read Replica bereitstellt, unterbrochen wird, wechselt Postgre in den Wiederherstellungsmodus. SQL Es stellt das gelesene Replikat mithilfe archivierter WAL Daten aus Amazon S3 oder mithilfe der mit dem Replikationssteckplatz verknüpften WAL Daten wieder her. Wenn dieser Vorgang abgeschlossen ist, SQL stellt Postgre die Streaming-Replikation wieder her.

Beispiel: Wiederherstellen eines Lesereplikats nach einer Replikationsunterbrechungen

Im folgenden Beispiel finden Sie die Protokolldetails, die den Wiederherstellungsprozess für ein Lesereplikat veranschaulichen. Das Beispiel bezieht sich auf eine RDS SQL For-Postgre-DB-Instance, auf der Postgre SQL Version 12.9 in derselben Version AWS-Region wie die Quell-DB ausgeführt wird, sodass keine Replikationsslots verwendet werden. Der Wiederherstellungsprozess ist derselbe für andere RDS für SQL Postgre-DB-Instances, auf denen Postgre vor Version 14.1 mit regionsinternen SQL Read Replicas ausgeführt wird.

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

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 genügend archivierte WAL Daten auf dem Replikat RDS wiedergibt, um catch, beginnt das Streaming zur Read Replica erneut. Wenn das Streaming wieder aufgenommen wird, RDS schreibt Amazon einen Eintrag in die Protokolldatei, der dem folgenden ähnelt.

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 TransaktionenIDs, 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 auf dem Replikat unter den Parameterwerten auf dem Primärgerät liegen, 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 unzureichenden Speichers 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, dass Sie Ihre RDS SQL Postgre-DB-Instance routinemäßig überwachen und Repliken lesen. Sie müssen sicherstellen, dass Ihre Lesereplikate mit den Änderungen an der Quell-DB-Instance Schritt halten. Amazon stellt Ihre Read Replicas RDS transparent wieder her, wenn der Replikationsprozess unterbrochen wird. 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 RDS ReplicaLag Amazon-Metrik ansehen. Weitere Informationen über ReplicaLag und andere Kennzahlen für Amazon RDS finden Sie unter CloudWatch Amazon-Metriken für Amazon RDS.

  • Informationen, mit denen Sie Ihre Einstellungen anpassen können, finden Sie im SQL Postgre-Protokoll. An jedem Checkpoint erfasst das SQL Postgre-Protokoll die Anzahl der wiederverwendeten 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. Nehmen wir zum Beispiel an, dass das SQL Postgre-Protokoll in einem Intervall von checkpoint complete 5 35 recycled Minuten angezeigt wird. 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 SQL Postgre-Protokoll direkt zu analysieren, können Sie Amazon verwenden, CloudWatch um die gesammelten Metriken zu überprüfen. Sie können beispielsweise den Wert der TransactionLogsGeneration Metrik überprüfen, um zu sehen, wie viele WAL Daten von der Quell-DB-Instance generiert werden. In einigen Fällen kann die Arbeitslast auf Ihrer DB-Instance eine große WAL Datenmenge generieren. 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.

Überwachung der Replikationsslots RDS für Ihre SQL Postgre-DB-Instance

Alle Versionen von RDS for Postgre SQL verwenden Replikationsslots für regionsübergreifende Read Replicas. RDSfür Postgre SQL 14.1 und höhere Versionen werden Replikationsslots für regionsinterne Read Replicas verwendet. Read Replicas in der Region verwenden Amazon S3 auch zum Archivieren WAL von Daten. Mit anderen Worten, wenn auf Ihrer DB-Instance und Ihren Read Replicas Postgre SQL 14.1 oder höher ausgeführt wird, sind sowohl Replikationssteckplätze als auch Amazon S3 S3-Archive für die Wiederherstellung der Read Replica verfügbar. 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 vier SQL Postgre-DB-Instances anzeigen, indem Sie die Ansicht wie folgt abfragen. pg_replication_slots

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 reserved Wert wal_status of bedeutet, dass die im Slot gespeicherte WAL Datenmenge innerhalb der Grenzen des Parameters liegt. max_wal_size Mit anderen Worten: Der Replikationsslots ist angemessen dimensioniert. Folgende Statuswerte sind außerdem möglich:

  • extended— Der Steckplatz überschreitet die max_wal_size Einstellung, aber die WAL Daten werden beibehalten.

  • unreserved— Der Steckplatz enthält nicht mehr 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 lost Zustände von unreserved und wal_status werden nur angezeigt, wenn sie max_slot_wal_keep_size nicht negativ sind.

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, wie viel Speicherplatz 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 RDS für Postgre finden Sie SQL unterÜberwachung von Amazon RDS Amazon mit Amazon CloudWatch. Weitere Informationen zur Überwachung der Streaming-Replikation auf Ihren RDS for SQL Postgre-DB-Instances finden Sie im AWS Datenbank-Blog unter Bewährte Methoden für die RDS Amazon SQL Postgre-Replikation.

Fehlerbehebung RDS für SQL Postgre-Read Replica

Im Folgenden finden Sie Ideen zur Behebung einiger häufig RDS auftretender Probleme mit Postgre SQL Read Replica.

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

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

Führen Sie eine Abfrage auf der primären Instanz aus, die der folgenden ähnelt, 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 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);