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 PostgreSQL-Funktionen, die von Amazon RDS für PostgreSQL unterstützt werden Amazon RDS für PostgreSQL unterstützt viele der am häufigsten verwendeten PostgreSQL-Funktionen. PostgreSQL verfügt beispielsweise über eine Selbstbereinigungsfunktion, die die routinemäßige Wartung der Datenbank durchführt. Die Autovakuierungsfunktion ist standardmäßig aktiviert. Obwohl Sie diese Funktion deaktivieren können, empfehlen wir dringend, sie eingeschaltet zu lassen. Diese Funktion zu verstehen und was Sie tun können, um sicherzustellen, dass sie so funktioniert, wie sie sollte, ist eine grundlegende Aufgabe eines jeden DBA. Weitere Informationen zur Selbstbereinigung finden Sie unter [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Weitere Informationen zu anderen gängigen DBA-Aufgaben finden Sie unter [Häufige DBA-Aufgaben für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md). RDS für PostgreSQL unterstützt auch Erweiterungen, die der DB-Instance wichtige Funktionen hinzufügen. Sie können beispielsweise die PostGIS-Erweiterung verwenden, um mit räumlichen Daten zu arbeiten, oder die Erweiterung pg\$1cron verwenden, um die Wartung innerhalb der Instance zu planen. Weitere Informationen zu PostgreSQL-Erweiterungen finden Sie unter [Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md). Fremddaten-Wrapper sind eine bestimmte Art von Erweiterung, die dazu dient, dass Ihre DB-Instance von RDS für PostgreSQL mit anderen kommerziellen Datenbanken oder Datentypen arbeiten kann. Weitere Informationen zu Fremddaten-Wrappern, die von RDS für PostgreSQL unterstützt werden, finden Sie unter [Arbeiten mit den unterstützten Fremddaten-Wrapper für Amazon RDS für PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md). Nachfolgend finden Sie Informationen über einige andere Funktionen, die von RDS für PostgreSQL unterstützt werden. **Topics** + [ # Benutzerdefinierte Datentypen und Aufzählungen mit RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md) + [ # Ereignisauslöser für RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md) + [ # Huge Pages für RDS für PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md) + [ # Ausführen der logischen Replikation für Amazon RDS für PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md) + [ # Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen ](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md) + [ # RAM-Datenträger für das stats\$1temp\$1directory ](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md) + [ # Tablespaces für RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md) + [ # RDS-für-PostgreSQL-Kollatierungen für EBCDIC- und andere Mainframe-Migrationen ](PostgreSQL.Collations.mainframe.migration.md) + [ # Verwalten der logischen Slot-Synchronisation für RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md) # Benutzerdefinierte Datentypen und Aufzählungen mit RDS for PostgreSQL PostgreSQL unterstützt das Erstellen benutzerdefinierter Datentypen und das Arbeiten mit Aufzählungen. Weitere Informationen zum Erstellen von und zum Arbeiten mit Aufzählungen und anderen Datentypen finden Sie unter [Enumerated types](https://www.postgresql.org/docs/14/datatype-enum.html) (Aufzählungstypen) in der PostgreSQL-Dokumentation. Im Folgenden finden Sie ein Beispiel für das Erstellen eines Typs als Aufzählung und das anschließende Einfügen von Werten in eine Tabelle. ``` CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple'); CREATE TYPE CREATE TABLE t1 (colors rainbow); CREATE TABLE INSERT INTO t1 VALUES ('red'), ( 'orange'); INSERT 0 2 SELECT * from t1; colors -------- red orange (2 rows) postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson'; ALTER TYPE postgres=> SELECT * from t1; colors --------- crimson orange (2 rows) ``` # Ereignisauslöser für RDS for PostgreSQL Alle aktuellen PostgreSQL-Versionen unterstützen Ereignisauslöser, ebenso alle verfügbaren Versionen von RDS for PostgreSQL. Sie können das Hauptbenutzerkonto nutzen (Standard, `postgres`), um Ereignisauslöser zu erstellen, zu ändern, umzubenennen und zu löschen. Ereignisauslöser befinden sich auf DB-Instance-Level und können so auf alle Datenbanken einer Instance angewendet werden. Mit dem folgenden Code wird beispielsweise ein Ereignisauslöser erstellt, der den aktuellen Benutzer am Ende jedes DDL-Befehls (Data Definition Language, Datendefinitionssprache) ausgibt. ``` CREATE OR REPLACE FUNCTION raise_notice_func() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN RAISE NOTICE 'In trigger function: %', current_user; END; $$; CREATE EVENT TRIGGER event_trigger_1 ON ddl_command_end EXECUTE PROCEDURE raise_notice_func(); ``` Weitere Informationen über PostgreSQL-Ereignisauslöser finden Sie unter [Event Triggers](https://www.postgresql.org/docs/current/static/event-triggers.html) in der PostgreSQL-Dokumentation. Bei der Verwendung von PostgreSQL-Ereignisauslösern in Amazon RDS gibt es einige Einschränkungen. Diese umfassen u. a. folgende: + Auf Read Replicas können keine Ereignisauslöser erstellt werden. Sie können jedoch Ereignisauslöser auf einer Read Replica-Quelle erstellen. Die Ereignisauslöser werden dann in die Read Replica kopiert. Die Ereignisauslöser auf der Read Replica werden nicht bei Änderungen, die von der Quelle ausgehen, ausgelöst. Wenn jedoch die Read Replica verwendet wird, werden die vorhandenen Ereignisauslöser bei Datenbank-Operationen ausgelöst. + Um das Upgrade einer Hauptversion für eine PostgreSQL-DB-Instance durchzuführen, für die ein Ereignisauslöser verwendet wird, müssen Sie vor dem Upgraden der Instance die Ereignisauslöser löschen. # Huge Pages für RDS für PostgreSQL *Huge Pages* ist eine Arbeitsspeicher-Verwaltungsfunktion, die den Overhead reduziert, wenn eine DB-Instance mit großen, zusammenhängenden Arbeitsspeicherblöcken arbeitet, wie sie von gemeinsam genutzten Puffern verwendet werden. Diese PostgreSQL-Funktion wird von allen derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützt. Sie können große Seiten für Ihre Anwendung zuordnen, indem Sie Aufrufe des freigegebenen Speichers `mmap` oder `SYSV` verwenden. RDS für PostgreSQL unterstützt Seitengrößen von sowohl 4 KB als auch 2 MB. Sie können Huge Pages ein- oder ausschalten, indem Sie den Wert des `huge_pages`-Parameters ändern. Die Funktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium. RDS für PostgreSQL verwendet Huge Pages basierend auf dem verfügbaren gemeinsam genutzten Arbeitsspeicher. Wenn die DB-Instance aufgrund von Einschränkungen des gemeinsam genutzten Speichers keine großen Seiten verwenden kann, hindert Amazon RDS die DB-Instance am Starten. In diesem Fall legt Amazon RDS den Status der DB-Instance auf einen nicht kompatiblen Parameterstatus fest. In diesem Fall können Sie den Parameter `huge_pages` auf `off` setzen, sodass Amazon RDS die DB-Instance starten kann. Der Parameter `shared_buffers` ist wichtig für die Einstellung des gemeinsam genutzten Speicherpools, der für die Verwendung von großen Seiten erforderlich ist. Der Standardwert für den `shared_buffers`-Parameter verwendet ein Makro für Datenbankparameter. Dieses Makro legt einen Prozentsatz der insgesamt verfügbaren 8 KB an Seiten fest, die für den Speicher der DB-Instance verfügbar sind, verfügbar. Wenn Sie riesige Seiten verwenden, werden diese Seiten in den riesigen Seiten zusammengefasst zugeordnet. Amazon RDS versetzt eine DB-Instance in einen inkompatiblen Parameterstatus, wenn die Parameter für den gemeinsam genutzten Speicher so eingestellt sind, dass sie mehr als 90 Prozent des DB-Instance-Speichers benötigen. Weitere Informationen zur PostgreSQL-Arbeitsspeicherverwaltung finden Sie unter [Ressourcennutzung](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) in der PostgreSQL-Dokumentation. # Ausführen der logischen Replikation für Amazon RDS für PostgreSQL Ab Version 10.4 unterstützt RDS für PostgreSQL die Veröffentlichung und das Abonnement von SQL-Syntax, die erstmals in PostgreSQL 10 eingeführt wurde. Weitere Informationen finden Sie unter [Logische Replikation](https://www.postgresql.org/docs/current/logical-replication.html) in der PostgreSQL-Dokumentation. **Anmerkung** Zusätzlich zu der in PostgreSQL 10 eingeführten nativen logischen Replikationsfunktion von PostgreSQL unterstützt RDS für PostgreSQL auch die `pglogical`-Erweiterung. Weitere Informationen finden Sie unter [Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren](Appendix.PostgreSQL.CommonDBATasks.pglogical.md). Im Folgenden erfahren Sie, wie Sie die logische Replikation für eine DB-Instance von RDS für PostgreSQL einrichten. **Topics** + [ ## Verständnis der logischen Replikation und logischen Decodierung ](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding) + [ ## Arbeiten mit logischen Replikations-Slots ](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots) + [ ## Replizieren von Daten auf Tabellenebene mithilfe logischer Replikation ](#PostgreSQL.Concepts.LogicalReplication.Tables) ## Verständnis der logischen Replikation und logischen Decodierung RDS für PostgreSQL unterstützt das Streaming von Write-Ahead-Log(WAL)-Änderungen mithilfe der Slots für logische Replikation von PostgreSQL. Es unterstützt auch die Verwendung logischer Decodierung. Sie können logische Replikations-Slots in Ihrer Instance einrichten und über diese Slots Datenbankänderungen auf einen Client wie z. B. streame `pg_recvlogical`. Sie erstellen logische Replikationsslots auf Datenbankebene, die Replikationsverbindungen zu einer einzelnen Datenbank unterstützen. Die gängigsten Clients für die logische PostgreSQL-Replikation sind AWS Database Migration Service oder ein individuell verwalteter Host auf einer Amazon EC2 EC2-Instance. Der logische Replikations-Slot enthält keine Informationen über den Empfänger des Streams. Es gibt auch keine Anforderung, dass das Ziel eine Replikatdatenbank sein muss. Wenn beim Einrichten eines Slots für die logische Replikation nicht vom Slot gelesen wird, können Daten in den Speicher Ihrer DB-Instance geschrieben werden und diesen schnell füllen. Sie aktivieren die logische Replikation und die logische Decodierung PostgreSQL für Amazon RDS durch einen Parameter, einen neuen Replikationsverbindungstyp sowie eine Sicherheitsrolle. Beim Client für die logische Decodierung kann es sich um jeden beliebigen Client handeln, der eine Replikationsverbindung zu einer Datenbank in einer PostgreSQL-DB-Instance herstellen kann. **Logische Decodierung für eine DB-Instance von RDS für PostgreSQL aktivieren** 1. Stellen Sie sicher, dass das Benutzerkonto, das Sie verwenden, folgende Rollen hat: + Die `rds_superuser`-Rolle, damit Sie die logische Replikation aktivieren können + Die `rds_replication`-Rolle erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots 1. Setzen Sie den statischen Parameter `rds.logical_replication` auf 1. Setzen Sie bei der Anwendung dieses Parameters auch die Parameter `wal_level`, `max_wal_senders`, `max_replication_slots` und `max_connections` fest. Diese Änderungen an den Parametern können die WAL-Generierung steigern, legen Sie daher den Parameter `rds.logical_replication` nur dann fest, wenn Sie logische Slots verwenden. 1. Starten Sie die DB-Instance neu, damit der statische Parameter `rds.logical_replication` in Kraft tritt. 1. Erstellen Sie einen logischen Replikationsslot wie im nächsten Abschnitt erläutert. Für diesen Prozess ist es erforderlich, dass Sie ein Decodier-Plugin angeben. Derzeit unterstützt RDS für PostgreSQL die test\$1decoding- und wal2json-Ausgabe-Plugins, die mit PostgreSQL geliefert werden. Weitere Informationen zur logischen Decodierung mit PostgreSQL finden Sie in der [ PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html). ## Arbeiten mit logischen Replikations-Slots Sie können SQL-Befehle verwenden, um mit logischen Slots zu arbeiten. Beispiel: Der folgende Befehl erstellt einen logischen Slot mit dem Namen `test_slot` unter Verwendung des standardmäßigen Ausgangs-Plugin `test_decoding` von PostgreSQL. ``` SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding'); slot_name | xlog_position -----------------+--------------- regression_slot | 0/16B1970 (1 row) ``` Mit dem folgenden Befehl können Sie die logischen Slots auflisten. ``` SELECT * FROM pg_replication_slots; ``` Mit dem folgenden Befehl können Sie einen logischen Slot entfernen. ``` SELECT pg_drop_replication_slot('test_slot'); pg_drop_replication_slot ----------------------- (1 row) ``` Weitere Beispiele zum Arbeiten mit logischen Replikations-Slots finden Sie unter [ Logical Decoding Examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) in der PostgreSQL-Dokumentation. Sobald Sie den logischen Replikationsslot erstellt haben, können Sie mit dem Streaming beginnen. Das folgende Beispiel zeigt, wie die logische Decodierung über das Streaming-Replikationsprotokoll gesteuert wird. Dieses Beispiel verwendet das Programm pg\$1recvlogical, das in der PostgreSQL-Distribution enthalten ist. Dazu muss die Client-Authentifizierung so eingerichtet sein, dass Replikationsverbindungen zugelassen werden. ``` pg_recvlogical -d postgres --slot test_slot -U postgres --host -instance-name.111122223333.aws-region.rds.amazonaws.com -f - --start ``` Fragen Sie die Funktion `pg_replication_origin_status` ab, um den Inhalt der `pg_show_replication_origin_status` Ansicht anzuzeigen. ``` SELECT * FROM pg_show_replication_origin_status(); local_id | external_id | remote_lsn | local_lsn ----------+-------------+------------+----------- (0 rows) ``` ## Replizieren von Daten auf Tabellenebene mithilfe logischer Replikation Sie können die logische Replikation verwenden, um Daten aus Quelltabellen in Zieltabellen von RDS für PostgreSQL zu replizieren. Bei der logischen Replikation werden zunächst vorhandene Daten aus den Quelltabellen geladen und anschließend die laufenden Änderungen weiterhin repliziert. 1. **Erstellen der Quelltabellen** Stellen Sie eine Verbindung mit Ihrer Quelldatenbank in der DB-Instance von RDS für PostgreSQL her. ``` source=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` 1. **Einfügen der Daten in die Quelltabellen** ``` source=> INSERT INTO testtab VALUES (generate_series(1,1000)); INSERT 0 1000 ``` 1. **Erstellen einer Publikation für Quelltabellen** + Erstellen Sie eine Publikation für die Quelltabellen: ``` source=> CREATE PUBLICATION testpub FOR TABLE testtab; CREATE PUBLICATION ``` + Verwenden Sie eine SELECT-Abfrage, um die Details der erstellten Publikation zu überprüfen: ``` source=> SELECT * FROM pg_publication; oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot --------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------ 115069 | testpub | 16395 | f | t | t | t | t | f (1 row) ``` + Vergewissern Sie sich, dass die Quelltabellen zur Publikation hinzugefügt wurden: ``` source=> SELECT * FROM pg_publication_tables; pubname | schemaname | tablename ---------+------------+----------- testpub | public | testtab (1 rows) ``` + Um alle Tabellen in einer Datenbank zu replizieren, verwenden Sie Folgendes: ``` CREATE PUBLICATION testpub FOR ALL TABLES; ``` + Wenn die Publikation bereits für eine einzelne Tabelle erstellt wurde und Sie eine neue Tabelle hinzufügen müssen, können Sie die folgende Abfrage ausführen, um der vorhandenen Publikation beliebige neue Tabellen hinzuzufügen: ``` ALTER PUBLICATION add table ; ``` 1. **Herstellen einer Verbindung mit der Zieldatenbank und Erstellen von Zieltabellen** + Stellen Sie eine Verbindung mit der Zieldatenbank in der Ziel-DB-Instance her. Erstellen Sie die Zieltabellen mit denselben Namen wie die Quelltabellen: ``` target=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` + Vergewissern Sie sich, dass in den Zieltabellen keine Daten vorhanden sind, indem Sie eine SELECT-Abfrage für die Zieltabellen ausführen: ``` target=> SELECT count(*) FROM testtab; count ------- 0 (1 row) ``` 1. **Erstellen und Überprüfen des Abonnements in der Zieldatenbank** + Erstellen Sie das Abonnement in der Zieldatenbank: ``` target=> CREATE SUBSCRIPTION testsub CONNECTION 'host= port=5432 dbname= user= password=' PUBLICATION testpub; NOTICE: Created replication slot "testsub" on publisher CREATE SUBSCRIPTION ``` + Verwenden Sie eine SELECT-Abfrage, um zu überprüfen, ob das Abonnement aktiviert ist: ``` target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription; oid | subname | subenabled | subslotname | subpublications -------+---------+------------+-------------+----------------- 16434 | testsub | t | testsub | {testpub} (1 row) ``` + Wenn das Abonnement erstellt wird, werden alle Daten von den Quelltabellen in die Zieltabellen geladen. Führen Sie eine SELECT-Abfrage für die Zieltabellen aus, um zu überprüfen, ob die ursprünglichen Daten geladen werden: ``` target=> SELECT count(*) FROM testtab; count ------- 1000 (1 row) ``` 1. **Überprüfen des Replikations-Slots in der Quelldatenbank** Durch die Erstellung eines Abonnements in der Zieldatenbank wird ein Replikations-Slot in der Quelldatenbank erstellt. Überprüfen Sie die Details des Replikations-Slots, indem Sie die folgende SELECT-Abfrage für die Quelldatenbank ausführen: ``` source=> 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 ----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+--------------- testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved | (1 row) ``` 1. **Testen der Replikation** + Testen Sie, ob Datenänderungen in den Quelltabellen in die Zieltabellen repliziert werden, indem Sie folgende Zeilen in die Quelltabellen einfügen: ``` source=> INSERT INTO testtab VALUES(generate_series(1001,2000)); INSERT 0 1000 source=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` + Überprüfen Sie die Anzahl der Zeilen in den Zieltabellen, um sicherzustellen, dass neu eingefügte Daten repliziert werden: ``` target=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` 1. **Aktualisieren des Abonnements nach dem Hinzufügen von Tabellen** + Wenn Sie einer vorhandenen Publikation neue Tabellen hinzufügen, muss das Abonnement unbedingt aktualisiert werden, damit die Änderungen wirksam werden: ``` ALTER SUBSCRIPTION REFRESH PUBLICATION; ``` + Mit diesem Befehl werden fehlende Tabelleninformationen vom Publisher abgerufen und die Replikation für Tabellen gestartet, die seit der Erstellung oder letzten Aktualisierung des Abonnements zu den abonnierten Publikationen hinzugefügt wurden. # Konfiguration der IAM-Authentifizierung für logische Replikationsverbindungen Ab RDS für PostgreSQL, Versionen 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 Kennwörtern verwalten können. Sie funktioniert sowohl bei der Cluster- als auch bei der Instance-Granularität 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 in Ihrem DB-Cluster oder Ihrer DB-Parametergruppe auf 1. Da es sich um einen dynamischen Parameter handelt, muss Ihr DB-Cluster oder Ihre Instance 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 aufgeführten Voraussetzungen erfüllen. **Topics** + [ ## Voraussetzungen ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites) + [ ## Aktivieren der IAM-Authentifizierung für Replikationsverbindungen ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling) + [ ## Deaktivierung der IAM-Authentifizierung für Replikationsverbindungen ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling) + [ ## Einschränkungen und Überlegungen ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations) ## Voraussetzungen Um die IAM-Authentifizierung für Replikationsverbindungen verwenden zu können, müssen Sie alle der folgenden Anforderungen erfüllen: + Ihre RDS for PostgreSQL-DB-Instance muss Version 11 oder höher sein. + Gehen Sie auf Ihrer Publisher-DB-Instance RDS for PostgreSQL wie folgt vor: + 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. Bei der logischen Replikation ist der Herausgeber die Quell-RDS-Datenbank für PostgreSQL, die Daten an die Abonnentendatenbank sendet. Weitere Informationen finden Sie unter [Ausführen der logischen Replikation für Amazon RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md). **Anmerkung** Sowohl die IAM-Authentifizierung als auch die logische Replikation müssen auf Ihrer Publisher-RDS für PostgreSQL-DB-Instance 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. **Um die IAM-Authentifizierung für Replikationsverbindungen zu aktivieren** 1. Stellen Sie sicher, dass Ihr RDS for PostgreSQL-DB-Cluster oder Ihre Instance alle Voraussetzungen für die IAM-Authentifizierung mit Replikationsverbindungen erfüllt. Details hierzu finden Sie unter [Voraussetzungen](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites). 1. Konfigurieren Sie den `rds.iam_auth_for_replication` Parameter basierend auf Ihrem RDS for PostgreSQL-Setup: + Für RDS for PostgreSQL-DB-Instances: Ändern Sie Ihre DB-Parametergruppe. + Für Multi-AZ-Cluster: Ändern Sie Ihre DB-Cluster-Parametergruppe. Auf 1 `rds.iam_auth_for_replication` setzen. Dies ist ein dynamischer Parameter, der sofort wirksam wird, ohne dass ein Neustart erforderlich ist. **Anmerkung** Multi-AZ-Cluster verwenden nur DB-Cluster-Parametergruppen. Einzelne Instance-Parametergruppen können in Multi-AZ-Clustern nicht geändert werden. 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 in Ihrer DB-Parametergruppe für DB-Instances oder in der DB-Cluster-Parametergruppe für Multi-AZ-Cluster auf 0. + Alternativ können Sie eine dieser Funktionen in Ihrem RDS for PostgreSQL-DB-Cluster oder Ihrer Instance deaktivieren: + Deaktivieren Sie die logische Replikation, indem Sie den `rds.logical_replication` Parameter auf 0 setzen + Deaktivieren Sie die IAM-Authentifizierung Wenn Sie die Funktion deaktivieren, können Replikationsverbindungen Datenbankkennwörter zur Authentifizierung verwenden. **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 Beachten Sie bei der Verwendung der IAM-Authentifizierung für logische Replikationsverbindungen die folgenden Einschränkungen und Überlegungen: + Diese Funktion ist nur für RDS für PostgreSQL Version 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. # RAM-Datenträger für das stats\$1temp\$1directory Sie können den Parameter `rds.pg_stat_ramdisk_size` von RDS für PostgreSQL verwenden, um den Systemspeicher festzulegen, der einer RAM-Disk zur Speicherung von PostgreSQL-`stats_temp_directory` zugewiesen ist. Der RAM-Disk-Parameter ist nur für RDS für PostgreSQL 14 und frühere Versionen verfügbar. Bei bestimmten Workloads kann die Einstellung dieses Parameters die Leistung verbessern und die I/O Anforderungen verringern. Weitere Informationen zur Verwendung von `stats_temp_directory` finden Sie in der [ PostgreSQL-Dokumentation](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY). Wenn Sie einen RAM-Datenträger für Ihr `stats_temp_directory` einrichten möchten, legen Sie den Parameter `rds.pg_stat_ramdisk_size` in der von Ihrer DB-Instance verwendeten Parametergruppe auf einen literalen Ganzzahlwert fest. Dieser Parameter wird in MB angegeben, daher müssen Sie einen ganzzahligen Wert verwenden. Ausdrücke, Formeln und Funktionen sind für den Parameter `rds.pg_stat_ramdisk_size` nicht gültig. Starten Sie die DB-Instance neu, damit die Änderung wirksam wird. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Mit dem folgenden AWS CLI Befehl wird beispielsweise der RAM-Disk-Parameter auf 256 MB festgelegt. ``` aws rds modify-db-parameter-group \ --db-parameter-group-name pg-95-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Nach dem Neustart führen Sie den folgenden Befehl aus, um den Status des `stats_temp_directory` anzuzeigen: ``` postgres=> SHOW stats_temp_directory; ``` Der Befehl sollte Folgendes zurückgeben. ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Tablespaces für RDS for PostgreSQL RDS for PostgreSQL unterstützt Tablespaces aus Kompatibilitätsgründen. Da sich der gesamte Speicher auf einem einzigen logischen Volume befindet, können Sie Tablespaces nicht zum I/O Teilen oder Isolieren verwenden. Unsere Benchmarks und Erfahrung zeigen, dass ein einzelnes logisches Volume für die meisten Anwendungsfälle das beste Setup ist. Um Tablespaces mit Ihrer DB-Instance von RDS for PostgreSQL zu erstellen und zu verwenden, benötigen Sie die `rds_superuser`-Rolle. Das Hauptbenutzerkonto (Standardname, `postgres`) Ihrer DB-Instance von RDS for PostgreSQL ist Mitglied dieser Rolle. Weitere Informationen finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md). Wenn Sie beim Erstellen eines Tablespace einen Dateinamen angeben, lautet das Pfadpräfix `/rdsdbdata/db/base/tablespace`. Im folgenden Beispiel werden Tablespace-Dateien in abgeleg `/rdsdbdata/db/base/tablespace/data`. In diesem Beispiel wird angenommen, dass ein `dbadmin`-Benutzer (Rolle) existiert und ihm die `rds_superuser`-Rolle gewährt wurde, die zur Arbeit mit Tablespaces benötigt wird. ``` postgres=> CREATE TABLESPACE act_data OWNER dbadmin LOCATION '/data'; CREATE TABLESPACE ``` Weitere Informationen zu PostgreSQL-Tablespaces finden Sie unter [Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) in der PostgreSQL-Dokumentation. # RDS-für-PostgreSQL-Kollatierungen für EBCDIC- und andere Mainframe-Migrationen RDS-für-PostgreSQL-Versionen 10 und höher enthalten die ICU-Version 60.2, die auf Unicode 10.0 basiert und Kollationen aus dem Unicode Common Locale Data Repository, CLDR 32, enthält. Diese Software-Internationalisierungsbibliotheken stellen sicher, dass Zeichenkodierungen unabhängig vom Betriebssystem oder der Plattform einheitlich dargestellt werden. Weitere Informationen zu Unicode CLDR-32 finden Sie unter[CLDR 32 Versionshinweis](https://cldr.unicode.org/index/downloads/cldr-32)auf der Unicode CLDR-Website. Mehr über die Internationalisierungskomponenten für Unicode (ICU) erfahren Sie auf der[Technischer Ausschuss der Intensivstation (ICU-TC)](https://icu.unicode.org/home)Webseite. Hinweise zu ICU-60 finden Sie unter[Laden Sie ICU 60 herunter](https://icu.unicode.org/download/60). Ab Version 14.3 umfasst RDS für PostgreSQL auch Kollatierungen, die bei der Datenintegration und Konvertierung von EBCDC-basierten Systemen helfen. Der erweiterte binär codierte Dezimalaustauschcode oder*EBCDIC*Encoding wird häufig von Mainframe-Betriebssystemen verwendet. Diese von Amazon RDS bereitgestellten Sortierungen sind eng definiert, um nur die Unicode-Zeichen zu sortieren, die direkt EBCDIC-Codepages zugeordnet sind. Die Zeichen werden in EBCDIC-Codepunktreihenfolge sortiert, um eine Datenvalidierung nach der Konvertierung zu ermöglichen. Diese Sortierungen enthalten weder denormalisierte Formen noch Unicode-Zeichen, die nicht direkt einem Zeichen auf der EBCDIC-Quellcodepage zugeordnet sind. Die Zeichenzuordnungen zwischen EBCDIC-Codepages und Unicode-Codepunkten basieren auf von IBM veröffentlichten Tabellen. Das komplette Set ist bei IBM erhältlich als[komprimierte Datei](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip)zum Herunterladen. RDS für PostgreSQL verwendete diese Zuordnungen mit Tools, die von der ICU bereitgestellt wurden, um die in den Tabellen in diesem Abschnitt aufgeführten Kollatierungen zu erstellen. Die Kollationsnamen enthalten eine Sprache und ein Land, wie von der Intensivstation gefordert. EBCDIC-Codepages spezifizieren jedoch keine Sprachen, und einige EBCDIC-Codepages decken mehrere Länder ab. Das bedeutet, dass der Sprach- und Länderteil der Sortierungsnamen in der Tabelle willkürlich sind und nicht mit dem aktuellen Gebietsschema übereinstimmen müssen. Mit anderen Worten, die Codepage-Nummer ist der wichtigste Teil des Sortierungsnamens in dieser Tabelle. Sie können jede der in den folgenden Tabellen aufgeführten Kollatierungen in jeder RDS für PostgreSQL-Datenbank verwenden. + [Unicode to EBCDIC collations table](#ebcdic-table)— Einige Mainframe-Datenmigrationstools verwenden LATIN1 oder intern, um Daten LATIN9 zu kodieren und zu verarbeiten. Solche Tools verwenden Roundtrip-Schemata, um die Datenintegrität zu wahren und die umgekehrte Konvertierung zu unterstützen. Die Sortierungen in dieser Tabelle können von Tools verwendet werden, die Daten mithilfe von LATIN1 Kodierung verarbeiten, was keine besondere Behandlung erfordert. + [Unicode to LATIN9 collations table](#latin9-table) – Sie können diese Kollatierungen in jeder RDS für PostgreSQL-Datenbank verwenden. In der folgenden Tabelle finden Sie in RDS für PostgreSQL verfügbare Kollatierungen, die EBCDIC-Codepages Unicode-Codepunkten zuordnen. Es wird empfohlen, die Sortierungen in dieser Tabelle für die Anwendungsentwicklung zu verwenden, die eine Sortierung basierend auf der Reihenfolge der IBM Codepages erfordert. | Name der PostgreSQL-Sortierung | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge | | --- | --- | | DA-DK-CP277-x-Intensivstation | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 277 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 277-Codepunkt-Reihenfolge sortiert | | DE-DE-CP273-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 273 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 273-Codepunkt-Reihenfolge sortiert | | DE-GB-CP285-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 285 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 285-Codepunkt-Reihenfolge sortiert | | de-US-CP037-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 037 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 37-Codepunktreihenfolge sortiert | | es-ES-CP284-x-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 284 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 284-Codepunkt-Reihenfolge sortiert | | fi-FI-CP278-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 278 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 278-Codepunkt-Reihenfolge sortiert | | fr-FR-CP297-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 297 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 297-Codepunkt-Reihenfolge sortiert | | es-es-CP280-X-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 280 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 280 Codepunkt-Reihenfolge sortiert. | | NL-BE-CP500-x-ICU | Unicode-Zeichen, die direkt IBM EBCDIC Code Page 500 zugeordnet sind (pro Konvertierungstabellen), werden in IBM CP 500-Codepunktreihenfolge sortiert | Amazon RDS bietet eine Reihe zusätzlicher Sortierungen, die Unicode-Codepunkte, die LATIN9 Zeichen anhand der von IBM veröffentlichten Tabellen zugeordnet sind, in der Reihenfolge der ursprünglichen Codepunkte gemäß der EBCDIC-Codepage der Quelldaten sortieren. | Name der PostgreSQL-Sortierung | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge | | --- | --- | | DA-DK-CP1142 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1142 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1142-Codepunkte sortiert | | de-DE-CP1141 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1141 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1141-Codepunkte sortiert | | de-GB-CP1146 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1146 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1146-Codepunkte sortiert | | en-US-CP1140 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1140 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1140-Codepunkte sortiert | | es-ES-CP1145 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1145 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1145-Codepunkte sortiert | | fi-FI-CP1143 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1143 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1143-Codepunkte sortiert | | fr-FR-CP1147 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1147 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1147-Codepunkte sortiert | | it-IT-CP1144 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1144 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1144-Codepunkte sortiert | | nl-BE-CP1148 m-x-icu | Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC-Codepage 1148 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der IBM CP 1148-Codepunkte sortiert | Im Folgenden finden Sie ein Beispiel für die Verwendung eines RDS-Werts für PostgreSQL-Sortierungen. ``` db1=> SELECT pg_import_system_collations('pg_catalog'); pg_import_system_collations ----------------------------- 36 db1=> SELECT '¤' < 'a' col1; col1 ------ t db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1; col1 ------ f ``` Wir empfehlen Ihnen, die Sortierungen in der[Unicode to EBCDIC collations table](#ebcdic-table)und in der[Unicode to LATIN9 collations table](#latin9-table)für die Anwendungsentwicklung, die eine Sortierung basierend auf der Reihenfolge der IBM Codepages erfordert. Die folgenden Sortierungen (mit dem Suffix „b“) sind auch in sichtbar, sind aber für die Verwendung durch Mainframe-Datenintegrations- und Migrationstools vorgesehen`pg_collation`, da sie Codepages mit bestimmten Codepunktverschiebungen AWS zuordnen und erfordern eine besondere Behandlung bei der Sortierung. Mit anderen Worten: Die folgenden Sortierungen werden nicht empfohlen. + DA-DK-277 b-x-icu + DA-DK-1142 b-x-icu + DE-DE-CP273 b-x-icu + DE-DE-CP1141 b-x-icu + de-GB-CP1146 b-x-icu + de-GB-CP285 b-x-icu + de-US-CP037 b-x-icu + de-US-CP1140 b-x-icu + es-ES-CP1145 b-x-icu + Es-ES-CP284 b-x-icu + fi-FI-CP1143 b-x-icu + fr-FR-CP1147 b-x-icu + fr-FR-CP297 b-x-icu + it-IT-CP1144 b-x-icu + it-IT-CP280 b-x-icu + NL-BE-CP1148 b-x-icu + NL-BE-CP500 b-x-icu [Weitere Informationen zur Migration von Anwendungen aus Mainframe-Umgebungen zu finden Sie unter Was ist Mainframe-Modernisierung AWS? AWS](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html) . Weitere Informationen zu PostgreSQL und Kollationen finden Sie unter [Support für Kollationen](https://www.postgresql.org/docs/current/collation.html) in der PostgreSQL-Dokumentation. # Verwalten der logischen Slot-Synchronisation für RDS für PostgreSQL Ab Community-PostgreSQL 17 wurde über den Parameter `sync_replication_slots` oder die zugehörige Funktion, die Slots bei der Ausführung manuell synchronisiert, eine neue Funktion `pg_sync_replication_slots()` zur automatischen Synchronisation logischer Replikations-Slots von Primär- zu Standby-Servern eingeführt. Diese Funktionen sind ab RDS für PostgreSQL 17 verfügbar. Ein typisches Setup besteht aus einer primären Instance und ihrer [Read Replica](USER_PostgreSQL.Replication.ReadReplicas.md) sowie einem Abonnenten der primären Instance für die logische Replikation. Stellen Sie sicher, dass das Abonnement so erstellt wurde, dass die Failover-Option auf true gesetzt ist: ``` CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true); ``` Dadurch wird ein logischer Slot auf dem Publisher mit aktiviertem Failover erstellt. ``` postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots; slot_name | slot_type | failover -----------+-----------+---------- subname | logical | t (1 row) ``` Durch die Aktivierung der Slot-Synchronisierung werden alle Steckplätze für die logische Failover-Replikation auf dem primären System automatisch auf den physischen Standby-Slots erstellt und regelmäßig synchronisiert. Stellen Sie sicher, dass die folgenden Werte über [Parametergruppen](USER_WorkingWithParamGroups.Associating.md) festgelegt wurden: + `rds.logical_replication` muss `1` sein, um die logische Replikation zu aktivieren + `hot_standby_feedback` muss `1` im Standby-Modus sein + `rds.logical_slot_sync_dbname` im Standby-Modus muss auf einen gültigen Datenbanknamen gesetzt sein Der Standardwert des Parameters ist `postgres`. Wenn die logische Publishing-Instance über die `postgres`-Datenbank verfügt, muss der Standardparameter nicht geändert werden. + `synchronized_standby_slots` auf dem primären System muss auf den physischen Replikations-Slot des Standby-Speichers eingestellt werden, der synchron sein soll + `sync_replication_slots` muss `1` sein, um die automatische Synchronisation zu aktivieren Mit einem Abonnement-Slot mit aktiviertem Failover und den oben genannten Parameterwerten kann der Abonnent beim Heraufstufen einer Standby-Instance sein Abonnement für diese neu hochgestufte Instance ändern und die logische Replikation nahtlos fortsetzen.