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.
# Replikation mit Amazon Aurora PostgreSQL
Im Folgenden finden Sie Informationen zur Replikation mit Amazon Aurora PostgreSQL und wie Sie die logische Replikation überwachen und verwenden.
**Topics**
+ [Verwendung von Aurora-Replicas](#AuroraPostgreSQL.Replication.Replicas)
+ [Verbesserung der Leseverfügbarkeit von Aurora Replicas](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Überwachung einer Aurora PostgreSQL-Replikation](#AuroraPostgreSQL.Replication.Monitoring)
+ [Überblick über die logische Replikation von PostgreSQL mit Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Deaktivieren der logischen Replikation](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Überwachen des Write-Through-Caches und der logischen Slots für die logische Replikation in Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Beispiel: Verwenden der logischen Replikation mit DB-Clustern von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Beispiel: Logische Replikation mit Aurora PostgreSQL und AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Verwendung von Aurora-Replicas
Eine *Aurora Replica* ist ein unabhängiger Endpunkt in einem Aurora-DB-Cluster, die die beste Methode für das Skalieren von Leseoperationen und Erhöhen der Verfügbarkeit darstellen. Ein Aurora-DB-Cluster kann bis zu 15 Aurora Replicas enthalten, die sich in den Availability Zones der AWS Region des Aurora-DB-Clusters befinden.
Das DB-Cluster-Volume besteht aus mehreren Kopien der Daten für den DB-Cluster. Die Daten im Cluster-Volume werden jedoch als ein einzelnes logisches Volume der primären Writer-DB-Instance und der Aurora-Replicas im DB-Cluster dargestellt. Weitere Informationen über Aurora-Replicas finden Sie unter [Aurora-Replikate](Aurora.Replication.md#Aurora.Replication.Replicas).
Aurora Replicas eignen sich für das Skalieren von Lesevorgängen, da sie in Ihrem Cluster-Volume ausschließlich für Lesevorgänge bereitstehen. Schreibvorgänge werden von der Writer-DB-Instance verwaltet. Das Cluster-Volume wird von allen Instance in Ihrem Aurora PostgreSQL-DB-Cluster gemeinsam genutzt. Daher ist keine zusätzliche Arbeit erforderlich, um eine Kopie der Daten für jede Aurora Replica zu replizieren.
Mit Aurora PostgreSQL wird beim Löschen eines Aurora-Replica der Instance-Endpunkt sofort entfernt und das Aurora-Replica vom Leser-Endpunkt entfernt. Wenn Anweisungen vorhanden sind, die auf dem Aurora-Replica ausgeführt werden, das gerade gelöscht wird, besteht eine Übergangsfrist von drei Minuten. Vorhandene Anweisungen können während der Nachfrist geordnet beendet werden. Nach Ablauf der Nachfrist wird das Aurora-Replikat geschlossen und gelöscht.
Aurora PostgreSQL-DB-Cluster unterstützen Aurora Replicas in verschiedenen AWS Regionen unter Verwendung der globalen Aurora-Datenbank. Weitere Informationen finden Sie unter [Verwenden von Amazon Aurora Global Database](aurora-global-database.md).
**Anmerkung**
Mit der Leseverfügbarkeitsfunktion müssen Sie die Aurora-Replikate im DB-Cluster ggf. manuell neu starten. Für die DB-Cluster, die vor Einführung dieser Funktion erstellt wurden, werden durch einen Neustart der Writer-DB-Instance automatisch die Aurora Replicas neu gestartet. Durch den automatischen Neustart wird ein Einstiegspunkt wiederhergestellt, der die read/write Konsistenz im gesamten DB-Cluster gewährleistet.
## Verbesserung der Leseverfügbarkeit von Aurora Replicas
Aurora PostgreSQL verbessert die Leseverfügbarkeit im DB-Cluster, indem die Leseanforderungen kontinuierlich bearbeitet werden, wenn die Writer-DB-Instance neu gestartet wird oder wenn die Aurora Replica nicht mit dem Schreibverkehr Schritt halten kann.
Die Leseverfügbarkeitsfunktion ist standardmäßig in den folgenden Versionen von Aurora PostgreSQL verfügbar:
+ 16.1 und alle höheren Versionen
+ 15.2 und höhere 15-Versionen
+ 14.7 und höhere 14-Versionen
+ 13.10 und höhere 13-Versionen
+ 12.14 und höhere 12-Versionen
Die Leseverfügbarkeitsfunktion wird von der globalen Aurora-Datenbank in den folgenden Versionen unterstützt:
+ 16.1 und alle höheren Versionen
+ 15.4 und höhere 15-Versionen
+ 14.9 und höhere 14-Versionen
+ 13.12 und höhere Versionen (13)
+ 12.16 und höhere 12-Versionen
Um die Leseverfügbarkeitsfunktion für einen DB-Cluster zu verwenden, der vor der Einführung der Funktion in einer dieser Versionen erstellt wurde, starten Sie die Writer-Instance des DB-Clusters neu.
Wenn Sie statische Parameter Ihres DB-Clusters von Aurora PostgreSQL ändern, müssen Sie die Writer-Instance neu starten, damit die Parameteränderungen wirksam werden. Sie müssen beispielsweise die Writer-Instance neu starten, wenn Sie den Wert `shared_buffers` festlegen. Dank der Leseverfügbarkeitsfunktion von Aurora-Replikaten behält der DB-Cluster die verbesserte Verfügbarkeit bei, wodurch sich ein Neustart der Schreiber-Instance weniger stark auf ihn auswirkt. Die Reader-Instances werden nicht neu gestartet und antworten weiterhin auf die Leseanfragen. Um statische Parameteränderungen anzuwenden, starten Sie jede einzelne Reader-Instance neu.
Eine Aurora Replica eines DB-Clusters von Aurora PostgreSQL kann nach Replikationsfehlern wie Writer-Neustarts, Failover, langsamer Replikation und Netzwerkproblemen wiederhergestellt werden, indem sie nach einer erneuten Verbindung mit dem Writer schnell den In-Memory-Datenbankstatus wiederherstellt. Dieser Ansatz ermöglicht es Aurora-Replica-Instances, die Konsistenz mit den neuesten Speicher-Updates zu erreichen, solange die Client-Datenbank noch verfügbar ist.
Bei laufenden Transaktionen, die mit der Replikationswiederherstellung kollidieren, wird möglicherweise ein Fehler angezeigt, aber der Client kann diese Transaktionen erneut versuchen, sobald die Reader wieder mit dem Writer mithalten.
### Überwachen von Aurora Replicas
Sie können die Aurora Replicas bei der Wiederherstellung nach einer Writer-Unterbrechung überwachen. Verwenden Sie die folgenden Metriken, um nach den neuesten Informationen zur Reader-Instance zu suchen und um in Bearbeitung befindliche schreibgeschützte Transaktionen zu verfolgen.
+ Die `aurora_replica_status` Funktion wurde aktualisiert, sodass sie die meisten up-to-date Informationen für die Reader-Instanz zurückgibt, wenn diese noch verbunden ist. Der Zeitstempel der letzten Aktualisierung in `aurora_replica_status` ist für die Zeile, die der DB-Instance entspricht, auf der die Abfrage ausgeführt wird, immer leer. Dies bedeutet, dass die Reader-Instance über die neuesten Daten verfügt.
+ Wenn das Aurora Replica die Verbindung zur Writer-Instance trennt und wieder eine Verbindung herstellt, wird das folgende Datenbankereignis ausgelöst:
`Read replica has been disconnected from the writer instance and reconnected.`
+ Wenn eine schreibgeschützte Abfrage aufgrund eines Wiederherstellungskonflikts abgebrochen wird, wird möglicherweise eine oder mehrere der folgenden Fehlermeldungen im Datenbankfehlerprotokoll angezeigt:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Einschränkungen
Die folgenden Einschränkungen gelten für Aurora-Replikate mit der Leseverfügbarkeitsfunktion:
+ Aurora-Replikate des sekundären DB-Clusters können neu gestartet werden, wenn die Daten während der Replikationswiederherstellung nicht von der Schreiber-Instance gestreamt werden können.
+ Aurora Replicas unterstützen keine Online-Replikationswiederherstellung, wenn eine solche Wiederherstellung bereits läuft und neu gestartet wird.
+ Aurora Replicas werden neu gestartet, wenn sich Ihre DB-Instance dem Transaktions-ID-Wraparound nähert. Weitere Informationen zum Transaktions-ID-Wraparound finden Sie unter [Verhindern von Transaktions-ID-Wraparound-Fehlern](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ Aurora Replicas können unter bestimmten Umständen neu gestartet werden, wenn der Replikationsprozess blockiert ist.
## Überwachung einer Aurora PostgreSQL-Replikation
Skalieren von Lesevorgängen und hohe Verfügbarkeit hängen von der minimalen Verzögerungszeit ab. Sie können überwachen, wie weit eine Aurora Replica der Writer-DB-Instance Ihres Aurora PostgreSQL-DB-Clusters hinterherhinkt, indem Sie die Amazon-Metrik überwachen. CloudWatch `ReplicaLag` Da Aurora Replicas aus demselben Cluster-Volume wie die Writer-DB-Instance lesen, hat die `ReplicaLag`-Metrik für einen Aurora PostgreSQL-DB-Cluster eine andere Bedeutung. Die `ReplicaLag`-Metrik für eine Aurora Replica ermittelt die Verzögerung für den Seiten-Cache der Aurora Replica im Vergleich zu der der Writer-DB-Instance.
Weitere Informationen zur Überwachung von RDS-Instances und CloudWatch -Metriken finden Sie unter. [Überwachung von Metriken in einem Amazon-Aurora-Cluster](MonitoringAurora.md)
# Überblick über die logische Replikation von PostgreSQL mit Aurora
Durch die Verwendung der logischen Replikationsfunktion von PostgreSQL mit Ihrem DB-Cluster von Aurora PostgreSQL können Sie einzelne Tabellen statt der gesamten Datenbank-Instance replizieren und synchronisieren. Für die logische Replikation wird ein Veröffentlichungs- und Abonnementmodell verwendet, um Änderungen aus einer Quelle an einen oder mehrere Empfänger zu replizieren. Dazu werden Änderungsdatensätze aus dem Write-Ahead-Protokoll (WAL) von PostgreSQL verwendet. Die Quelle oder der *Herausgeber* sendet WAL-Daten für die angegebenen Tabellen an einen oder mehrere Empfänger (*Abonnenten*). Dadurch werden die Änderungen repliziert und die Tabelle eines Abonnenten wird mit der Tabelle des Herausgebers synchronisiert. Die Änderungen des Herausgebers werden anhand einer *Veröffentlichung* identifiziert. Abonnenten erhalten die Änderungen, indem sie ein *Abonnement* erstellen, das die Verbindung mit der Datenbank des Herausgebers und den entsprechenden Veröffentlichungen definiert. Ein *Replikationsslot* ist der Mechanismus, der in diesem Schema verwendet wird, um den Fortschritt eines Abonnements zu verfolgen.
Bei DB-Clustern von Aurora PostgreSQL werden die WAL-Datensätze im Aurora-Speicher abgelegt. Der DB-Cluster von Aurora PostgreSQL, der in einem logischen Replikationsszenario als Herausgeber fungiert, liest die WAL-Daten aus dem Aurora-Speicher, dekodiert sie und sendet sie an den Abonnenten, sodass die Änderungen auf die Tabelle in dieser Instance angewendet werden können. Der Herausgeber verwendet einen *logischen Decoder*, um die Daten für die Verwendung durch Abonnenten zu dekodieren. Standardmäßig verwenden DB-Cluster von Aurora PostgreSQL beim Senden von Daten das native `pgoutput`-Plugin von PostgreSQL. Es sind auch andere logische Decoder verfügbar. Zum Beispiel unterstützt Aurora PostgreSQL auch das `[wal2json](https://github.com/eulerto/wal2json)`-Plugin, das WAL-Daten in JSON konvertiert.
Ab Aurora PostgreSQL Version 14.5, 13.8, 12.12 und 11.17 erweitert Aurora PostgreSQL den logischen Replikationsprozess von PostgreSQL um einen *Write-Through-Cache*, um die Leistung zu verbessern. Die WAL-Transaktionsprotokolle werden lokal in einem Puffer zwischengespeichert, um die Menge an Festplatten-I/O zu reduzieren, d. h. es wird während der logischen Dekodierung aus dem Aurora-Speicher gelesen. Der Write-Through-Cache wird standardmäßig verwendet, wenn Sie die logische Replikation für Ihren DB-Cluster von Aurora PostgreSQL verwenden. Aurora bietet mehrere Funktionen, mit denen Sie den Cache verwalten können. Weitere Informationen finden Sie unter [Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
Die logische Replikation wird von allen derzeit verfügbaren Aurora-PostgreSQL-Versionen unterstützt. Weitere Informationen finden Sie unter [Aktualisierungen von Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) im Abschnitt *Versionshinweise für Aurora PostgreSQL*.
Die logische Replikation wird von Babelfish für Aurora PostgreSQL in den folgenden Versionen unterstützt:
+ 15.7 und höhere Versionen
+ 16.3 und höhere Versionen
**Anmerkung**
Zusätzlich zu der in PostgreSQL 10 eingeführten nativen logischen Replikationsfunktion von PostgreSQL unterstützt Aurora PostgreSQL auch die `pglogical`-Erweiterung. Weitere Informationen finden Sie unter [Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Weitere Informationen über die logische Replikation in PostgreSQL finden Sie unter [Logical Replication](https://www.postgresql.org/docs/current/logical-replication.html) (Logische Replikation) und [Logical Decoding Concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) (Logische Dekodierungskonzepte) in der PostgreSQL-Dokumentation.
**Anmerkung**
PostgreSQL 16 hat Unterstützung für die logische Dekodierung von Read Replicas hinzugefügt. Diese Funktion wird in Aurora PostgreSQL nicht unterstützt.
# Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL
Für das Einrichten der logischen Replikation sind `rds_superuser`-Berechtigungen erforderlich. Ihr DB-Cluster von Aurora PostgreSQL muss für die Verwendung einer benutzerdefinierten DB-Cluster-Parametergruppe konfiguriert sein, damit Sie die erforderlichen Parameter wie im folgenden Verfahren beschrieben festlegen können. Weitere Informationen finden Sie unter [DB-Cluster-Parametergruppen für Amazon-Aurora-DB-Cluster](USER_WorkingWithDBClusterParamGroups.md).
**So richten Sie die logische Replikation von PostgreSQL für einen DB-Cluster von Aurora PostgreSQL ein**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie Ihren DB-Cluster von Aurora PostgreSQL im Navigationsbereich aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration). Suchen Sie in den Instance-Details den Link **Parametergruppe** mit der **DB-Cluster-Parametergruppe** als **Typ**.
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Cluster von Aurora PostgreSQL zugeordnet sind.
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `rds` ein, um den `rds.logical_replication`-Parameter zu finden. Der Standardwert für diesen Parameter ist `0`, was bedeutet, dass er standardmäßig deaktiviert ist.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen. Wählen Sie dann `1` aus der Auswahl aus, um die Funktion zu aktivieren. Abhängig von Ihrer erwarteten Auslastung müssen Sie möglicherweise auch die Einstellungen für die folgenden Parameter ändern. In vielen Fällen sind die Standardwerte jedoch ausreichend.
+ `max_replication_slots`: Legen Sie diesen Parameter auf einen Wert fest, der mindestens der geplanten Gesamtzahl der Veröffentlichungen und Abonnements der logischen Replikation entspricht. Wenn Sie verwenden AWS DMS, sollte dieser Parameter mindestens Ihren geplanten Change-Data-Capture-Aufgaben aus dem Cluster sowie Veröffentlichungen und Abonnements für logische Replikation entsprechen.
+ `max_wal_senders`und `max_logical_replication_workers` — Stellen Sie diese Parameter auf einen Wert ein, der mindestens der Anzahl der logischen Replikationsslots entspricht, die Sie aktiv sein möchten, oder der Anzahl der aktiven AWS DMS Aufgaben für die Datenänderungserfassung. Wenn Sie einen logischen Replikationsslot inaktiv lassen, wird die Bereinigung durch Entfernen überholter Tupel aus Tabellen verhindert. Wir empfehlen daher, Replikationsslots zu überwachen und inaktive Slots nach Bedarf zu entfernen.
+ `max_worker_processes`: Legen Sie diesen Parameter auf einen Wert fest, der mindestens der Summe der Werte `max_logical_replication_workers`, `autovacuum_max_workers` und `max_parallel_workers` entspricht. Bei kleinen DB-Instance-Klassen können sich Hintergrund-Workerprozesse auf Anwendungs-Workloads auswirken. Überwachen Sie daher die Leistung Ihrer Datenbank, wenn Sie `max_worker_processes` höher als den Standardwert festlegen. (Der Standardwert ist das Ergebnis von `GREATEST(${DBInstanceVCPU*2},8}`, was bedeutet, dass dies standardmäßig entweder 8 oder doppelt so hoch ist wie das CPU-Äquivalent der DB-Instance-Klasse, je nachdem, welcher Wert größer ist).
**Anmerkung**
Sie können die Parameterwerte in einer benutzerdefinierten DB-Parametergruppe ändern. Die Parameterwerte in einer Standard-DB-Parametergruppe können nicht geändert werden.
1. Wählen Sie **Änderungen speichern ** aus.
1. Starten Sie die Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL neu, damit Ihre Änderungen wirksam werden. Wählen Sie in der Amazon-RDS-Konsole die primäre DB-Instance des Clusters und dann im Menü **Actions** (Aktionen) die Option **Reboot** (Neustart) aus.
1. Wenn die Instance verfügbar ist, können Sie wie folgt überprüfen, ob die logische Replikation aktiviert ist.
1. Verwenden Sie `psql`, um eine Verbindung mit der Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL herzustellen.
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Stellen Sie mithilfe des folgenden Befehls sicher, dass die logische Replikation aktiviert wurde.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. Überprüfen Sie, dass `wal_level` auf `logical` festgelegt ist.
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
Ein Beispiel für die Verwendung der logischen Replikation, um eine Datenbanktabelle mit Änderungen aus einem Quell-DB-Cluster von Aurora PostgreSQL zu synchronisieren, finden Sie unter [Beispiel: Verwenden der logischen Replikation mit DB-Clustern von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# Deaktivieren der logischen Replikation
Nachdem Sie Ihre Replikationsaufgaben abgeschlossen haben, sollten Sie den Replikationsprozess beenden, Replikationsslots löschen und die logische Replikation deaktivieren. Bevor Sie Slots löschen, vergewissern Sie sich, dass diese nicht mehr benötigt werden. Aktive Replikationsslots können nicht gelöscht werden.
**So deaktivieren Sie die logische Replikation**
1. Löschen Sie alle Replikations-Slots.
Wenn Sie alle Replikationsslots löschen möchten, stellen Sie eine Verbindung zum Herausgeber her und führen Sie den folgenden SQL-Befehl aus.
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
Die Replikationsslots dürfen nicht aktiv sein, wenn Sie diesen Befehl ausführen.
1. Ändern Sie die dem Herausgeber zugeordnete benutzerdefinierte DB-Cluster-Parametergruppe, wie in [Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md) beschrieben. Legen Sie den `rds.logical_replication`-Parameter jedoch auf 0 fest.
Weitere Informationen zu benutzerdefinierten DB-Parametergruppen finden Sie unter [Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Starten Sie den Herausgeber-DB-Cluster von Aurora PostgreSQL neu, damit die Änderung des `rds.logical_replication`-Parameters wirksam wird.
# Überwachen des Write-Through-Caches und der logischen Slots für die logische Replikation in Aurora PostgreSQL
Überwachen Sie den Write-Through-Cache für die logische Replikation und verwalten Sie die logischen Slots, um die Leistung Ihres DB-Clusters in Aurora PostgreSQL zu verbessern. Im Folgenden finden Sie weitere Informationen zum Write-Through-Cache und zu den logischen Slots.
**Topics**
+ [Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Verwalten logischer Slots für Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Überwachen des Write-Through-Caches für die logische Replikation in Aurora PostgreSQL
Standardmäßig verwenden die Aurora-PostgreSQL-Versionen 14.5, 13.8, 12.12 und 11.17 und höher einen Write-Through-Cache, um die Leistung für die logische Replikation zu verbessern. Ohne den Write-Through-Cache verwendet Aurora PostgreSQL die Aurora-Speicherschicht bei der Implementierung des nativen logischen PostgreSQL-Replikationsprozesses. Dazu schreibt es WAL-Daten in den Speicher und liest die Daten dann wieder aus dem Speicher, um sie zu dekodieren und an ihre Ziele (Abonnenten) zu senden (zu replizieren). Dies kann zu Engpässen bei der logischen Replikation für DB-Cluster von Aurora PostgreSQL führen.
Der Write-Through-Cache minimiert die Abhängigkeit von der Aurora-Speicherschicht. Statt fortlaufender Schreib- und Lesezugriffe auf diese Schicht nutzt Aurora PostgreSQL einen Puffer, der den logischen WAL-Stream für die Replikation zwischenspeichert und so Festplattenzugriffe reduziert. Dieser Puffer ist der native PostgreSQL-Cache, der in der logischen Replikation verwendet wird. Er wird in den DB-Cluster-Parametern von Aurora PostgreSQL als `rds.logical_wal_cache` identifiziert.
Wenn Sie die logische Replikation mit Ihrem DB-Cluster von Aurora PostgreSQL verwenden (für die Versionen, die den Write-Through-Cache unterstützen), können Sie die Cache-Trefferrate überwachen, um festzustellen, wie gut sie für Ihren Anwendungsfall funktioniert. Stellen Sie dazu mit `psql` eine Verbindung mit der Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL her und verwenden Sie dann die Aurora-Funktion `aurora_stat_logical_wal_cache`, wie im folgenden Beispiel gezeigt.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
Die Funktion gibt beispielsweise die folgende Ausgabe zurück.
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
Die `last_reset_timestamp`-Werte wurden aus Gründen der Lesbarkeit gekürzt. Weitere Informationen zu dieser Funktion finden Sie unter [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL bietet die beiden folgenden Funktionen zur Überwachung des Write-Through-Cache.
+ Die `aurora_stat_logical_wal_cache`-Funktion – Die Referenzdokumentation finden Sie unter [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ Die `aurora_stat_reset_wal_cache`-Funktion – Die Referenzdokumentation finden Sie unter [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
Wenn Sie feststellen, dass die automatisch angepasste WAL-Cache-Größe für Ihre Workloads nicht ausreicht, können Sie den Wert von `rds.logical_wal_cache` manuell ändern. Berücksichtigen Sie dabei Folgendes:
+ Wenn der Parameter `rds.logical_replication` deaktiviert ist, wird `rds.logical_wal_cache` auf Null (0) gesetzt.
+ Wenn der Parameter `rds.logical_replication` aktiviert ist, hat `rds.logical_wal_cache` einen Standardwert von 16 MB.
+ Der Parameter `rds.logical_wal_cache` ist statisch und erfordert einen Neustart der Datenbank-Instance, damit Änderungen wirksam werden. Dieser Parameter ist in Form von 8-KB-Blöcken definiert. Beachten Sie, dass jeder positive Wert unter 32 KB als 32 KB behandelt wird. Weitere Informationen über `wal_buffers` finden Sie unter [Write-Ahead-Protokoll](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) in der PostgreSQL-Dokumentation.
## Verwalten logischer Slots für Aurora PostgreSQL
Streaming-Aktivitäten werden in der `pg_replication_origin_status`-Ansicht erfasst. Wenn Sie den Inhalt dieser Ansicht anzeigen möchten, können Sie die `pg_show_replication_origin_status()`-Funktion verwenden, wie im Folgenden gezeigt:
```
SELECT * FROM pg_show_replication_origin_status();
```
Sie können eine Liste Ihrer logischen Slots mit der folgenden SQL-Abfrage abrufen.
```
SELECT * FROM pg_replication_slots;
```
Zum Löschen eines logischen Slots können Sie den `pg_drop_replication_slot` mit dem Namen des Slots verwenden, wie im folgenden Befehl gezeigt.
```
SELECT pg_drop_replication_slot('test_slot');
```
# Beispiel: Verwenden der logischen Replikation mit DB-Clustern von Aurora PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Clustern von Aurora PostgreSQL starten. Sowohl der Herausgeber als auch der Abonnent müssen für die logische Replikation konfiguriert sein, wie unter [Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md) beschrieben.
Der DB-Cluster von Aurora PostgreSQL, der der designierte Herausgeber ist, muss ebenfalls Zugriff auf den Replikationsslot gewähren. Ändern Sie dazu die Sicherheitsgruppe, die der Virtual Public Cloud (VPC) des DB-Clusters von Aurora PostgreSQL zugeordnet ist, basierend auf dem Amazon-VPC-Service. Erlauben Sie eingehenden Zugriff, indem Sie die Sicherheitsgruppe, die der VPC des Abonnenten zugeordnet ist, zur Sicherheitsgruppe des Herausgebers hinzufügen. Weitere Informationen finden Sie unter [Kontrollieren des Datenverkehrs zu Ressourcen mithilfe von Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im *Benutzerhandbuch von Amazon VPC*.
Nachdem diese vorbereitenden Schritte abgeschlossen sind, können Sie die PostgreSQL-Befehle `CREATE PUBLICATION` auf dem Herausgeber und `CREATE SUBSCRIPTION` auf dem Abonnenten verwenden, wie im folgenden Verfahren beschrieben.
**So starten Sie den logischen Replikationsprozess zwischen zwei DB-Clustern von Aurora PostgreSQL**
Bei diesen Schritten wird davon ausgegangen, dass Ihre DB-Cluster von Aurora PostgreSQL über eine Writer-Instance mit einer Datenbank verfügen, in der die Beispieltabellen erstellt werden können.
1. **Auf dem Herausgeber-DB-Cluster von Aurora PostgreSQL**
1. Erstellen Sie mit der folgenden SQL-Anweisung eine Tabelle.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Fügen Sie mit der folgenden SQL-Anweisung Daten in die Herausgebertabelle ein.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Stellen Sie sicher, dass Daten in der Tabelle vorhanden sind, indem Sie die folgende SQL-Anweisung verwenden.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Erstellen Sie eine Veröffentlichung für diese Tabelle, indem Sie die `CREATE PUBLICATION`-Anweisung wie folgt verwenden.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **Auf dem Abonnenten-DB-Cluster von Aurora PostgreSQL**
1. Erstellen Sie wie folgt dieselbe `LogicalReplicationTest`-Tabelle auf dem Abonnenten, die Sie auf dem Herausgeber erstellt haben.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Stellen Sie sicher, dass diese Tabelle leer ist.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Erstellen Sie ein Abonnement, um die Änderungen vom Herausgeber zu erhalten. Sie müssen die folgenden Details über den Herausgeber-DB-Cluster von Aurora PostgreSQL verwenden.
+ **host** – Die Writer-DB-Instance des Herausgeber-DB-Clusters von Aurora PostgreSQL.
+ **port** – Der Port, den die Writer-DB-Instance überwacht. Der Standardwert für PostgreSQL lautet 5432.
+ **dbname** – Der Name der Datenbank.
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**Anmerkung**
Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.
Nachdem das Abonnement erstellt wurde, wird für den Herausgeber ein Slot für die logische Replikation erstellt.
1. Um für dieses Beispiel zu überprüfen, dass das Anfangsdatum für den Abonnenten repliziert wird, verwenden Sie die folgende SQL-Anweisung für die Abonnenten-Datenbank.
```
SELECT count(*) FROM LogicalReplicationTest;
```
Alle weiteren Änderungen am Herausgeber werden beim Abonnenten repliziert.
Durch die logische Replikation wird die Leistung beeinträchtigt. Es wird empfohlen, die logische Replikation zu deaktivieren, nachdem Ihre Replikationsaufgaben abgeschlossen sind.
# Beispiel: Logische Replikation mit Aurora PostgreSQL und AWS Database Migration Service
Sie können das AWS Database Migration Service (AWS DMS) verwenden, um eine Datenbank oder einen Teil einer Datenbank zu replizieren. Wird verwendet AWS DMS , um Ihre Daten von einer Aurora PostgreSQL-Datenbank in eine andere Open Source- oder kommerzielle Datenbank zu migrieren. Weitere Informationen AWS DMS dazu finden Sie im [AWS Database Migration Service Benutzerhandbuch](https://docs.aws.amazon.com/dms/latest/userguide/).
Das folgende Beispiel zeigt, wie die logische Replikation von einer Aurora PostgreSQL-Datenbank als Herausgeber eingerichtet und dann AWS DMS für die Migration verwendet wird. In diesem Beispiel werden der gleiche Herausgeber und Abonnent verwendet, die unter erstellt wurde [Beispiel: Verwenden der logischen Replikation mit DB-Clustern von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
Um die logische Replikation mit einzurichten AWS DMS, benötigen Sie Details zu Ihrem Herausgeber und Abonnenten von Amazon RDS. Insbesondere benötigen Sie Details zur Writer-DB-Instance des Herausgebers und zur DB-Instance des Abonnenten.
Fordern Sie die folgenden Informationen für die Writer-DB-Instance des Herausgebers an:
+ Die ID der Virtual Private Cloud (VPC)
+ Die Subnetzgruppe
+ Die Availability Zone (AZ)
+ Die VPC-Sicherheitsgruppe
+ Die ID der DB-Instance
Fordern Sie die folgenden Informationen für die DB-Instance des Herausgebers an:
+ Die ID der DB-Instance
+ Die Quell-Engine
**Zur Verwendung AWS DMS für die logische Replikation mit Aurora PostgreSQL**
1. Bereiten Sie die Herausgeberdatenbank für die Arbeit vor. AWS DMS
Hierzu müssen Sie bei PostgreSQL-Datenbanken der Version 10.x und höher AWS DMS -Wrapper-Funktionen auf die Datenbank des Herausgebers anwenden. Einzelheiten hierzu und weitere Schritte finden Sie in den Anweisungen unter [Verwenden von PostgreSQL-Version 10.x und höher als Quelle für AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) im *AWS Database Migration Service -Benuterhandbuch.*
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS DMS Konsole unter[https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2). Wählen Sie oben rechts dieselbe AWS Region aus, in der sich der Herausgeber und der Abonnent befinden.
1. Erstellen Sie eine AWS DMS Replikationsinstanz.
Wählen Sie Werte, die mit denen für die Writer-DB-Instance des Herausgebers identisch sind. Dazu gehören die folgenden Einstellungen:
+ Wählen Sie unter **VPC** dasselbe VPC wie für die Writer-DB-Instance aus.
+ Wählen Sie für **Replikations-Subnetzgruppe** eine Subnetzgruppe mit denselben Werten wie die Writer-DB-Instance aus. Erstellen Sie bei Bedarf eine Neue.
+ Wählen Sie unter **Availability zone (Availability Zone)** dieselbe Zone wie für die Writer-DB-Instance aus.
+ Wählen Sie unter **VPC Security Group (VPC-Sicherheitsgruppe)** dieselbe Gruppe wie für die Writer-DB-Instance aus.
1. Erstellen Sie einen AWS DMS Endpunkt für die Quelle.
Geben Sie unter Verwendung der folgenden Einstellungen den Herausgeber als Quellendpunkt an:
+ Wählen Sie unter **Endpoint type (Endpunkttyp)** die Option **Source endpoint (Quellendpunkt)** aus.
+ Wählen Sie **Select RDS DB Instance (RDS-DB-Instance auswählen)**.
+ Wählen Sie unter **RDS Instance (RDS-Instance)** die DB-Kennung der Writer-DB-Instance des Herausgebers aus.
+ Wählen Sie unter **Source engine (Quellen-Engine)** die Option **postgres** aus.
1. Erstellen Sie einen AWS DMS Endpunkt für das Ziel.
Geben Sie den Abonnenten unter Verwendung der folgenden Einstellungen als Zielendpunkt an:
+ Wählen Sie unter **Endpoint type (Endpunkttyp)** die Option **Target endpoint (Zielendpunkt)** aus.
+ Wählen Sie **Select RDS DB Instance (RDS-DB-Instance auswählen)**.
+ Wählen Sie unter **RDS Instance (RDS-Instance)** die DB-Kennung der Abonnenten-DB-Instance aus.
+ Wählen Sie einen Wert für **Source engine (Quell-Engine)** aus. Beispiel: Wenn der Abonnent eine RDS-PostgreSQL-Datenbank ist, wählen Sie **postgres**. Wenn der Subscriber eine Aurora PostgreSQL-Datenbank ist, wählen Sie **aurora-postgresql** aus.
1. Erstellen Sie eine AWS DMS Datenbankmigrationsaufgabe.
Sie geben mit der Datenbankmigrationsaufgabe an, welche Datenbanktabelle migriert werden sollen, um Daten mithilfe des Zielschemas zuzuordnen und um neue Tabellen für die Zieldatenbank zu erstellen. Verwenden Sie zumindest die folgenden Einstellungen für **Task configuration (Aufgabenkonfiguration)**:
+ Wählen Sie unter **Replication instance (Replikations-Instance)** die Replikations-Instance aus, die Sie in einem früheren Schritt erstellt haben.
+ Wählen Sie unter **Source database endpoint (Quelldatenbank-Endpunkt)** die Herausgeberquelle aus, die Sie in einem früheren Schritt erstellt haben.
+ Wählen Sie unter **Target database endpoint (Zieldatenbank-Endpunkt)** das Abonnentenziel aus, das Sie in einem früheren Schritt erstellt haben.
Die übrigen Aufgabendetails sind von Ihrem Migrationsprojekt abhängig. Weitere Informationen zur Angabe aller Details für DMS-Aufgaben finden Sie im *AWS Database Migration Service Benutzerhandbuch* unter [Arbeiten mit AWS DMS-Aufgaben](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html).
Nachdem die Aufgabe AWS DMS erstellt wurde, beginnt sie mit der Migration der Daten vom Herausgeber zum Abonnenten.
# Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen
Ab Aurora PostgreSQL Version 11 und höher können Sie die AWS Identity and Access Management (IAM) -Authentifizierung für Replikationsverbindungen verwenden. Diese Funktion erhöht die Sicherheit, da Sie den Datenbankzugriff mithilfe von IAM-Rollen anstelle von Passwörtern verwalten können. Sie funktioniert auf Clusterebene und folgt demselben Sicherheitsmodell wie die Standard-IAM-Authentifizierung.
Die IAM-Authentifizierung für Replikationsverbindungen ist eine optionale Funktion. Um sie zu aktivieren, setzen Sie den `rds.iam_auth_for_replication` Parameter `1` in Ihrer DB-Cluster-Parametergruppe auf. Da es sich um einen dynamischen Parameter handelt, muss Ihr DB-Cluster nicht neu gestartet werden, sodass Sie die IAM-Authentifizierung für bestehende Workloads ohne Ausfallzeiten nutzen können. Bevor Sie diese Funktion aktivieren können, müssen Sie die unten [Voraussetzungen](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) aufgeführten Voraussetzungen erfüllen.
## Voraussetzungen
Um die IAM-Authentifizierung für Replikationsverbindungen verwenden zu können, müssen Sie alle der folgenden Anforderungen erfüllen:
+ Ihr Aurora PostgreSQL-DB-Cluster muss Version 11 oder höher sein.
+ Auf Ihrem Publisher-Aurora-PostgreSQL-DB-Cluster:
+ Aktivieren Sie die IAM-Datenbankauthentifizierung.
Weitere Informationen finden Sie unter [Aktivieren und Deaktivieren der IAM-Datenbank-Authentifizierung](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Aktivieren Sie die logische Replikation, indem Sie den `rds.logical_replication` Parameter auf `1` setzen.
Weitere Informationen finden Sie unter [Einrichten der logischen Replikation für Ihren DB-Cluster von Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Bei der logischen Replikation ist der Herausgeber der Aurora PostgreSQL-Quell-DB-Cluster, der Daten an Abonnentencluster sendet. Weitere Informationen finden Sie unter [Überblick über die logische PostgreSQL-Replikation mit Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**Anmerkung**
Sowohl die IAM-Authentifizierung als auch die logische Replikation müssen auf Ihrem Publisher-Aurora-PostgreSQL-DB-Cluster aktiviert sein. Wenn eine der beiden Optionen nicht aktiviert ist, können Sie die IAM-Authentifizierung nicht für Replikationsverbindungen verwenden.
## Aktivieren der IAM-Authentifizierung für Replikationsverbindungen
Gehen Sie wie folgt vor, um die IAM-Authentifizierung für die Replikationsverbindung zu aktivieren.
1. Stellen Sie sicher, dass Ihr Aurora PostgreSQL-DB-Cluster alle Voraussetzungen für die IAM-Authentifizierung mit Replikationsverbindungen erfüllt. Details hierzu finden Sie unter [Voraussetzungen](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Konfigurieren Sie den `rds.iam_auth_for_replication` Parameter, indem Sie Ihre DB-Cluster-Parametergruppe ändern:
+ Stellen Sie den Parameter `rds.iam_auth_for_replication` auf `1` ein. Für diesen dynamischen Parameter ist kein Neustart erforderlich.
1. Connect zu Ihrer Datenbank her und weisen Sie Ihrem Replikationsbenutzer die erforderlichen Rollen zu:
Die folgenden SQL-Befehle gewähren die erforderlichen Rollen, um die IAM-Authentifizierung für Replikationsverbindungen zu aktivieren:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Nachdem Sie diese Schritte abgeschlossen haben, muss der angegebene Benutzer die IAM-Authentifizierung für Replikationsverbindungen verwenden.
**Wichtig**
Wenn Sie die Funktion aktivieren, müssen Benutzer mit `rds_replication` Rollen `rds_iam` sowohl als auch die IAM-Authentifizierung für Replikationsverbindungen verwenden. Dies gilt unabhängig davon, ob die Rollen dem Benutzer direkt zugewiesen oder über andere Rollen vererbt wurden.
## Deaktivierung der IAM-Authentifizierung für Replikationsverbindungen
Sie können die IAM-Authentifizierung für Replikationsverbindungen mit einer der folgenden Methoden deaktivieren:
+ Setzen Sie den `rds.iam_auth_for_replication` Parameter `0` in Ihrer DB-Cluster-Parametergruppe auf
+ Alternativ können Sie eine dieser Funktionen in Ihrem Aurora PostgreSQL-DB-Cluster deaktivieren:
+ Deaktivieren Sie die logische Replikation, indem Sie den Parameter auf `rds.logical_replication` setzen `0`
+ Deaktivieren Sie die IAM-Authentifizierung
Wenn Sie die Funktion deaktivieren, können Replikationsverbindungen Datenbankkennwörter für die Authentifizierung verwenden, sofern sie konfiguriert sind.
**Anmerkung**
Replikationsverbindungen für Benutzer ohne die `rds_iam` Rolle können die Kennwortauthentifizierung verwenden, auch wenn die Funktion aktiviert ist.
## Einschränkungen und Überlegungen
Die folgenden Einschränkungen und Überlegungen gelten für die Verwendung der IAM-Authentifizierung für Replikationsverbindungen.
+ Die IAM-Authentifizierung für Replikationsverbindungen ist nur für Aurora PostgreSQL Versionen 11 und höher verfügbar.
+ Der Herausgeber muss die IAM-Authentifizierung für Replikationsverbindungen unterstützen.
+ Das IAM-Authentifizierungstoken läuft standardmäßig nach 15 Minuten ab. Möglicherweise müssen Sie lang andauernde Replikationsverbindungen aktualisieren, bevor das Token abläuft.