Arbeiten mit PostgreSQL Read Replicas in Amazon RDS - Amazon Relational Database Service

Arbeiten mit PostgreSQL Read Replicas in Amazon RDS

Sie verwenden Lesereplikate üblicherweise, um die Replikation zwischen Amazon RDS-DB-Instances zu konfigurieren. Allgemeine Informationen zu Lesereplikaten finden Sie unter Arbeiten mit Lesereplikaten.

Dieser Abschnitt enthält spezifische Informationen zum Arbeiten mit Lesereplikaten unter PostgreSQL.

Konfiguration von Read Replicas mit PostgreSQL

Amazon RDS PostgreSQL 9.3.5 verwendet die native PostgreSQL Streaming-Replikation, um eine schreibgeschützte Kopie einer Quell-DB-Instance zu erstellen. Diese Read Replica (ein „Standby“ in der PostgreSQL-Terminologie) ist eine asynchron erstellte physische Replikation der-DB-Quell-Instance. Sie wird von einer speziellen Verbindung erstellt, die Write-Ahead-Log-Daten (WAL) zwischen der Quell-DB-Instance und dem Lesereplikat übermittelt, wobei PostgreSQL Datenbankänderungen asynchron streamt, während sie vorgenommen werden.

PostgreSQL verwendet eine "Replikations"-Rolle, um die Streaming-Replikation durchzuführen. Die Rolle besitzt Sonderrechte, kann jedoch nicht für das Ändern von beliebigen Daten verwendet werden. PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation.

Bevor eine DB-Instance als eine Quell-DB-Instance eingesetzt werden kann, müssen Sie automatische Backups für die DB-Instance aktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf einen anderen Wert als 0 festlegen.

Das Erstellen einer PostgreSQL Read Replica erfordert keinen Ausfall der DB-Quell-Instance. Amazon RDS legt die notwendigen Parameter und Berechtigungen für die DB-Quell-Instance und die Read Replica ohne Servieunterbrechung fest. Ein Snapshot von der Quell-DB-Instance wird gemacht und dieser Snapshot wird zum Lesereplikat. Es findet kein Nutzungsausfall statt, wenn Sie ein Lesereplikat löschen.

Sie können bis zu fünf Lesereplikate aus einer Quell-DB-Instance erstellen. 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 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.

PostgreSQL-DB-Instances verwenden eine sichere Verbindung, die Sie verschlüsseln können, indem Sie den Parameter ssl sowohl für die Quell- als auch für die Lesereplikat-Instances auf 1 setzen.

Sie können ein Lesereplikat aus Single-AZ- oder Multi-AZ-DB-Instance-Bereitstellungen erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten zu verbessern, aber Sie können Multi-AZ nicht zweitranging noch für schreibgeschützte Abfragen verwenden. Stattdessen können Sie Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Wenn die Quell-Instance einer Multi-AZ-Bereitstellung ein Failover zur sekundären Instance durchführt, werden alle zugehörigen Lesereplikate automatisch auf die Verwendung der sekundären (jetzt primären) Instance als Replikationsquelle umgeschaltet. Weitere Informationen finden Sie unter Hohe Verfügbarkeit (Multi-AZ) für Amazon RDS.

Sie können ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt eine Standby-Version des Replikats in einer anderen Availability Zone, um ein Failover für das Replikat zu unterstützen. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

Wenn Sie die Erweiterung postgres_fdw verwenden, um auf Daten aus einem externen Server zuzugreifen, erhalten auch die Lesereplikate Zugriff darauf. Weitere Informationen zur Verwendung von postgres_fdw finden Sie unter Zugreifen auf externe Daten mit der Erweiterung postgres_fdw.

Überwachung von PostgreSQL Read Replicas

Für PostgreSQL-Lesereplikate können Sie die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie die Amazon RDS-Metrik ReplicaLag anzeigen. Die Kennzahl ReplicaLag meldet den Wert von SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS replica_lag.

Read Replica-Beschränkungen unter PostgreSQL

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

  • Alle PostgreSQL-Lesereplikate sind schreibgeschützt und können nicht beschreibbar gemacht werden.

  • Sie können kein Lesereplikat aus einem anderen Lesereplikat erstellen (d. h. Sie können keine kaskadierenden Lesereplikate erstellen).

  • Sie können ein PostgreSQL-Lesereplikat zu einer neuen Quell-DB-Instance hochstufen. Jedoch wird das Lesereplikat nicht automatisch zur neuen Quell-DB-Instance. Das Lesereplikat empfängt, wenn es hochgestuft wird, keine WAL-Kommunikation mehr und ist nicht länger eine schreibgeschützte Instance. Sie müssen jegliche Replikation einrichten, die Sie fortfahren lassen möchten, da das hochgestufte Lesereplikat jetzt die neue Quell-DB-Instance ist.

  • Ein PostgreSQL-Lesereplikat meldet eine Replikationsverzögerung von bis zu fünf Minuten, wenn keine Benutzertransaktionen in der Quell-DB-Instance erfolgen.

Replikationsunterbrechungen bei PostgreSQL Read Replicas

In einigen Situationen kann eine PostgreSQL-Quell-DB-Instance unbeabsichtigt die Replikation mit einem Lesereplikat unterbrechen. Zu diesen Situationen gehören die Folgenden:

  • Der Parameter max_wal_senders ist zu niedrig eingestellt, um genügend Daten für die Anzahl an Lesereplikaten bereitzustellen. Diese Situation führt zum Anhalten der Replikation.

  • Der PostgreSQL-Parameter wal_keep_segments gibt vor, wie viele Write-Ahead-Protokolldateien (WAL) für die Bereitstellung von Daten an die Lesereplikate beibehalten werden. Der Parameterwert gibt die Anzahl an beizubehaltenden Protokollen an. Wenn Sie den Parameterwert zu niedrig einstellen, kann dies dazu führen, dass ein Lesereplikat dermaßen zurückfällt, dass der Replikations-Stream anhält. In diesem Fall meldet Amazon RDS einen Replikationsfehler und beginnt mit der Wiederherstellung des Lesereplikats, indem es die archivierten WAL-Protokolle der Quell-DB-Instance 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. Weitere Informationen finden Sie unter Fehlerbehebung eines Problems in einer PostgreSQL Read Replica.

  • Ein PostgreSQL Read Replica erfordert einen Neustart wenn die IP-Adresse des Endpunkts der DB-Quell-Instance geändert wird.

Wenn ein WAL-Stream, der Daten an das Lesereplikat leitet, unterbrochen wird, wechselt PostgreSQL in den Wiederherstellungsmodus, um das Lesereplikat mithilfe der archivierten WAL-Dateien wiederherzustellen. Wenn dieser Vorgang abgeschlossen ist, versucht PostgreSQL, das Streamen der Replikation wieder aufzunehmen.

Fehlerbehebung eines Problems in einer PostgreSQL Read Replica

PostgreSQL verwendet Replikationsslots für die regionsübergreifende Replikation, sodass der Vorgang zur Fehlerbehebung von regionalen und regionsübergreifenden Replikationsproblemen unterschiedlich ist.

Fehlerbehebung bei Problemen mit PostgreSQL Read Replicas innerhalb einer AWS-Region

Der PostgreSQL-Parameter wal_keep_segments gibt vor, wie viele Write-Ahead-Protokolldateien (WAL) für die Bereitstellung von Daten an die Lesereplikate beibehalten werden. Der Parameterwert gibt die Anzahl an beizubehaltenden Protokollen an. Wenn Sie den Parameterwert zu niedrig einstellen, kann dies dazu führen, dass ein Lesereplikat dermaßen zurückfällt, dass der Replikations-Stream anhält. In diesem Fall meldet Amazon RDS einen Replikationsfehler und beginnt mit der Wiederherstellung des Lesereplikats, indem es die archivierten WAL-Protokolle der Quell-DB-Instance 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.

Das PostgreSQL-Protokoll für das Lesereplikat zeigt an, wenn Amazon RDS ein Lesereplikat wiederherstellt. Dies ist der Zustand, in dem archivierte WAL-Dateien erneut wiedergegeben werden.

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

Nach einer bestimmten Zeit hat Amazon RDS genügend archivierte WAL-Dateien für das Replikat wiedergegeben, um dem Lesereplikat die Synchronisation und das Streaming wieder zu erlauben. An dieser Stelle fährt PostgreSQL mit dem Streamen fort und schreibt eine Zeile in die Protokolldatei, wie nachstehend aufgeführt.

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

Sie können bestimmen, wie viele WAL-Dateien Sie beibehalten möchten, wenn Sie sich die Informationen zum Kontrollpunkt im Protokoll ansehen, Das PostgreSQL-Protokoll zeigt die folgenden Informationen zu jedem Kontrollpunkt. Aus den "# recycled"-Transaktionsprotokolldateien dieser Protokollstatements können Sie erschließen, wie viele Transaktionsdateien innerhalb eines Zeitabschnitts recycelt werden, und diese Informationen verwenden, um den wal_keep_segments-Parameter abzustimmen.

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

Angenommen, die PostgreSQL-Protokolle zeigen an, dass innerhalb der nächsten 5 Minuten 35 Dateien aus den Protokollstatements mit dem Status „Kontrollpunkt abgeschlossen” recycelt werden. In diesem Fall wissen wir, dass sich ein Lesereplikat bei diesem Nutzungsmuster auf 35 Transaktionsdateien in fünf Minuten verlässt. Ein Lesereplikat überlebt nicht fünf Minuten in einem Ruhezustand, wenn der wal_keep_segments-Parameter der Quell-DB-Instance auf den Standardwert 32 gesetzt ist.

Fehlerbehebung von Problemen mit PostgreSQL Read Replicas in anderen AWS-Regionen

PostgreSQL der Version 9.5.2 verwendet physische Replikations-Slots, um die Write-Ahead-Log-Aufbewahrung (WAL) in der Quell-DB-Instance zu verwalten. Für jede regionsübergreifende Lesereplikat-Instance erstellt Amazon RDS einen physikalischen Replikations-Slot und weist ihn zu. Sie können die zwei Amazon CloudWatch-Metriken, Oldest Replication Slot Lag und Transaction Logs Disk Usage, verwenden, um zu sehen, wie weit das Replica mit der stärksten Verzögerung, in Bezug auf die erhaltenen WAL-Daten, zurückliegt und wie viel Speicherplatz von diesen WAL-Daten beansprucht wird. Der Wert Transaction Logs Disk Usage kann erheblich ansteigen, wenn ein regionsübergreifendes Lesereplikat signifikant verzögert ist.

Wenn die Arbeitslast in Ihrer DB-Instance eine große Menge an WAL-Daten generiert, müssen Sie möglicherweise die DB-Instance-Klasse Ihrer Quell-DB-Instance und Ihres Lesereplikats ändern. In diesem Fall ändern Sie sie in eine mit einer hohen Netzwerkleistung (10 Gbps), damit die Replica mithalten kann. Die Amazon CloudWatch-Metrik Transaction Logs Generation kann Ihnen helfen, die Schnelligkeitsrate zu verstehen, mit der Ihre Arbeitslast WAL-Daten generiert.

Sie können pg_replication_slots in der Quell-Instance abfragen, um den Status eines regionsübergreifenden Lesereplikats zu bestimmen, wie im folgenden Beispiel gezeigt wird:

postgres=# select * from pg_replication_slots; slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn _______________________________________________________________________________________________________________________________________________ rds_us_east_1_db_uzwlholddgpblksce6hgw4nkte | | physical | | | t | 12598 | | | 4E/95000060 (1 row)