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.
# Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL
Sie können die Funktionalität von PostgreSQL erweitern, indem Sie eine Vielzahl von Erweiterungen und Modulen installieren. Um beispielsweise mit Geodaten zu arbeiten, können Sie die PostGIS-Erweiterung installieren und verwenden. Weitere Informationen finden Sie unter [Verwalten von Geodaten mit der PostGIS-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md). Wenn Sie als anderes Beispiel die Dateneingabe für sehr große Tabellen verbessern möchten, können Sie die Partitionierung Ihrer Daten in Betracht ziehen, indem Sie die `pg_partman`-Erweiterung verwenden. Weitere Informationen hierzu finden Sie unter [Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman](PostgreSQL_Partitions.md).
**Anmerkung**
RDS für PostgreSQL unterstützt Trusted Language Extensions für PostgreSQL über die `pg_tle`-Erweiterung, die Sie Ihrer DB-Instance hinzufügen können. Mithilfe dieser Erweiterung können Entwickler ihre eigenen PostgreSQL-Erweiterungen in einer sicheren Umgebung erstellen, was die Setup- und Konfigurationsanforderungen vereinfacht. Weitere Informationen zu den Versionen von RDS für PostgreSQL, die `pg_tle`-Erweiterungen unterstützen, und weitere Informationen finden Sie unter. [Arbeiten mit Trusted Language Extensions für PostgreSQL](PostgreSQL_trusted_language_extension.md)
In einigen Fällen bietet es sich an, anstatt eine Erweiterung zu installieren, ein bestimmtes Modul zur Liste der `shared_preload_libraries` in der benutzerdefinierten DB-Parametergruppe Ihrer DB-Instance von RDS für PostgreSQL hinzufügen. In der Regel lädt die standardmäßige DB-Cluster-Parametergruppe nur die `pg_stat_statements`. Es stehen jedoch weitere Module zur Verfügung, die der Liste hinzugefügt werden können. Sie können beispielsweise Planungsfunktionen hinzufügen, indem Sie das `pg_cron`-Modul hinzufügen, wie unter [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md) beschrieben. Als weiteres Beispiel können Sie Abfrageausführungspläne protokollieren, indem Sie das `auto_explain`-Modul laden. Weitere Informationen finden Sie im AWS Knowledge Center unter [Ausführungspläne von Abfragen protokollieren](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#).
Abhängig von Ihrer Version von RDS für PostgreSQL erfordert die Installation einer Erweiterung möglicherweise `rds_superuser`-Berechtigungen wie folgt:
+ Für RDS für PostgreSQL Versionen 12 und frühere Versionen erfordert das Installieren von Erweiterungen `rds_superuser`-Berechtigungen.
+ Für RDS für PostgreSQL Version 13 und höher können Benutzer (Rollen) mit Erstellungsberechtigungen für eine bestimmte Datenbank-Instance *vertrauenswürdige Erweiterungen* installieren und verwenden. Eine Liste mit vertrauenswürdigen Erweiterungen finden Sie unter [Vertrauenswürdige Erweiterungen für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted).
Sie können auch genau angeben, welche Erweiterungen auf Ihrer DB-Instance von RDS für PostgreSQL installiert werden können, indem Sie sie im Parameter `rds.allowed_extensions` aufführen. Weitere Informationen finden Sie unter [Beschränkung der Installation von PostgreSQL-Erweiterungen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Weitere Informationen über die `rds_superuser`-Rolle finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
**Topics**
+ [
# Verwenden der Funktionen aus der orafce-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [
# Verwenden der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
](RDS_delegated_ext.md)
+ [
# Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman
](PostgreSQL_Partitions.md)
+ [
# Verwenden von pgAudit zur Protokollierung der Datenbankaktivität
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [
# Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron
](PostgreSQL_pg_cron.md)
+ [
# Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren
](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [
# Verwenden von „pgactive“ zur Unterstützung der Aktiv-Aktiv-Replikation
](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [
# Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg\$1repack
](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [
# Erweiterung aktualisieren und verwenden PLV8
](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [
# Verwenden PL/Rust , um PostgreSQL-Funktionen in der Sprache Rust zu schreiben
](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [
# Verwalten von Geodaten mit der PostGIS-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# Verwenden der Funktionen aus der orafce-Erweiterung
Die Orafce-Erweiterung bietet Funktionen und Operatoren, die eine Teilmenge von Funktionen und Paketen aus einer Oracle-Datenbank emulieren. Die orafce-Erweiterung erleichtert Ihnen das Portieren einer Oracle-Anwendung nach PostgreSQL. RDS for PostgreSQL Version 9.6.6 und höher unterstützt diese Erweiterung. Weitere Informationen zu Oracle finden Sie unter [orafce](https://github.com/orafce/orafce) on. GitHub
**Anmerkung**
RDS for PostgreSQL unterstützt das Paket `utl_file` nicht, das Teil der Erweiterung orafce ist. Dies liegt daran, dass die `utl_file`-Schema-Funktionen Lese- und Schreiboperationen für Betriebssystem-Textdateien ermöglichen, wofür ein Superuser-Zugriff auf den zugrundeliegenden Host erforderlich ist. Als verwalteter Service bietet RDS for PostgreSQL keinen Hostzugriff.
**So verwenden Sie die orafce-Erweiterung**
1. Stellen Sie unter Verwendung des Hauptbenutzernamens, der für die Erstellung der DB-Instance verwendet wurde, eine Verbindung mit der DB-Instance her.
Wenn Sie orafce für eine andere Datenbank in derselben DB-Instance aktivieren möchten, verwenden Sie den Befehl `/c dbname`-psql. Mit diesem Befehl wechseln Sie nach dem Einleiten der Verbindung aus der primären Datenbank.
1. Aktivieren Sie die orafce-Erweiterung mit der Anweisung `CREATE EXTENSION`.
```
CREATE EXTENSION orafce;
```
1. Übertragen Sie den Besitz der oracle-Schemas mit der Anweisung `ALTER SCHEMA` auf die rds\$1superuser-Rolle.
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
Mit dem psql-Befehl `\dn` zeigen Sie die Liste der Eigentümer für das oracle-Schema an.
# Verwenden der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
Mithilfe der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL können Sie die Erweiterungsverwaltung an einen Benutzer delegieren, der kein `rds_superuser` sein muss. Mit dieser Unterstützung für delegierte Erweiterungen wird die neue Rolle `rds_extension` erstellt und Sie müssen diese einem Benutzer zuweisen, um andere Erweiterungen zu verwalten. Mit dieser Rolle können Erweiterungen erstellt, aktualisiert und gelöscht werden.
Sie können auch genau angeben, welche Erweiterungen auf Ihrer RDS-DB-Instance installiert werden können, indem Sie sie im Parameter `rds.allowed_extensions` aufführen. Weitere Informationen finden Sie unter [Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS für PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
Mit dem Parameter `rds.allowed_delegated_extensions` können Sie die Liste der Erweiterungen einschränken, die vom Benutzer mit der `rds_extension`-Rolle verwaltet werden kann.
Die Unterstützung für delegierte Erweiterungen ist in den folgenden Versionen verfügbar:
+ Alle höheren Versionen
+ 16.4 und höhere 16-Versionen
+ 15.8 und höhere 15-Versionen
+ 14.13 und höhere 14-Versionen
+ 13.16 und höhere 13 Versionen
+ 12.20 und höhere 12 Versionen
**Topics**
+ [
## Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer
](#RDSPostgreSQL.delegated_ext_mgmt)
+ [
## Konfiguration, die bei der Unterstützung für delegierte Erweiterungen von RDS für PostgreSQL verwendet wird
](#RDSPostgreSQL.delegated_ext_config)
+ [
## Deaktivieren der Unterstützung für die delegierte Erweiterung
](#RDSPostgreSQL.delegated_ext_disable)
+ [
## Vorteile der Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS
](#RDSPostgreSQL.delegated_ext_benefits)
+ [
## Einschränkung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
](#RDSPostgreSQL.delegated_ext_limit)
+ [
## Für bestimmte Erweiterungen erforderliche Berechtigungen
](#RDSPostgreSQL.delegated_ext_perm)
+ [
## Sicherheitsüberlegungen
](#RDSPostgreSQL.delegated_ext_sec)
+ [
## Drop extension cascade ist deaktiviert
](#RDSPostgreSQL.delegated_ext_drop)
+ [
## Beispielerweiterungen, die mithilfe der Unterstützung für delegierte Erweiterungen hinzugefügt werden können
](#RDSPostgreSQL.delegated_ext_support)
## Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer
Sie müssen die folgenden Schritte ausführen, um die Unterstützung für delegierte Erweiterungen für einen Benutzer zu aktivieren:
1. **Einem Benutzer die `rds_extension`-Rolle erteilen** – Stellen Sie als `rds_superuser` eine Verbindung zur Datenbank her und führen Sie den folgenden Befehl aus:
```
Postgres => grant rds_extension to user_name;
```
1. **Die Liste der Erweiterungen festlegen, die von delegierten Benutzern verwaltet werden können** – Mit `rds.allowed_delegated_extensions` können Sie unter Verwendung von `rds.allowed_extensions` im DB-Cluster-Parameter eine Teilmenge der verfügbaren Erweiterungen angeben. Sie können dies auf einer der folgenden Ebenen durchführen:
+ Im Cluster oder in der Instance-Parametergruppe, über die AWS-Managementkonsole oder API. Weitere Informationen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**Anmerkung**
Sie müssen die Datenbank nicht neu starten, nachdem Sie den dynamischen Parameter `rds.allowed_delegated_extensions` geändert haben.
1. **Dem delegierten Benutzer Zugriff auf Objekte gewähren, die während dem Prozess der Erweiterungserstellung erstellt wurden** – Bestimmte Erweiterungen erstellen Objekte, für die zusätzliche Berechtigungen erteilt werden müssen, bevor der Benutzer mit der `rds_extension`-Rolle auf sie zugreifen kann. Der `rds_superuser` muss dem delegierten Benutzer Zugriff auf diese Objekte gewähren. Eine der Optionen besteht darin, einen Ereignisauslöser zu verwenden, um dem delegierten Benutzer automatisch die Berechtigung zu erteilen.
**Beispiel für einen Event-Trigger**
Wenn Sie einem delegierten Benutzer mit `rds_extension` die Verwendung von Erweiterungen ermöglichen möchten, für die Berechtigungen für seine bei der Erstellung der Erweiterung erstellten Objekte erforderlich sind, können Sie das folgende Beispiel für einen Ereignisauslöser anpassen und nur die Erweiterungen hinzufügen, für die die delegierten Benutzer Zugriff auf die gesamte Funktionalität haben sollen. Dieser Ereignisauslöser kann auf template1 (der Standardvorlage) erstellt werden, sodass alle mit template1 erstellten Datenbanken über diesen Ereignisauslöser verfügen. Wenn ein delegierter Benutzer die Erweiterung installiert, gewährt dieser Trigger automatisch die Eigentümerschaft an den von der Erweiterung erstellten Objekten.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Konfiguration, die bei der Unterstützung für delegierte Erweiterungen von RDS für PostgreSQL verwendet wird
| Konfigurationsname | Description | Standardwert | Hinweise | Wer Berechtigungen ändern oder erteilen kann |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | Dieser Parameter schränkt die Erweiterungen ein, die eine rds\$1extension-Rolle in einer Datenbank verwalten kann. Es muss sich um eine Teilmenge von rds.allowed\$1extensions handeln. | leere Zeichenfolge | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) Weitere Informationen zum Einrichten dieses Parameters finden Sie unter [Aktivieren der Unterstützung für delegierte Erweiterungen für einen Benutzer](#RDSPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | Mit diesem Parameter kann der Kunde die Erweiterungen einschränken, die in der RDS-DB-Instance installiert werden können. Weitere Informationen finden Sie unter [Einschränken der Installation von PostgreSQL-Erweiterungen](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction). | "\$1" | Standardmäßig ist dieser Parameter auf „\$1“ gesetzt, was bedeutet, dass alle von RDS für PostgreSQL und Aurora PostgreSQL unterstützten Erweiterungen von Benutzern mit den erforderlichen Berechtigungen erstellt werden dürfen. Leer bedeutet, dass keine Erweiterungen in der RDS-DB-Instance installiert werden können. | Administrator |
| `rds-delegated_extension_allow_drop_cascade` | Dieser Parameter steuert, ob Benutzer mit `rds_extension` die Erweiterung mithilfe der Option cascade löschen können. | aus | `rds-delegated_extension_allow_drop_cascade` ist standardmäßig auf `off` festgelegt. Dies bedeutet, dass Benutzer mit `rds_extension` eine Erweiterung mithilfe der Option cascade nicht löschen dürfen. Zur Erteilung dieser Fähigkeit sollte der Parameter `rds.delegated_extension_allow_drop_cascade` auf `on` gesetzt werden. | rds\$1superuser |
## Deaktivieren der Unterstützung für die delegierte Erweiterung
**Teilweises Deaktivieren**
Die delegierten Benutzer können keine neuen Erweiterungen erstellen, aber trotzdem bestehende Erweiterungen aktualisieren.
+ Setzen Sie `rds.allowed_delegated_extensions` in der DB-Cluster-Parametergruppe auf den Standardwert zurück.
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Vollständiges Deaktivieren**
Wenn Sie einem Benutzer die `rds_extension`-Rolle entziehen, erhält der Benutzer wieder die Standardberechtigungen. Der Benutzer kann keine Erweiterungen mehr erstellen, aktualisieren oder löschen.
```
postgres => revoke rds_extension from user_name;
```
## Vorteile der Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS
Durch die Verwendung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL delegieren Sie die Erweiterungsverwaltung sicher an Benutzer, die nicht über die `rds_superuser`-Rolle verfügen. Diese Funktion bietet die folgenden Vorteile:
+ Sie können die Erweiterungsverwaltung ganz einfach an Benutzer Ihrer Wahl delegieren.
+ Dafür ist keine `rds_superuser`-Rolle erforderlich.
+ Bietet die Möglichkeit, verschiedene Gruppen von Erweiterungen für unterschiedliche Datenbanken im selben DB-Cluster zu unterstützen
## Einschränkung der Unterstützung für delegierte Erweiterungen von Amazon RDS für PostgreSQL
+ Objekte, die während der Erweiterungserstellung erstellt wurden, benötigen möglicherweise zusätzliche Berechtigungen, damit die Erweiterung ordnungsgemäß funktioniert.
+ Einige Erweiterungen können standardmäßig nicht vom Benutzer der delegierten Erweiterung verwaltet werden, darunter die folgenden: `log_fdw`, `pg_cron`, `pg_tle`, `pgactive`, `pglogical`, `postgis_raster`, `postgis_tiger_geocoder`, `postgis_topology`.
## Für bestimmte Erweiterungen erforderliche Berechtigungen
Um die folgenden Erweiterungen zu erstellen, zu verwenden oder zu aktualisieren, sollte der delegierte Benutzer über die erforderlichen Berechtigungen für die folgenden Funktionen, Tabellen und Schemas verfügen.
| Erweiterungen, für die eine Eigentümerschaft oder Berechtigungen erforderlich sind | Funktion | Tabellen | Schema | Wörterbuch für die Textsuche | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | Keine | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | Keine | Keine | Keine |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | Keine | Keine | Keine | Keine |
| dict\$1int | Keine | Keine | Keine | intdict | Keine |
| pg\$1partman | Keine | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | Keine | Keine | Keine |
| pg\$1stat\$1statements | Keine | Keine | Keine | Keine | Keine |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | Keine | Keine | Keine |
| postgis\$1raster | Keine | Keine | Keine | Keine | Keine |
| postgis\$1topology | Keine | topology, layer | topology | Keine | Der delegierte Benutzer muss der Datenbankbesitzer sein. |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | Keine | Keine | Keine | Keine |
| rds\$1tools | role\$1password\$1encryption\$1type | Keine | Keine | Keine | Keine |
| postgis\$1tiger\$1geocoder | Keine | geocode\$1settings\$1default, geocode\$1settings | tiger | Keine | Keine |
| pg\$1freespacemap | pg\$1freespace | Keine | Keine | Keine | Keine |
| pg\$1visibility | pg\$1visibility | Keine | Keine | Keine | Keine |
## Sicherheitsüberlegungen
Denken Sie daran, dass ein Benutzer mit der `rds_extension`-Rolle Erweiterungen für alle Datenbanken verwalten kann, für die er die Connect-Berechtigung hat. Wenn beabsichtigt ist, dass ein delegierter Benutzer die Erweiterung für eine einzelne Datenbank verwaltet, empfiehlt es sich, alle öffentlichen Berechtigungen für jede Datenbank zu entziehen und dann dem delegierten Benutzer explizit die Connect-Berechtigung für diese spezifische Datenbank zu gewähren.
Es gibt mehrere Erweiterungen, mit denen ein Benutzer auf Informationen aus mehreren Datenbanken zugreifen kann. Stellen Sie sicher, dass die Benutzer, denen Sie `rds_extension` gewähren, über datenbankübergreifende Funktionen verfügen, bevor Sie diese Erweiterungen zu `rds.allowed_delegated_extensions` hinzufügen. `postgres_fdw` und `dblink` stellen beispielsweise Funktionen für datenbankübergreifende Abfragen auf derselben Instance oder auf Remote-Instances bereit. `log_fdw` liest die Protokolldateien der Postgres-Engine, die für alle Datenbanken in der Instance gelten und möglicherweise langsame Abfragen oder Fehlermeldungen von mehreren Datenbanken enthalten. `pg_cron` ermöglicht die Ausführung von geplanten Hintergrundaufträgen auf der DB-Instance und kann Aufträge so konfigurieren, dass sie in einer anderen Datenbank ausgeführt werden.
## Drop extension cascade ist deaktiviert
Die Möglichkeit, die Erweiterung mit der Option cascade durch einen Benutzer mit der `rds_extension`-Rolle zu löschen, wird durch den Parameter `rds.delegated_extension_allow_drop_cascade` gesteuert. `rds-delegated_extension_allow_drop_cascade` ist standardmäßig auf `off` festgelegt. Das bedeutet, dass Benutzer mit der Rolle `rds_extension` keine Erweiterung mithilfe der Option cascade löschen dürfen, wie in der untenstehenden Abfrage gezeigt.
```
DROP EXTENSION CASCADE;
```
Da dadurch automatisch Objekte gelöscht werden, die von der Erweiterung abhängen – und in der Folge auch alle Objekte, die wiederum von diesen Objekten abhängig sind. Der Versuch, die Option cascade zu verwenden, führt zu einem Fehler.
Zur Erteilung dieser Fähigkeit sollte der Parameter `rds.delegated_extension_allow_drop_cascade` auf `on` gesetzt werden.
Das Ändern des dynamischen Parameters `rds.delegated_extension_allow_drop_cascade` erfordert keinen Neustart der Datenbank. Sie können dies auf einer der folgenden Ebenen tun:
+ Im Cluster oder in der Instanzparametergruppe, über die API AWS-Managementkonsole oder.
+ Verwenden Sie den folgenden Befehl auf Datenbankebene:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Verwenden Sie den folgenden Befehl auf Benutzerebene:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Beispielerweiterungen, die mithilfe der Unterstützung für delegierte Erweiterungen hinzugefügt werden können
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Verwalten von PostgreSQL-Partitionen mit der Erweiterung pg\$1partman
Die PostgreSQL-Tabellenpartitionierung bietet ein Framework für den leistungsstarken Umgang mit Dateneingaben und Berichten. Verwenden Sie die Partitionierung für Datenbanken, die eine sehr schnelle Eingabe großer Datenmengen erfordern. Die Partitionierung ermöglicht auch schnellere Abfragen großer Tabellen. Die Partitionierung hilft bei der Verwaltung von Daten, ohne die Datenbank-Instance zu beeinträchtigen, da sie weniger I/O-Ressourcen benötigt.
Durch die Partitionierung können Sie Daten zur Verarbeitung in benutzerdefinierte Blöcke aufteilen. Sie können beispielsweise Zeitreihendaten für Bereiche wie stündlich, täglich, wöchentlich, monatlich, vierteljährlich, jährlich, benutzerdefiniert oder eine beliebige Kombination davon partitionieren. Wenn Sie für ein Beispiel für Zeitreihendaten die Tabelle nach Stunden partitionieren, enthält jede Partition die Daten einer Stunde. Wenn Sie die Zeitreihentabelle nach Tag partitionieren, enthalten die Partitionen die Daten eines Tages und so weiter. Der Partitionsschlüssel steuert die Größe einer Partition.
Wenn Sie den SQL-Befehl `INSERT` oder `UPDATE` für eine partitionierte Tabelle verwenden, leitet die Datenbank-Engine die Daten an die entsprechende Partition weiter. PostgreSQL-Tabellenpartitionen, die die Daten speichern, sind untergeordnete Tabellen der Haupttabelle.
Während der Lesevorgänge der Datenbankabfrage untersucht der PostgreSQL-Optimierer die `WHERE`-Klausel der Abfrage und leitet den Datenbank-Scan nach Möglichkeit nur an die relevanten Partitionen weiter.
Beginnend mit Version 10 verwendet PostgreSQL deklarative Partitionierung, um die Tabellenpartitionierung zu implementieren. Dies wird auch als native PostgreSQL-Partitionierung bezeichnet. Vor PostgreSQL Version 10 wurden Auslöser verwendet, um Partitionen zu implementieren.
Die PostgreSQL-Tabellenpartitionierung bietet die folgenden Funktionen:
+ Erstellung neuer Partitionen zu jeder Zeit.
+ Variable Partitionsbereiche.
+ Entfernbare und wiederverwendbare Partitionen mit DDL-Anweisungen (Data Definition Language).
Zum Beispiel sind entfernbare Partitionen nützlich, um Verlaufsdaten aus der Hauptpartition zu entfernen, aber Verlaufsdaten für die Analyse zu behalten.
+ Neue Partitionen erben die Eigenschaften der übergeordneten Datenbanktabelle, einschließlich folgender Eigenschaften:
+ Indizes
+ Primärschlüssel, die die Partitionsschlüsselspalte enthalten müssen
+ Fremdschlüssel
+ Einschränkungen prüfen
+ Referenzen
+ Erstellen von Indizes für die vollständige Tabelle oder jede spezifische Partition.
Sie können das Schema für eine einzelne Partition nicht ändern. Sie können jedoch die übergeordnete Tabelle ändern (z. B. das Hinzufügen einer neuen Spalte), die auf Partitionen übertragen wird.
**Topics**
+ [
## Übersicht über die PostgreSQL-Erweiterung pg\$1partman
](#PostgreSQL_Partitions.pg_partman)
+ [
## Aktivieren der Erweiterung pg\$1partman
](#PostgreSQL_Partitions.enable)
+ [
## Konfigurieren von Partitionen mit der create\$1parent-Funktion
](#PostgreSQL_Partitions.create_parent)
+ [
## Konfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion
](#PostgreSQL_Partitions.run_maintenance_proc)
## Übersicht über die PostgreSQL-Erweiterung pg\$1partman
Sie können die PostgreSQL-Erweiterung `pg_partman` verwenden, um die Erstellung und Pflege von Tabellenpartitionen zu automatisieren. Weitere allgemeine Informationen finden Sie unter [PG-Partitions-Manager](https://github.com/pgpartman/pg_partman) in der `pg_partman`-Dokumentation.
**Anmerkung**
Die Erweiterung `pg_partman` wird auf den RDS-for-PostgreSQL-Versionen 12.5 und höher unterstützt.
Anstatt jede Partition manuell erstellen zu müssen, konfigurieren Sie `pg_partman` mit den folgenden Einstellungen:
+ Zu partitionierende Tabelle
+ Partitionstyp
+ Partitionsschlüssel
+ Granularität der Partition
+ Optionen für die Erstellung und Verwaltung von Partitionen
Nachdem Sie eine partitionierte PostgreSQL-Tabelle erstellt haben, registrieren Sie diese mit `pg_partman`, indem Sie die Funktion `create_parent` aufrufen. Dadurch werden die erforderlichen Partitionen basierend auf den Parametern erstellt, die Sie an die Funktion übergeben.
Die Erweiterung `pg_partman` bietet auch die Funktion `run_maintenance_proc`, die Sie planmäßig aufrufen können, um Partitionen automatisch zu verwalten. Planen Sie, dass diese Funktion regelmäßig (z. B. stündlich) ausgeführt wird, um sicherzustellen, dass die richtigen Partitionen nach Bedarf erstellt werden. Sie können auch sicherstellen, dass Partitionen automatisch gelöscht werden.
## Aktivieren der Erweiterung pg\$1partman
Wenn Sie mehrere Datenbanken innerhalb derselben PostgreSQL-DB-Instance haben, für die Sie Partitionen verwalten möchten, aktivieren Sie die Erweiterung `pg_partman` für jede Datenbank separat. Um die Erweiterung `pg_partman` für eine bestimmte Datenbank zu aktivieren, erstellen Sie das Partitionswartungsschema und dann die Erweiterung `pg_partman` wie folgt:
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**Anmerkung**
Um die Erweiterung `pg_partman` zu erstellen, müssen Sie sicherstellen, dass Sie über `rds_superuser`-Berechtigungen verfügen.
Wenn Sie einen Fehler wie den folgenden erhalten, erteilen Sie dem Konto die Berechtigungen `rds_superuser` oder verwenden Sie Ihr Superuser-Konto.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
Um die Berechtigungen `rds_superuser` zu erteilen, verbinden Sie sich mit Ihrem Superuser-Konto und führen Sie den folgenden Befehl aus.
```
GRANT rds_superuser TO user-or-role;
```
Für die Beispiele, die die Verwendung der Erweiterung pg\$1partman zeigen, verwenden wir die folgende Beispieldatenbanktabelle und Partition. Diese Datenbank verwendet eine partitionierte Tabelle basierend auf einem Zeitstempel. Ein `data_mart`-Schema enthält eine Tabelle mit dem Namen `events` mit einer Spalte namens `created_at`. Die folgenden Einstellungen sind in der `events`-Tabelle enthalten:
+ Primärschlüssel `event_id` und `created_at`, die die Spalte zur Führung der Partition verwenden müssen.
+ Eine CHECK-Beschränkung `ck_valid_operation` zum Durchsetzen von Werten für eine `operation`-Tabellenspalte.
+ Zwei Fremdschlüssel, wobei einer `fk_orga_membership)` auf die externe Tabelle `organization` verweist und der andere (`fk_parent_event_id`) ein selbst referenzierter Fremdschlüssel ist.
+ Zwei Indizes, wobei einer (`idx_org_id`) für den Fremdschlüssel und der andere (`idx_event_type`) für den Ereignistyp steht.
Die folgenden DDL-Anweisungen erstellen diese Objekte, die automatisch auf jeder Partition enthalten sind.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Konfigurieren von Partitionen mit der create\$1parent-Funktion
Nachdem Sie die Erweiterung `pg_partman` aktiviert haben, verwenden Sie die `create_parent`-Funktion, um Partitionen innerhalb des Partitionswartungsschemas zu konfigurieren. Im folgenden Beispiel wird das `events`-Tabellenbeispiel verwendet, das in [Aktivieren der Erweiterung pg\$1partmanKonfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion](#PostgreSQL_Partitions.enable) erstellt wurde. Rufen Sie die `create_parent`-Funktion wie folgt auf.
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
Dabei werden die folgenden Parameter verwendet:
+ `p_parent_table` – Die übergeordnete partitionierte Tabelle. Diese Tabelle muss bereits existieren und einschließlich des Schemas vollständig qualifiziert sein.
+ `p_control` – Die Spalte, auf der die Partitionierung basieren soll. Der Datentyp muss ganzzahlig oder zeitbasiert sein.
+ `p_type` – Der Typ ist entweder `'range'` oder `'list'`.
+ `p_interval` – Das Zeitintervall oder der Ganzzahlbereich für jede Partition. Beispielwerte sind `1 day`, `1 hour` usw.
+ `p_premake` – Die Anzahl der Partitionen, die im Voraus erstellt werden müssen, um neue Inserts zu unterstützen.
Eine vollständige Beschreibung der Funktion `create_parent` finden Sie in der `pg_partman`-Dokumentation unter [Creation Functions (Erstellungsfunktionen)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions).
## Konfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion
Sie können Partitionswartungsvorgänge ausführen, um automatisch neue Partitionen zu erstellen, Partitionen zu trennen oder alte Partitionen zu entfernen. Die Partitionspflege beruht auf der Funktion `run_maintenance_proc` von der `pg_partman`-Erweiterung und der Erweiterung `pg_cron`, die einen internen Scheduler initiiert. Der `pg_cron`-Scheduler führt automatisch SQL-Anweisungen, -Funktionen und -Prozesse aus, die in Ihren Datenbanken definiert sind.
Im folgenden Beispiel wird das `events`-Tabellenbeispiel verwendet, das in [Aktivieren der Erweiterung pg\$1partmanKonfigurieren der Partitionspflege mit der run\$1maintenance\$1proc-Funktion](#PostgreSQL_Partitions.enable) erstellt wurde, um die automatische Ausführung der Partitionswartung festzulegen. Fügen Sie als Voraussetzung `pg_cron` zum Parameter `shared_preload_libraries` in der Parametergruppe der DB-Instance hinzu.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
Im Folgenden finden Sie eine step-by-step Erläuterung des vorangegangenen Beispiels:
1. Ändern Sie die mit Ihrer DB-Instance verknüpfte Parametergruppe und fügen Sie `pg_cron` dem `shared_preload_libraries`-Parameterwert hinzu. Diese Änderung erfordert einen Neustart der DB-Instance, damit sie wirksam wird. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Führen Sie den Befehl `CREATE EXTENSION pg_cron;` mit einem Konto aus, das die `rds_superuser`-Berechtigungen besitzt. Dadurch wird die Erweiterung `pg_cron` aktiviert. Weitere Informationen finden Sie unter [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](PostgreSQL_pg_cron.md).
1. Führen Sie den Befehl `UPDATE partman.part_config` aus, um die `pg_partman`-Einstellungen für die Tabelle `data_mart.events` anzupassen.
1. Führen Sie den Befehl aus `SET` . . . um die `data_mart.events`-Tabelle mit den folgenden Klauseln zu konfigurieren:
1. `infinite_time_partitions = true,` – Konfiguriert die Tabelle so, dass automatisch neue Partitionen ohne Begrenzung erstellt werden können.
1. `retention = '3 months',` – Konfiguriert die Tabelle so, dass sie eine maximale Beibehaltung von drei Monaten hat.
1. `retention_keep_table=true `– Konfiguriert die Tabelle so, dass die Tabelle bei Fälligkeit der Aufbewahrungsfrist nicht automatisch gelöscht wird. Stattdessen werden Partitionen, die älter als die Aufbewahrungsfrist sind, nur von der übergeordneten Tabelle getrennt.
1. Führen Sie den Befehl aus `SELECT cron.schedule` . . . um einen `pg_cron`-Funktionsaufruf zu machen. Dieser Aufruf definiert, wie oft der Scheduler das `pg_partman`-Wartungsverfahren `partman.run_maintenance_proc` ausführt. In diesem Beispiel wird der Prozess stündlich ausgeführt.
Eine vollständige Beschreibung der `run_maintenance_proc`-Funktion finden Sie in der `pg_partman`-Dokumentation unter [Maintenance Functions (Wartungsfunktionen)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions).
# Verwenden von pgAudit zur Protokollierung der Datenbankaktivität
Finanzinstitute, Behörden und viele Branchen müssen *Audit-Protokolle* aufbewahren, um die gesetzlichen Bestimmungen zu erfüllen. Durch die Verwendung der PostgreSQL-Audit-Erweiterung (pgAudit) mit Ihrer DB-Instance von RDS für PostgreSQL können Sie die detaillierten Datensätze erfassen, die normalerweise von Prüfern oder zur Erfüllung gesetzlicher Bestimmungen benötigt werden. Sie können beispielsweise die pgAudit-Erweiterung einrichten, um Änderungen an bestimmten Datenbanken und Tabellen nachzuverfolgen, den Benutzer zu erfassen, der die Änderung vorgenommen hat, und viele andere Details.
Die pgAudit-Erweiterung baut auf der Funktionalität der nativen PostgreSQL-Protokollierungsinfrastruktur auf, indem sie die Protokollmeldungen um Details erweitert. Mit anderen Worten, Sie verwenden für die Anzeige Ihres Audit-Protokolls den gleichen Ansatz wie für die Anzeige von Protokollmeldungen. Weitere Informationen zur PostgreSQL-Protokollierung finden Sie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md).
Die pgAudit-Erweiterung redigiert sensible Daten wie Klartext-Passwörter aus den Protokollen. Wenn Ihre DB-Instance von RDS für PostgreSQL so konfiguriert ist, dass Data Manipulation Language (DML)-Anweisungen protokolliert werden, wie in [Aktivieren der Abfrageprotokollierung für Ihren ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) beschrieben, können Sie das Klartext-Passwortproblem mithilfe der PostgreSQL-Audit-Erweiterung vermeiden.
Sie können das Auditing für Ihre Datenbank-Instances mit einem hohen Grad an Spezifität konfigurieren. Sie können alle Datenbanken und alle Benutzer überprüfen. Sie können auch festlegen, dass nur bestimmte Datenbanken, Benutzer und andere Objekte überprüft werden. Bestimmte Benutzer und Datenbanken können Sie auch explizit von der Prüfung ausschließen. Weitere Informationen finden Sie unter [Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Angesichts der Menge an Details, die erfasst werden können, empfehlen wir, dass Sie bei Verwendung von pgAudit Ihren Speicherverbrauch überwachen.
Die pgAudit-Erweiterung wird von allen verfügbaren Versionen von RDS für PostgreSQL Eine Liste der pgAudit-Versionen, die von verfügbaren Aurora-PostgreSQL-Versionen unterstützt werden, finden Sie unter [Versionen der Erweiterungen für Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) in den *Versionshinweisen für Amazon RDS für PostgreSQL*.
**Topics**
+ [
# Einrichten der pgAudit-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [
# Überprüfen von Datenbankobjekten
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [
# Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [
# Referenz für die pgAudit-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Einrichten der pgAudit-Erweiterung
Wenn Sie die pgAudit-Erweiterung auf Ihrer DB-Instance von RDS für PostgreSQLIhrem DB-Cluster von Aurora PostgreSQL einrichten möchten, fügen Sie zunächst pgAudit zu den gemeinsam genutzten Bibliotheken in der benutzerdefinierten DB-Parametergruppe für Ihre DB-Instance von RDS für PostgreSQL, hinzu. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Als Nächstes installieren Sie die pgAudit-Erweiterung. Abschließend geben Sie die Datenbanken und Objekte an, die Sie überprüfen möchten. Die Schritte in diesem Abschnitt veranschaulichen die Vorgehensweise. Sie können die AWS-Managementkonsole oder die AWS CLI verwenden.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um alle diese Aufgaben ausführen zu können.
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance von RDS für PostgreSQL einer benutzerdefinierten DB-Parametergruppe zugeordnet ist.
## Konsole
**So richten Sie die pgAudit-Erweiterung ein**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre DB-Instance von RDS für PostgreSQL Suchen Sie in den Instance-Details den Link **Parameter group** (Parametergruppe).
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Instance von RDS für PostgreSQL
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den `shared_preload_libraries`-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie `pgaudit` der Liste im Feld **Values** (Werte) hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
![\[Bild des shared_preload_libaries-Parameters mit hinzugefügter pgAudit-Erweiterung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Starten Sie die DB-Instance von RDS für PostgreSQL neu, damit Ihre Änderung des `shared_preload_libraries`-Parameters wirksam wird.
1. Wenn die Instance verfügbar ist, stellen Sie sicher, dass pgAudit initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. Wenn pgAudit initialisiert ist, können Sie jetzt die Erweiterung erstellen. Sie müssen die Erweiterung nach dem Initialisieren der Bibliothek erstellen, da die `pgaudit`-Erweiterung Ereignisauslöser für die Überwachung von Data Definition Language (DDL)-Anweisungen installiert.
```
CREATE EXTENSION pgaudit;
```
1. Schließen Sie die `psql`-Sitzung.
```
labdb=> \q
```
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Suchen Sie den `pgaudit.log`-Parameter in der Liste und legen Sie den entsprechenden Wert für Ihren Anwendungsfall fest. Wenn Sie beispielsweise den `pgaudit.log`-Parameter auf `write` festlegen, wie in der folgenden Abbildung gezeigt, werden Einfügungen, Aktualisierungen, Löschungen und einige andere Typänderungen im Protokoll erfasst.
![\[Bild des pgaudit.log-Parameters mit Einstellung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
Sie können auch einen der folgenden Werte für den `pgaudit.log`-Parameter auswählen.
+ „none“: Dies ist der Standardwert. Es werden keine Datenbankänderungen protokolliert.
+ „all“: Es wird alles protokolliert (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes).
+ „ddl“: Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind.
+ „function“: Protokolliert Funktionsaufrufe und `DO`-Blöcke.
+ „misc“: Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`.
+ „read“: Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist.
+ „role“: Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`.
+ „write“: Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist.
1. Wählen Sie **Änderungen speichern ** aus.
1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie Ihre DB-Instance von RDS für PostgreSQL aus der Datenbankliste aus.
## AWS CLI
**So richten Sie pgAudit ein**
Wenn Sie pgAudit mit der AWS CLI einrichten möchten, rufen Sie die Operation [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) auf, um die Audit-Protokollparameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie in den folgenden Schritten gezeigt.
1. Verwenden Sie den folgenden AWS CLI-Befehl, um dem `shared_preload_libraries`-Parameter `pgaudit` hinzuzufügen.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgendenAWS CLI Befehl, um die DB-Instance von RDS für PostgreSQL neu zu starten, sodass die pgaudit-Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, können Sie überprüfen, ob `pgaudit` initialisiert wurde. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
Wenn pgAudit initialisiert ist, können Sie jetzt die Erweiterung erstellen.
```
CREATE EXTENSION pgaudit;
```
1. Schließen Sie die `psql`-Sitzung, damit Sie die AWS CLI verwenden können.
```
labdb=> \q
```
1. Verwenden Sie den folgenden AWS CLI-Befehl, um die Anweisungsklassen anzugeben, die von der Sitzungsüberwachungsprotokollierung erfasst werden sollen. Im Beispiel wird der `pgaudit.log`-Parameter auf `write` festgelegt, wodurch Einfügungen, Aktualisierungen und Löschungen im Protokoll erfasst werden.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
Sie können auch einen der folgenden Werte für den `pgaudit.log`-Parameter auswählen.
+ „none“: Dies ist der Standardwert. Es werden keine Datenbankänderungen protokolliert.
+ „all“: Es wird alles protokolliert (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes).
+ „ddl“: Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind.
+ „function“: Protokolliert Funktionsaufrufe und `DO`-Blöcke.
+ „misc“: Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`.
+ „read“: Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist.
+ „role“: Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`.
+ „write“: Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist.
Starten Sie die DB-Instance von RDS für PostgreSQL mit dem folgenden AWS CLI-Befehl neu.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Überprüfen von Datenbankobjekten
Wenn pgAudit auf Ihrer DB-Instance von RDS für PostgreSQL eingerichtet und für Ihre Anforderungen konfiguriert ist, werden detailliertere Informationen im PostgreSQL-Protokoll erfasst. Während die PostgreSQL-Standardprotokollierungskonfiguration beispielsweise das Datum und die Uhrzeit angibt, zu der eine Änderung in einer Datenbanktabelle vorgenommen wurde, kann der Protokolleintrag mit der pgAudit-Erweiterung das Schema, den Benutzer, der die Änderung vorgenommen hat, und andere Details enthalten, je nachdem, wie die Erweiterungsparameter konfiguriert sind. Sie können das Auditing einrichten, um Änderungen wie folgt zu verfolgen.
+ Für jede Sitzung, nach Benutzer. Auf der Sitzungsebene können Sie den vollständig qualifizierten Befehlstext erfassen.
+ Für jedes Objekt, nach Benutzer und nach Datenbank.
Die Objektüberwachungsfunktion wird aktiviert, wenn Sie die `rds_pgaudit`-Rolle in Ihrem System erstellen und diese Rolle dann dem `pgaudit.role`-Parameter in Ihrer benutzerdefinierten Parametergruppe hinzufügen. Standardmäßig ist der `pgaudit.role`-Parameter nicht festgelegt und der einzig zulässige Wert ist `rds_pgaudit`. Bei den folgenden Schritten wird davon ausgegangen, dass `pgaudit` initialisiert wurde und Sie die `pgaudit`-Erweiterung gemäß den Schritten unter [Einrichten der pgAudit-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md) erstellt haben.
![\[Bild der PostgreSQL-Protokolldatei nach dem Einrichten von pgAudit.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
Wie in diesem Beispiel gezeigt, enthält die Zeile „LOG: AUDIT: SESSION“ unter anderem Informationen über die Tabelle und deren Schema.
**So richten Sie die Objektüberwachung ein**
1. Stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Erstellen Sie mithilfe des folgenden Befehls eine Datenbankrolle mit dem Namen `rds_pgaudit`.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Schließen Sie die `psql`-Sitzung.
```
labdb=> \q
```
Verwenden Sie in den nächsten Schritten die AWS CLI, um die Audit-Protokollparameter in Ihrer benutzerdefinierten Parametergruppe zu ändern.
1. Verwenden Sie den folgenden AWS CLI-Befehl, um den `pgaudit.role`-Parameter auf `rds_pgaudit` festzulegen. Standardmäßig ist dieser Parameter leer und der einzig zulässige Wert ist `rds_pgaudit`.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Starten Sie die DB-Instance von RDS für PostgreSQL mit dem folgenden AWS CLI-Befehl neu, damit Ihre Änderungen der Parameter wirksam werden.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Führen Sie den folgenden Befehl aus, um zu bestätigen, dass `pgaudit.role` auf `rds_pgaudit` festgelegt ist.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
Um die pgAudit-Protokollierung zu testen, können Sie mehrere Beispielbefehle ausführen, die Sie überprüfen möchten. Sie könnten beispielsweise die folgenden Befehle ausführen.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
Die Datenbankprotokolle sollten dann einen Eintrag ähnlich dem folgenden enthalten.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
Weitere Informationen zur Anzeige der Protokolle finden Sie unter [Überwachen von Amazon RDS-Protokolldateien](USER_LogAccess.md).
Weitere Informationen zur pgAudit-Erweiterung finden Sie unter [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) auf GitHub.
# Benutzer oder Datenbanken von der Audit-Protokollierung ausschließen
Wie unter [ RDS für PostgreSQL-Datenbankprotokolldateien](USER_LogAccess.Concepts.PostgreSQL.md) beschrieben, verbrauchen PostgreSQL-Protokolle Speicherplatz. Die Verwendung der pgAudit-Erweiterung erhöht die in Ihren Protokollen gesammelte Datenmenge je nach den von Ihnen verfolgten Änderungen in unterschiedlichem Maße. Möglicherweise müssen Sie nicht jeden Benutzer oder jede Datenbank in Ihrem überwachen. DB-Instance von RDS für PostgreSQL
Sie können Benutzer und Datenbanken von der Prüfung ausschließen, um die Auswirkungen auf Ihren Speicher zu minimieren und die unnötige Erfassung von Audit-Datensätzen zu vermeiden. Sie können die Protokollierung auch innerhalb einer bestimmten Sitzung ändern. In den nachstehenden Beispielen wird die Vorgehensweise dazu veranschaulicht.
**Anmerkung**
Parametereinstellungen auf Sitzungsebene haben Vorrang vor den Einstellungen in der benutzerdefinierten DB-Parametergruppe der DB-Instance von RDS für PostgreSQL. Wenn Sie nicht möchten, dass Datenbankbenutzer Ihre Konfigurationseinstellungen für die Audit-Protokollierung umgehen, müssen Sie ihre Berechtigungen ändern.
Angenommen, Ihre DB-Instance von RDS für PostgreSQL ist so konfiguriert, dass derselbe Aktivitätsgrad für alle Benutzer und Datenbanken überprüft wird. Sie entscheiden dann, dass Sie den Benutzer `myuser` nicht überprüfen möchten. Sie können das Auditing für `myuser` mit dem folgenden SQL-Befehl deaktivieren.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Anschließend können Sie die folgende Abfrage verwenden, um die Spalte `user_specific_settings` auf `pgaudit.log` zu überprüfen und zu bestätigen, dass der Parameter auf `NONE` festgelegt ist.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
Die Ausgabe sollte folgendermaßen aussehen.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
Sie können die Protokollierung für einen bestimmten Benutzer während seiner Datenbanksitzung mit dem folgenden Befehl deaktivieren.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Verwenden Sie die folgende Abfrage, um die Einstellungsspalte für eine bestimmte Benutzer- und Datenbankkombination auf pgaudit.log zu überprüfen.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
Die Ausgabe entspricht weitgehend der folgenden.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
Nachdem Sie das Auditing für `myuser` deaktiviert haben, entscheiden Sie, dass Sie Änderungen an `mydatabase` nicht verfolgen möchten. Sie können das Auditing für diese spezifische Datenbank mit dem folgenden Befehl deaktivieren.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Verwenden Sie dann die folgende Abfrage, um die Spalte database\$1specific\$1settings zu überprüfen und zu bestätigen, dass pgaudit.log auf NONE festgelegt ist.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
Die Ausgabe sollte folgendermaßen aussehen.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
Verwenden Sie den folgenden Befehl, um die Einstellungen wieder auf die Standardeinstellung für myuser festzulegen:
```
ALTER USER myuser RESET pgaudit.log;
```
Verwenden Sie den folgenden Befehl, um die Einstellungen wieder auf die Standardeinstellung für eine Datenbank festzulegen.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
Verwenden Sie den folgenden Befehl, um Benutzer und Datenbank wieder auf die Standardeinstellung festzulegen.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
Sie können auch bestimmte Ereignisse im Protokoll erfassen, indem Sie `pgaudit.log` auf einen der anderen zulässigen Werte für den `pgaudit.log`-Parameter festlegen. Weitere Informationen finden Sie unter [Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Referenz für die pgAudit-Erweiterung
Sie können den gewünschten Detaillierungsgrad für Ihr Audit-Protokoll angeben, indem Sie einen oder mehrere der in diesem Abschnitt aufgeführten Parameter ändern.
## Steuern des pgAudit-Verhaltens
Sie können die Audit-Protokollierung steuern, indem Sie einen oder mehrere der in der folgenden Tabelle aufgeführten Parameter ändern.
| Parameter | Description |
| --- | --- |
| `pgaudit.log` | Gibt die Anweisungsklassen an, die durch die Sitzungs-Audit-Protokollierung erfasst werden. Zulässige Werte sind „ddl“, „function“, „misc“, „read“, „role“, „write“, „none“, „all“. Weitere Informationen finden Sie unter [Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | Wenn diese Option aktiviert ist (auf 1 festgelegt), werden Anweisungen zum Audit-Trail hinzugefügt, wenn sich alle Beziehungen in einer Anweisung in pg\$1catalog befinden. |
| `pgaudit.log_level` | Gibt die Protokollstufe an, die für Protokolleinträge verwendet werden soll. Zulässige Werte: „debug5“, „debug4“, „debug3“, „debug2“, „debug1“, „info“, „notice“, „warning“, „log“ |
| `pgaudit.log_parameter` | Wenn diese Option aktiviert ist (auf 1 festgelegt), werden die mit der Anweisung übergebenen Parameter im Audit-Protokoll erfasst. |
| `pgaudit.log_relation` | Wenn diese Option aktiviert ist (auf 1 festgelegt), erstellt das Audit-Protokoll für die Sitzung einen separaten Protokolleintrag für jede Beziehung (TABLE, VIEW usw.), auf die in einer SELECT- oder DML-Anweisung verwiesen wird. |
| `pgaudit.log_statement_once` | Gibt an, ob die Protokollierung den Anweisungstext und die Parameter mit dem ersten Protokolleintrag für eine statement/substatement Kombination oder mit jedem Eintrag enthält. |
| `pgaudit.role` | Gibt die Hauptrolle an, die für die Objektüberwachungsprotokollierung verwendet werden soll. Der einzig zulässige Eintrag ist `rds_pgaudit`. |
## Liste der zulässigen Einstellungen für den `pgaudit.log`-Parameter
| Wert | Description |
| --- | --- |
| none | Dies ist die Standardeinstellung. Es werden keine Datenbankänderungen protokolliert. |
| all | Protokolliert alles (Lesen, Schreiben, Funktion, Rolle, DDL, Verschiedenes). |
| ddl | Protokolliert alle Data Definition Language (DDL)-Anweisungen, die nicht in der `ROLE`-Klasse enthalten sind. |
| function | Protokolliert Funktionsaufrufe und `DO`-Blöcke. |
| misc | Protokolliert verschiedene Befehle wie `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM` und `SET`. |
| read | Protokolliert `SELECT` und `COPY`, wenn die Quelle eine Beziehung (z. B. eine Tabelle) oder eine Abfrage ist. |
| role | Protokolliert Anweisungen in Bezug auf Rollen und Berechtigungen wie `REVOKE`, `CREATE ROLE`, `ALTER ROLE` und `DROP ROLE`. |
| Schreib- | Protokolliert `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` und `COPY`, wenn das Ziel eine Beziehung (Tabelle) ist. |
Um mehrere Ereignistypen mit der Sitzungsüberwachung zu protokollieren, verwenden Sie eine kommagetrennte Liste. Um alle Ereignistypen zu protokollieren, legen Sie `pgaudit.log` auf `ALL` fest. Starten Sie Ihre DB-Instance neu, um die Änderungen zu übernehmen.
Mit der Objektüberwachung können Sie die Überwachungsprotokollierung verfeinern, um mit bestimmten Beziehungen zu arbeiten. Sie können z. B. angeben, dass Sie eine Audit-Protokollierung für `READ`-Vorgänge in einer oder mehreren Tabellen wünschen.
# Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron
Sie können die PostgreSQL-Erweiterung `pg_cron` verwenden, um Wartungsbefehle innerhalb einer PostgreSQL-Datenbank zu planen. Weitere Informationen zu der Erweiterung finden Sie unter [Was ist pg\$1cron?](https://github.com/citusdata/pg_cron) in der pg\$1cron-Dokumentation.
Die Erweiterung `pg_cron` wird von RDS-PostgreSQL-Engine-Versionen 12.5 und höher unterstützt.
Weitere Informationen zur Verwendung von `pg_cron` finden Sie unter [Planen von Aufträgen mit pg\$1cron auf RDS für PostgreSQL oder Ihren Datenbanken der mit Aurora PostgreSQL kompatiblen Edition](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/).
**Anmerkung**
Die `pg_cron`-Erweiterungsversion wird in der Ansicht „pg\$1available\$1extensions“ als zweistellige Version angezeigt, beispielsweise 1.6. In einigen Kontexten werden möglicherweise dreistellige Versionen aufgeführt, z. B. 1.6.4 oder 1.6.5, Sie müssen jedoch die zweistellige Version angeben, wenn Sie ein Upgrade der Erweiterung durchführen.
**Topics**
+ [
## Einrichten der pg\$1con-Erweiterung
](#PostgreSQL_pg_cron.enable)
+ [
## Gewähren von Berechtigungen zur Verwendung von pg\$1cron für Datenbankbenutzer
](#PostgreSQL_pg_cron.permissions)
+ [
## Planen von pg\$1cron-Aufträgen
](#PostgreSQL_pg_cron.examples)
+ [
## Referenz für die pg\$1cron-Erweiterung
](#PostgreSQL_pg_cron.reference)
## Einrichten der pg\$1con-Erweiterung
Richten Sie die Erweiterung `pg_cron` wie folgt ein:
1. Ändern Sie die benutzerdefinierte Parametergruppe, die mit Ihrer PostgreSQL-DB-Instance verknüpft ist, indem Sie `pg_cron` dem Parameterwert `shared_preload_libraries` hinzufügen.
+ Wenn Ihre DB-Instance von RDS für PostgreSQL den Parameter `rds.allowed_extensions` verwendet, um Erweiterungen, die installiert werden können, explizit aufzulisten, müssen Sie die Erweiterung `pg_cron` in die Liste aufnehmen. Nur bestimmte Versionen von RDS für PostgreSQL unterstützen den Parameter `rds.allowed_extensions`. Standardmäßig sind alle verfügbaren Erweiterungen zulässig. Weitere Informationen finden Sie unter [Beschränkung der Installation von PostgreSQL-Erweiterungen](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction).
Starten Sie die PostgreSQL-DB-Instance neu, damit die Änderungen an der Parametergruppe in Kraft treten. Weitere Informationen zum Arbeiten mit Parametergruppen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Nachdem die PostgreSQL-DB-Instance neu gestartet wurde, führen Sie den folgenden Befehl mit einem Konto aus, das über `rds_superuser`-Berechtigungen verfügt. Wenn Sie beispielsweise beim Erstellen Ihrer RDS-for-PostgreSQL-DB-Instance die Standardeinstellungen verwendet haben, verbinden Sie sich als Benutzer `postgres` und erstellen Sie die Erweiterung.
```
CREATE EXTENSION pg_cron;
```
Der Scheduler `pg_cron` ist in der standardmäßigen PostgreSQL-Datenbank mit dem Namen `postgres` festgelegt. Die Objekte `pg_cron` werden in dieser `postgres`-Datenbank erstellt und alle Planungsaktionen werden in dieser Datenbank ausgeführt.
1. Sie können die Standardeinstellungen verwenden oder Aufgaben für die Ausführung in anderen Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance planen. Informationen zum Planen von Aufgaben für andere Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance finden Sie im Beispiel unter [Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank](#PostgreSQL_pg_cron.otherDB).
## Gewähren von Berechtigungen zur Verwendung von pg\$1cron für Datenbankbenutzer
Zum Installieren der Erweiterung `pg_cron` sind `rds_superuser`-Berechtigungen erforderlich. Berechtigungen zur Verwendung von `pg_cron` können anderen Datenbankbenutzern (von einem Mitglied der Gruppe/Rolle `rds_superuser`) gewährt werden, damit diese ihre eigenen Aufträge planen können. Wir empfehlen Ihnen, dem `cron`-Schema Berechtigungen nur nach Bedarf, wenn es die Abläufe in Ihrer Produktionsumgebung verbessert, zu gewähren.
Führen Sie den folgenden Befehl aus, um einem Datenbankbenutzer Berechtigungen im `cron`-Schema zu erteilen:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
Dies gibt die *db-user* Erlaubnis, auf das `cron` Schema zuzugreifen, um Cron-Jobs für die Objekte zu planen, für die sie Zugriffsberechtigungen haben. Wenn der Datenbankbenutzer keine Berechtigungen hat, schlägt der Auftrag fehl, nachdem die Fehlermeldung in der `postgresql.log`-Datei angezeigt wurde, wie nachfolgend dargestellt:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
Mit anderen Worten, stellen Sie sicher, dass Datenbankbenutzer, denen Berechtigungen für das `cron`-Schemas gewährt werden, auch über Berechtigungen für die Objekte (Tabellen, Schemas usw.) verfügen, die sie planen wollen.
Die Details des cron-Auftrags und dessen Erfolg oder Misserfolg werden ebenfalls in der Tabelle `cron.job_run_details` erfasst. Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
## Planen von pg\$1cron-Aufträgen
Die folgenden Abschnitte zeigen, wie Sie verschiedene Verwaltungsaufgaben mit `pg_cron`-Aufträgen planen können.
**Anmerkung**
Wenn Sie `pg_cron`-Aufträge erstellen, überprüfen Sie, dass die Einstellung `max_worker_processes` größer ist als die Anzahl von `cron.max_running_jobs`. Ein `pg_cron`-Auftrag schlägt fehl, wenn keine Hintergrund-Workerprozesse ausgeführt werden. Die Standardanzahl von `pg_cron`-Aufträgen ist `5`. Weitere Informationen finden Sie unter [Parameter für die Verwaltung der pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [
### Bereinigen von Tabellen
](#PostgreSQL_pg_cron.vacuum)
+ [
### Löschen der Verlaufstabelle pg\$1cron
](#PostgreSQL_pg_cron.job_run_details)
+ [
### Protokollieren von Fehlern nur in der Datei postgresql.log
](#PostgreSQL_pg_cron.log_run)
+ [
### Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank
](#PostgreSQL_pg_cron.otherDB)
### Bereinigen von Tabellen
Autovacuum übernimmt die Entfernung für die meisten Fälle Möglicherweise möchten Sie jedoch eine Bereinigung für eine bestimmte Tabelle zu einem Zeitpunkt Ihrer Wahl planen.
Weitere Informationen finden Sie auch unter, [Arbeiten mit der PostgreSQL-Selbstbereinigung in Amazon RDS für PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md).
Es folgt ein Beispiel für die Verwendung der Funktion `cron.schedule` zum Einrichten eines Auftrags, der jeden Tag um 22:00 Uhr (GMT) `VACUUM FREEZE` auf eine bestimmte Tabelle anwenden soll.
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
Nachdem das vorangehende Beispiel ausgeführt wurde, können Sie den Verlauf in der `cron.job_run_details`-Tabelle wie folgt überprüfen.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
Nachfolgend finden Sie eine Abfrage der Tabelle `cron.job_run_details`, um fehlgeschlagene Aufträge anzuzeigen.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
### Löschen der Verlaufstabelle pg\$1cron
Die `cron.job_run_details`-Tabelle enthält einen Verlauf von Cron-Aufgaben, die im Laufe der Zeit sehr groß werden können. Wir empfehlen Ihnen, eine Aufgabe zu planen, die diese Tabelle bereinigt. Beispielsweise kann es für die Fehlerbehebung ausreichen, die Eingaben einer Woche beizubehalten.
Im folgenden Beispiel wird die [cron.schedule](#PostgreSQL_pg_cron.schedule)-Funktion verwendet, um eine Aufgabe zu planen, die jeden Tag um Mitternacht ausgeführt wird, um die `cron.job_run_details`-Tabelle zu bereinigen. Die Aufgabe behält nur die letzten sieben Tage. Verwenden Sie Ihr `rds_superuser`-Konto, um die Aufgabe wie folgt zu planen.
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables).
### Protokollieren von Fehlern nur in der Datei postgresql.log
Wenn Sie verhindern möchten, dass in die `cron.job_run_details`-Tabelle geschrieben wird, ändern Sie die mit der PostgreSQL-DB-Instance verknüpfte Parametergruppe und deaktivieren Sie den Parameter `cron.log_run`. Es werden keine Schreibvorgänge der `pg_cron`-Erweiterung in die Tabelle mehr durchgeführt und nur noch Fehler in der `postgresql.log`-Datei erfasst. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Verwenden Sie den folgenden Befehl, um den Wert des `cron.log_run`-Parameters zu überprüfen.
```
postgres=> SHOW cron.log_run;
```
Weitere Informationen finden Sie unter [Parameter für die Verwaltung der pg\$1cron-Erweiterung](#PostgreSQL_pg_cron.parameters).
### Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank
Die Metadaten für `pg_cron` werden alle in der PostgreSQL-Standarddatenbank mit dem Namen `postgres` gespeichert. Da Hintergrund-Worker für die Ausführung der Maintenance-Cron-Aufgaben verwendet werden, können Sie eine Aufgabe in jeder Ihrer Datenbanken innerhalb der PostgreSQL-DB-Instance planen.
**Anmerkung**
Nur Benutzer mit der Rolle `rds_superuser` oder mit `rds_superuser`-Berechtigungen können alle cron-Aufträge in der Datenbank auflisten. Andere Benutzer können nur ihre eigenen Aufträge in der Tabelle `cron.job` anzeigen.
1. Planen Sie die Aufgabe in der Cron-Datenbank wie gewohnt mit [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. Aktualisieren Sie als Benutzer mit der `rds_superuser`-Rolle die Datenbankspalte für die soeben erstellte Aufgabe, damit sie in einer anderen Datenbank innerhalb Ihrer PostgreSQL-DB-Instance ausgeführt wird.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Überprüfen Sie dies, indem Sie die `cron.job`-Tabelle abfragen.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**Anmerkung**
In einigen Fällen können Sie eine Cron-Aufgabe hinzufügen, die Sie in einer anderen Datenbank ausführen möchten. Bevor Sie die richtige Datenbankspalte aktualisieren, versucht die Aufgabe in solchen Fällen möglicherweise, in der Standarddatenbank (`postgres`) ausgeführt zu werden. Wenn der Benutzername über Berechtigungen verfügt, wird die Aufgabe erfolgreich in der Standarddatenbank ausgeführt.
## Referenz für die pg\$1cron-Erweiterung
Sie können die folgenden Parameter, Funktionen und Tabellen mit der `pg_cron`-Erweiterung verwenden. Weitere Informationen finden Sie unter [Was ist pg\$1cron?](https://github.com/citusdata/pg_cron) in der pg\$1cron-Dokumentation.
**Topics**
+ [
### Parameter für die Verwaltung der pg\$1cron-Erweiterung
](#PostgreSQL_pg_cron.parameters)
+ [
### Funktionsreferenz: cron.schedule
](#PostgreSQL_pg_cron.schedule)
+ [
### Funktionsreferenz: cron.unschedule
](#PostgreSQL_pg_cron.unschedule)
+ [
### Tabellen zum Planen von Jobs und zur Erfassung des Status
](#PostgreSQL_pg_cron.tables)
### Parameter für die Verwaltung der pg\$1cron-Erweiterung
Es folgt eine Liste der Parameter zur Steuerung des Erweiterungsverhaltens von `pg_cron`.
| Parameter | Description |
| --- | --- |
| cron.database\$1name | Die Datenbank, in der `pg_cron`-Metadaten aufbewahrt werden. |
| cron.host | Der Hostname für die Verbindung mit PostgreSQL. Dieser Wert kann nicht verändert werden. |
| cron.log\$1run | Protokollieren Sie jeden ausgeführten Auftrag in der Tabelle `job_run_details`. Die Werte sind `on` oder `off`. Weitere Informationen finden Sie unter [Tabellen zum Planen von Jobs und zur Erfassung des Status](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Protokolliert alle Cron-Anweisungen, bevor Sie ausgeführt werden. Die Werte sind `on` oder `off`. |
| cron.max\$1running\$1jobs | Die maximale Anzahl von Aufgaben, die gleichzeitig ausgeführt werden können. |
| cron.use\$1background\$1workers | Verwenden Sie Hintergrund-Worker anstelle von Client-Sitzungen. Dieser Wert kann nicht verändert werden. |
Verwenden Sie den folgenden SQL-Befehl, um diese Parameter und ihre Werte anzuzeigen.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Funktionsreferenz: cron.schedule
Diese Funktion plant eine Cron-Aufgabe. Die Aufgabe ist anfänglich in der `postgres` Standarddatenbank geplant. Die Funktion gibt einen `bigint` Wert zurück, der den Aufgabenbezeichner darstellt. Informationen zum Planen von Aufgaben für die Ausführung in anderen Datenbanken innerhalb Ihrer PostgreSQL-DB-Instance finden Sie im Beispiel unter [Planen einer Cron-Aufgabe für eine andere als die Standard-Datenbank](#PostgreSQL_pg_cron.otherDB).
Die Funktion hat zwei Syntaxformate.
**Syntax**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Beispiele**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Funktionsreferenz: cron.unschedule
Diese Funktion löscht eine Cron-Aufgabe. Sie können entweder den `job_name` oder die `job_id` angeben. Eine Richtlinie stellt sicher, dass Sie der Besitzer sind, um den Plan für die Aufgabe zu entfernen. Die Funktion gibt einen Booleschen Wert zurück, der Erfolg oder Misserfolg anzeigt.
Die Funktion weist die folgende Syntax auf.
**Syntax**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parameter**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**Beispiele**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tabellen zum Planen von Jobs und zur Erfassung des Status
Die folgenden Tabellen werden verwendet, um die Cron-Aufgaben zu planen und aufzuzeichnen, wie die Aufgaben abgeschlossen wurden.
| Tabelle | Beschreibung |
| --- | --- |
| cron.job | Enthält die Metadaten zu jeder geplanten Aufgabe. Die meisten Interaktionen mit dieser Tabelle sollten über die Funktionen `cron.schedule` und `cron.unschedule` erfolgen. Wir empfehlen, dieser Tabelle keine Aktualisierungs- oder Einfügeberechtigungen zu gewähren. Dies würde es dem Benutzer ermöglichen, die `username`-Spalte zu aktualisieren, die als `rds-superuser` ausgeführt wird. |
| cron.job\$1run\$1details | Enthält Verlaufsdaten zu vergangenen geplanten Aufträgen, die ausgeführt wurden. Dies ist nützlich, um den Status, die Rückgabe von Nachrichten sowie die Start- und Endzeit des ausgeführten Auftrags zu untersuchen. Um zu verhindern, dass diese Tabelle ins Unendliche wächst, bereinigen Sie sie in regelmäßigen Abständen. Ein Beispiel finden Sie unter [Löschen der Verlaufstabelle pg\$1cron](#PostgreSQL_pg_cron.job_run_details). |
# Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen die `pglogical`-Erweiterung. Die Erweiterung pglogical ist älter als die funktionell ähnliche logische Replikationsfunktion, die von PostgreSQL in Version 10 eingeführt wurde. Weitere Informationen finden Sie unter [Ausführen der logischen Replikation für Amazon RDS für PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md).
Die `pglogical`-Erweiterung unterstützt die logische Replikation zwischen zwei oder mehr . DB-Instances von RDS für PostgreSQL Es unterstützt auch die Replikation zwischen verschiedenen PostgreSQL-Versionen und zwischen Datenbanken, die auf DB-Instances von RDS für PostgreSQL und DB-Clustern von Aurora PostgreSQL laufen. Die `pglogical`-Erweiterung verwendet ein Publish-Subscribe-Modell, um Änderungen an Tabellen und anderen Objekten, z. B. Sequenzen, von einem Herausgeber auf einen Abonnenten zu replizieren. Sie stützt sich auf einen Replikationsslot, um sicherzustellen, dass Änderungen von einem Herausgeberknoten zu einem Abonnentenknoten synchronisiert werden. Dies ist wie folgt definiert.
+ Der *Herausgeberknoten* ist die DB-Instance von RDS für PostgreSQL, die die Datenquelle ist, die auf andere Knoten repliziert werden soll. Der Herausgeberknoten definiert die Tabellen, die in einem Veröffentlichungssatz repliziert werden sollen.
+ Der *Abonnentenknoten* ist die DB-Instance von RDS für PostgreSQL, die WAL-Updates vom Herausgeber erhält. Der Abonnent erstellt ein Abonnement, um eine Verbindung zum Herausgeber herzustellen und die dekodierten WAL-Daten abzurufen. Wenn der Abonnent das Abonnement erstellt, wird der Replikationsslot auf dem Herausgeberknoten erstellt.
Im Folgenden erfahren Sie, wie Sie die `pglogical`-Erweiterung einrichten.
**Topics**
+ [
## Anforderungen und Einschränkungen für die pglogical-Erweiterung
](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [
# Einrichten der pglogical-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [
# Einrichten der logischen Replikation für die DB-Instance von RDS für PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [
# Wiederherstellung der logischen Replikation nach einem Hauptversions-Upgrade
](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [
# Verwaltung logischer Replikationsslots für
](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [
# Parameterreferenz für die pglogical-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Anforderungen und Einschränkungen für die pglogical-Erweiterung
Alle derzeit verfügbaren Versionen von RDS für PostgreSQL unterstützen die `pglogical`-Erweiterung.
Sowohl der Herausgeberknoten als auch der Abonnentenknoten müssen für die logische Replikation eingerichtet sein.
Die Tabellen, die Sie vom Publisher zum Subscriber replizieren möchten, müssen dieselben Namen und dasselbe Schema haben. Diese Tabellen müssen außerdem dieselben Spalten enthalten und diese müssen dieselben Datentypen verwenden. Sowohl die Herausgeber- als auch die Abonnententabelle müssen dieselben Primärschlüssel haben. Wir empfehlen, nur den PRIMARY KEY als eindeutige Einschränkung zu verwenden.
Die Tabellen auf dem Abonnentenknoten können für CHECK-Einschränkungen und NOT NULL-Einschränkungen großzügigere Einschränkungen haben als die Tabellen auf dem Herausgeberknoten.
Die `pglogical`-Erweiterung bietet Funktionen wie die bidirektionale Replikation, die von der logischen Replikationsfunktion, die in PostgreSQL (Version 10 und höher) integriert ist, nicht unterstützt werden. Weitere Informationen finden Sie unter [Die bidirektionale PostgreSQL-Replikation mit pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
# Einrichten der pglogical-Erweiterung
Wenn Sie die `pglogical`-Erweiterung auf Ihrer DB-Instance von RDS für PostgreSQL einrichten möchten, fügen Sie zunächst `pglogical` zu den gemeinsam genutzten Bibliotheken in der benutzerdefinierten DB-Parametergruppe für Ihre DB-Instance von RDS für PostgreSQL hinzu. Sie müssen außerdem den Wert des `rds.logical_replication`-Parameters auf `1` festlegen, um die logische Dekodierung zu aktivieren. Abschließend erstellen Sie die Erweiterung in der Datenbank. Sie können das AWS-Managementkonsole oder das AWS CLI für diese Aufgaben verwenden.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um diese Aufgaben ausführen zu können.
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance von RDS für PostgreSQL einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Weitere Informationen über das Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
## Konsole
**So richten Sie die pglogical-Erweiterung 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 im Navigationsbereich Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre DB-Instance von RDS für PostgreSQL Suchen Sie in den Instance-Details den Link **Parameter group** (Parametergruppe).
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrem DB-Instance von RDS für PostgreSQL
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den `shared_preload_libraries`-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie `pglogical` der Liste im Feld **Values** (Werte) hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
![\[Bild des shared_preload_libraries-Parameters mit hinzugefügter pglogical-Erweiterung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Suchen Sie den `rds.logical_replication`-Parameter und legen Sie ihn auf `1` fest, um die logische Replikation zu aktivieren.
1. Starten Sie die DB-Instance von RDS für PostgreSQL neu, damit Ihre Änderungen wirksam werden.
1. Wenn die Instance verfügbar ist, können Sie über `psql` (oder pgAdmin) eine Verbindung mit der DB-Instance von RDS für PostgreSQL herstellen.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass pglogical initialisiert ist.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Überprüfen Sie die Einstellung, die die logische Dekodierung ermöglicht, wie folgt.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Erstellen Sie die Erweiterung wie folgt.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Wählen Sie **Änderungen speichern ** aus.
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie aus der Liste der Datenbanken Ihre DB-Instance von RDS für PostgreSQL und dann im Menü „Actions“ (Aktionen) die Option **Reboot** (Neustart) aus.
## AWS CLI
**So richten Sie die pglogical-Erweiterung ein**
Um pglogical mit dem einzurichten AWS CLI, rufen Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)Vorgang auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.
1. Verwenden Sie den folgenden AWS CLI Befehl, um den Parameter `pglogical` zu erweitern. `shared_preload_libraries`
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um auf zu setzen`rds.logical_replication`, `1` um die logische Dekodierungsfunktion für die zu aktivieren. DB-Instance von RDS für PostgreSQL
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um die neu zu starten, sodass die pglogische Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Erstellen Sie die Erweiterung wie folgt.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Starten Sie die for PostgreSQL-DB-Instance mit dem folgenden Befehl neu. AWS CLI
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# Einrichten der logischen Replikation für die DB-Instance von RDS für PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Instances von RDS für PostgreSQL starten. Bei den Schritten wird davon ausgegangen, dass sowohl für die Quelle (Herausgeber) als auch für das Ziel (Abonnent) die `pglogical`-Erweiterung eingerichtet wurde, wie unter [Einrichten der pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md) beschrieben.
**Anmerkung**
Der `node_name` eines Subscriber-Knoten kann nicht mit `rds` beginnen.
**So erstellen Sie den Herausgeberknoten und die zu replizierenden Tabellen**
Bei diesen Schritten wird vorausgesetzt, dass Ihre DB-Instance von RDS für PostgreSQL über eine Datenbank mit einer oder mehreren Tabellen verfügt, die Sie auf einen anderen Knoten replizieren möchten. Sie müssen die Tabellenstruktur des Herausgebers für den Abonnenten neu erstellen. Rufen Sie daher bei Bedarf zunächst die Tabellenstruktur ab. Verwenden Sie dazu den `psql`-Metabefehl `\d tablename` und erstellen Sie dann dieselbe Tabelle auf der Abonnenten-Instance. Mit dem folgenden Verfahren wird zu Demonstrationszwecken eine Beispieltabelle für den Herausgeber (Quelle) erstellt.
1. Verwenden Sie `psql`, um eine Verbindung zu der Instance herzustellen, die die Tabelle enthält, die Sie als Quelle für Abonnenten verwenden möchten.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
Wenn Sie noch keine vorhandene Tabelle haben, die Sie replizieren möchten, können Sie wie folgt eine Beispieltabelle erstellen.
1. Erstellen Sie mit der folgenden SQL-Anweisung eine Beispieltabelle.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Füllen Sie die Tabelle mit der folgenden SQL-Anweisung mit generierten Daten auf.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Stellen Sie sicher, dass Daten in der Tabelle vorhanden sind, indem Sie die folgende SQL-Anweisung verwenden.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identifizieren Sie diese DB-Instance von RDS für PostgreSQL wie folgt als Herausgeberknoten.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Fügen Sie die Tabelle, die Sie replizieren möchten, zum Standardreplikationssatz hinzu. Weitere Informationen zu Replikationssätzen finden Sie unter [Replikationssätze](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) in der Dokumentation zur pglogical-Erweiterung.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
Die Einrichtung des Herausgeberknotens ist abgeschlossen. Sie können jetzt den Abonnentenknoten einrichten, um die Updates vom Herausgeber zu erhalten.
**So richten Sie den Abonnentenknoten ein und erstellen ein Abonnement für den Empfang von Updates**
Bei diesen Schritten wird vorausgesetzt, dass die DB-Instance von RDS für PostgreSQL mit der `pglogical`-Erweiterung eingerichtet wurde. Weitere Informationen finden Sie unter [Einrichten der pglogical-Erweiterung](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Verwenden Sie `psql`, um sich mit der Instance zu verbinden, die Updates vom Herausgeber erhalten soll.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Erstellen Sie auf der DB-Instance von RDS für PostgreSQL des Abonnenten dieselbe Tabelle, die auf dem Herausgeber vorhanden ist. In diesem Beispiel heißt die Tabelle `docs_lab_table`. Sie können die Tabelle wie folgt erstellen.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Stellen Sie sicher, dass diese Tabelle leer ist.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identifizieren Sie diese DB-Instance von RDS für PostgreSQL wie folgt als Abonnentenknoten.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Erstellen Sie das Abonnement.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
Wenn Sie diesen Schritt abschließen, werden die Daten aus der Tabelle des Herausgeberknotens in der Tabelle auf dem Abonnentenknoten erstellt. Mit der folgenden SQL-Abfrage können Sie überprüfen, ob dies der Fall ist.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
Ab diesem Zeitpunkt werden Änderungen, die an der Tabelle auf dem Herausgeberknoten vorgenommen wurden, auf die Tabelle auf dem Abonnentenknoten repliziert.
# Wiederherstellung der logischen Replikation nach einem Hauptversions-Upgrade
Bevor Sie ein Hauptversions-Upgrade einer DB-Instance von RDS für PostgreSQL durchführen können, die als Herausgeberknoten für die logische Replikation eingerichtet ist, müssen Sie alle Replikationsslots einschließlich der Slots löschen, die nicht aktiv sind. Wir empfehlen, Datenbanktransaktionen vorübergehend vom Herausgeberknoten umzuleiten, die Replikationsslots zu löschen, die DB-Instance von RDS für PostgreSQL zu aktualisieren und dann die Replikation erneut einzurichten und neu zu starten.
Die Replikationsslots werden nur auf dem Herausgeberknoten gehostet. Der Abonnentenknoten von RDS für PostgreSQL hat in einem logischen Replikationsszenario keine Slots, die gelöscht werden könnten. Er kann jedoch nicht auf eine Hauptversion aktualisiert werden, solange er als Abonnentenknoten mit einem Abonnement beim Herausgeber vorgesehen ist. Bevor Sie den Abonnentenknoten von RDS für PostgreSQL aktualisieren, löschen Sie das Abonnement und den Knoten. Weitere Informationen finden Sie unter [Verwaltung logischer Replikationsslots für ](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md).
## Feststellen, dass die logische Replikation unterbrochen wurde
Sie können feststellen, ob der Replikationsprozess unterbrochen wurde, indem Sie entweder den Herausgeberknoten oder den Abonnentenknoten wie folgt abfragen.
**So überprüfen Sie den Herausgeberknoten**
+ Verwenden Sie `psql`, um eine Verbindung mit dem Herausgeberknoten herzustellen, und fragen Sie dann die `pg_replication_slots`-Funktion ab. Notieren Sie sich den Wert in der aktiven Spalte. Normalerweise wird `t` (true) zurückgegeben, was bedeutet, dass die Replikation aktiv ist. Wenn die Abfrage `f` (false) zurückgibt, ist dies ein Hinweis darauf, dass die Replikation an den Abonnenten gestoppt wurde.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**So überprüfen Sie den Abonnentenknoten**
Auf dem Abonnentenknoten können Sie den Status der Replikation auf drei verschiedene Arten überprüfen.
+ Suchen Sie in den PostgreSQL-Protokollen auf dem Abonnentenknoten nach Fehlermeldungen. Das Protokoll identifiziert Fehler mit Meldungen, die den Exit-Code 1 enthalten, wie im Folgenden dargestellt.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Fragen Sie die `pg_replication_origin`-Funktion ab. Stellen Sie mithilfe von `psql` eine Verbindung mit der Datenbank auf dem Abonnentenknoten her und fragen Sie die `pg_replication_origin`-Funktion wie folgt ab.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
Die leere Ergebnismenge bedeutet, dass die Replikation unterbrochen wurde. Die Ausgabe sollte normalerweise folgendermaßen aussehen.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Fragen Sie die `pglogical.show_subscription_status`-Funktion wie im folgenden Beispiel veranschaulicht ab.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
Diese Ausgabe zeigt, dass die Replikation unterbrochen wurde. Ihr Status lautet `down`. Normalerweise zeigt die Ausgabe den Status `replicating` an.
Wenn Ihr logischer Replikationsprozess unterbrochen wurde, können Sie die Replikation wiederherstellen, indem Sie die folgenden Schritte ausführen.
**So stellen Sie die logische Replikation zwischen Herausgeber- und Abonnentenknoten wieder her**
Um die Replikation wiederherzustellen, trennen Sie zuerst den Abonnenten vom Herausgeberknoten und richten dann das Abonnement erneut ein, wie in diesen Schritten beschrieben.
1. Stellen Sie mit `psql` wie folgt eine Verbindung zum Abonnentenknoten her.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Deaktivieren Sie das Abonnement, indem Sie die `pglogical.alter_subscription_disable`-Funktion verwenden.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Rufen Sie die ID des Herausgeberknotens ab, indem Sie `pg_replication_origin` wie folgt abfragen.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Verwenden Sie die Antwort aus dem vorherigen Schritt mit dem `pg_replication_origin_create`-Befehl, um die ID zuzuweisen, die vom Abonnement verwendet werden kann, wenn es erneut eingerichtet wurde.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Aktivieren Sie das Abonnement, indem Sie seinen Namen mit dem Status `true` übergeben, wie im folgenden Beispiel veranschaulicht.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Prüfen Sie den Status des Knotens. Sein Status sollte `replicating` wie in diesem Beispiel gezeigt lauten.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Überprüfen Sie den Status des Replikationsslots des Abonnenten auf dem Herausgeberknoten. Die `active`-Spalte des Slots sollte den Wert `t` (true) zurückgeben, was darauf hinweist, dass die Replikation wiederhergestellt wurde.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Verwaltung logischer Replikationsslots für
Bevor Sie ein Hauptversions-Upgrade einer DB-Instance von RDS für PostgreSQL durchführen können, die als Herausgeberknoten in einem logischen Replikationsszenario eingerichtet ist, müssen Sie alle Replikationsslots auf der Instance löschen. Bei der Vorabüberprüfung des Hauptversions-Upgrades werden Sie darüber informiert, dass das Upgrade erst fortgesetzt werden kann, wenn die Slots gelöscht wurden.
Um Slots aus Ihrer DB-Instance von RDS für PostgreSQL zu entfernen, löschen Sie zuerst das Abonnement und dann den Slot.
Um Replikationsslots zu identifizieren, die mit der `pglogical`-Erweiterung erstellt wurden, melden Sie sich bei jeder Datenbank an und rufen Sie die Namen der Knoten ab. Wenn Sie den Abonnentenknoten abfragen, erhalten Sie in der Ausgabe sowohl den Herausgeber- als auch den Abonnentenknoten, wie in diesem Beispiel gezeigt.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
Die Details zum Abonnement erhalten Sie mit der folgenden Abfrage.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
Sie können das Abonnement jetzt wie folgt kündigen.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
Nachdem Sie das Abonnement gekündigt haben, können Sie den Knoten löschen.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
Sie können wie folgt überprüfen, dass der Knoten nicht mehr existiert.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Parameterreferenz für die pglogical-Erweiterung
In der Tabelle finden Sie Parameter, die der `pglogical`-Erweiterung zugeordnet sind. Parameter wie `pglogical.conflict_log_level` und `pglogical.conflict_resolution` werden verwendet, um Aktualisierungskonflikte zu beheben. Konflikte können auftreten, wenn Änderungen lokal an denselben Tabellen vorgenommen werden, die Änderungen vom Herausgeber abonniert haben. Konflikte können auch in verschiedenen Szenarien auftreten, z. B. bei der bidirektionalen Replikation oder wenn mehrere Abonnenten vom selben Herausgeber replizieren. Weitere Informationen finden Sie unter [Die bidirektionale PostgreSQL-Replikation mit pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
| Parameter | Description |
| --- | --- |
| pglogical.batch\$1inserts | Batch-Inserts wenn möglich Standardmäßig nicht festgelegt. In '1' ändern zum Einschalten, in '0' zum Ausschalten. |
| pglogical.conflict\$1log\$1level | Legt die Protokollstufe für die Protokollierung gelöster Konflikte fest. Unterstützte Zeichenfolgenwerte sind debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Legt die Methode fest, die verwendet werden soll, um Konflikte zu lösen, die lösbar sind. Unterstützte Zeichenfolgenwerte sind error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Verbindungsoptionen zum Hinzufügen zu allen Peer-Knotenverbindungen |
| pglogical.synchronous\$1commit | Spezifischer synchroner Commit-Wert für pglogical |
| pglogical.use\$1spi | Verwenden Sie zum Anwenden von Änderungen SPI (Server Programming Interface) anstelle der Low-Level-API. In '1' ändern zum Einschalten, in '0' zum Ausschalten. Weitere Informationen zu SPI finden Sie unter [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) in der PostgreSQL-Dokumentation. |
# Verwenden von „pgactive“ zur Unterstützung der Aktiv-Aktiv-Replikation
Die Erweiterung „`pgactive`“ verwendet Aktiv-Aktiv-Replikation, um Schreibvorgänge auf mehreren RDS-für-PostgreSQL-Datenbanken zu unterstützen und zu koordinieren. Die Erweiterung `pgactive` wird auf Amazon RDS für PostgreSQL für die folgenden Versionen unterstützt:
+ RDS für PostgreSQL 17.0 und alle höheren Versionen
+ RDS für PostgreSQL 16.1 und höhere 16-Versionen
+ RDS für PostgreSQL 15.4-R2 und höhere 15-Versionen
+ RDS für PostgreSQL 14.10 und höhere 14-Versionen
+ RDS für PostgreSQL 13.13 und höhere 13-Versionen
+ RDS für PostgreSQL 12.17 und höhere 12-Versionen
+ RDS für PostgreSQL 11.22
**Anmerkung**
Wenn in einer Replikationskonfiguration Schreibvorgänge für mehr als eine Datenbank ausgeführt werden, sind Konflikte möglich. Weitere Informationen finden Sie unter [Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md).
**Topics**
+ [
## Einschränkungen für die pgactive-Erweiterung
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [
# Initialisierung der „pgactive“-Erweiterungsfunktion
](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [
# Einrichten der Aktiv-Aktiv-Replikation für die DB-Instances von RDS für PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [
# Messen der Replikationsverzögerung zwischen pgactive-Mitgliedern
](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [
# Konfigurieren von Parametereinstellungen für die pgactive-Erweiterung
](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [
# Grundlegendes zu active-active-Konflikten
](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [
# Verstehen des pgactive-Schemas
](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [
# Referenz für pgactive-Funktionen
](pgactive-functions-reference.md)
+ [
# Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [
# Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Einschränkungen für die pgactive-Erweiterung
+ Alle Tabellen benötigen einen Primärschlüssel, andernfalls sind Aktualisierungen und Löschungen nicht zulässig. Die Werte in der Spalte „Primärschlüssel“ sollten nicht aktualisiert werden.
+ Sequenzen können Lücken aufweisen und manchmal keine bestimmte Reihenfolge beachten. Sequenzen werden nicht repliziert. Weitere Informationen finden Sie unter [Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ DDL und große Objekte werden nicht repliziert.
+ Sekundäre eindeutige Indizes können zu Datendivergenzen führen.
+ Die Sortierung muss auf allen Knoten in der Gruppe identisch sein.
+ Das Load Balancing zwischen den Knoten ist ein Anti-Muster.
+ Große Transaktionen können zu Verzögerungen bei der Replikation führen.
# Initialisierung der „pgactive“-Erweiterungsfunktion
Um die Erweiterungsfunktion „`pgactive`“ auf Ihrer RDS-für-PostgreSQL-DB-Instance zu initialisieren, setzen Sie den Wert des Parameters „`rds.enable_pgactive`“ auf `1` und erstellen Sie dann die Erweiterung in der Datenbank. Dadurch werden die Parameter „`rds.logical_replication`“ und „`track_commit_timestamp`“ automatisch aktiviert und der Wert von `wal_level` wird auf `logical` festgelegt.
Sie müssen über Berechtigungen als `rds_superuser`-Rolle verfügen, um diese Aufgaben ausführen zu können.
Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um den erforderlichen RDS für PostgreSQL-DB-Instances zu erstellen. Bei den folgenden Schritten wird davon ausgegangen, dass Ihre RDS-für-PostgreSQL-DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Informationen zum Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
## Konsole
**So initialisieren Sie die „pgactive“-Erweiterungsfunktion**
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 im Navigationsbereich Ihre DB-Instance von RDS für PostgreSQL aus.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration) für Ihre RDS-für-PostgreSQL-DB-Instance. Suchen Sie in den Instance-Details nach dem Link **DB-Instance-Parametergruppe**.
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer RDS-für-PostgreSQL-DB-Instance zugeordnet sind.
1. Suchen Sie den Parameter „`rds.enable_pgactive`“ und setzen Sie ihn auf „`1`“, um die „`pgactive`“-Funktion zu initialisieren.
1. Wählen Sie **Änderungen speichern ** aus.
1. Wählen Sie im Navigationsbereich der Amazon-RDS-Konsole die Option **Databases** (Datenbanken) aus.
1. Wählen Sie Ihre RDS-für-PostgreSQL-DB-Instance aus und wählen Sie dann im Menü **Aktionen** die Option **Neustart** aus.
1. Bestätigen Sie den Neustart der DB-Instance, damit die Änderungen in Kraft treten.
1. Wenn die DB-Instance verfügbar ist, können Sie „`psql`“ oder einen anderen PostgreSQL-Client nutzen, um eine Verbindung mit der RDS-für-PostgreSQL-DB-Instance herzustellen.
Im folgenden Beispiel wird davon ausgegangen, dass Ihre RDS for PostgreSQL-DB-Instance eine Standarddatenbank mit dem Namen hat. *postgres*
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass „pgactive“ initialisiert ist.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Wenn „`pgactive`“ in `shared_preload_libraries` ist, gibt der vorherige Befehl Folgendes zurück:
```
?column?
----------
t
```
## AWS CLI
**So initialisieren Sie die „pgactive“-Erweiterungsfunktion**
Um das `pgactive` mit dem zu initialisieren AWS CLI, rufen Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)Vorgang auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.
1. Verwenden Sie den folgenden AWS CLI Befehl, `rds.enable_pgactive` `1` um die `pgactive` Funktion für die RDS for PostgreSQL-DB-Instance zu initialisieren.
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um die RDS for PostgreSQL-DB-Instance neu zu starten, sodass die `pgactive` Bibliothek initialisiert wird.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, stellen Sie über `psql` eine Verbindung mit der DB-Instance von RDS für PostgreSQL her.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, dass „pgactive“ initialisiert ist.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Wenn „`pgactive`“ in `shared_preload_libraries` ist, gibt der vorherige Befehl Folgendes zurück:
```
?column?
----------
t
```
# Einrichten der Aktiv-Aktiv-Replikation für die DB-Instances von RDS für PostgreSQL
Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei DB-Instances von RDS für PostgreSQL starten, wobei `pgactive` verfügbar ist. Um das Beispiel für hohe Verfügbarkeit in mehreren Regionen auszuführen, müssen Sie Instances von Amazon RDS für PostgreSQL in zwei verschiedenen Regionen bereitstellen und VPC-Peering einrichten. Weitere Informationen finden Sie unter [VPC-Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**Anmerkung**
Beim Senden von Datenverkehr zwischen mehreren Regionen können zusätzliche Kosten anfallen.
Bei diesen Schritten wird vorausgesetzt, dass die DB-Instance von RDS für PostgreSQL mit der `pgactive`-Erweiterung eingerichtet wurde. Weitere Informationen finden Sie unter [Initialisierung der „pgactive“-Erweiterungsfunktion](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**So konfigurieren Sie die erste DB-Instance von RDS für PostgreSQL mit der „`pgactive`“-Erweiterung**
Das folgende Beispiel zeigt, wie die „`pgactive`“-Gruppe erstellt wird, sowie weitere Schritte, die erforderlich sind, um die „`pgactive`“-Erweiterung auf der RDS-für-PostgreSQL-DB-Instance zu erstellen.
1. Verwenden Sie `psql` oder ein anderes Client-Tool, um eine Verbindung zu Ihrer ersten DB-Instance von RDS für PostgreSQL herzustellen.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der RDS-für-PostgreSQL-Instance:
```
postgres=> CREATE DATABASE app;
```
1. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:
```
\c app
```
1. Erstellen Sie mit den folgenden SQL-Anweisungen eine Beispieltabelle.
1. Erstellen Sie mit der folgenden SQL-Anweisung eine Beispieltabelle.
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. Füllen Sie die Tabelle mit der folgenden SQL-Anweisung mit Beispieldaten auf.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Stellen Sie sicher, dass Daten in der Tabelle vorhanden sind, indem Sie die folgende SQL-Anweisung verwenden.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Erstellen Sie eine „`pgactive`“-Erweiterung für die bestehende Datenbank.
```
app=> CREATE EXTENSION pgactive;
```
1. Erstellen und initialisieren Sie die Gruppe „pgactive“ mit den folgenden Befehlen:
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
Jetzt können Sie die Replikationsgruppe initialisieren und diese erste Instance hinzufügen:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Verwenden Sie die folgenden Befehle als alternative, aber weniger sichere Methode, um die pgactive-Gruppe zu erstellen und zu initialisieren:
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app ist der Name, den Sie vergeben, um einen Knoten in der „`pgactive`“-Gruppe eindeutig zu identifizieren.
**Anmerkung**
Um diesen Schritt erfolgreich auf einer DB-Instance durchzuführen, auf die öffentlich zugegriffen werden kann, müssen Sie den Parameter „`rds.custom_dns_resolution`“ aktivieren, indem Sie ihn auf `1` setzen.
1. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die DB-Instance bereit ist:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen die folgende Ausgabe angezeigt:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**So konfigurieren Sie die zweite RDS-für-PostgreSQL-Instance und fügen sie der „`pgactive`“-Gruppe hinzu**
Das folgende Beispiel zeigt, wie Sie eine RDS-für-PostgreSQL-DB-Instance mit der „`pgactive`“-Gruppe verbinden können, sowie weitere Schritte, die zum Erstellen der „`pgactive`“-Erweiterung auf der DB-Instance erforderlich sind.
Bei diesen Schritten wird vorausgesetzt, dass andere DB-Instances von RDS für PostgreSQL mit der „`pgactive`“-Erweiterung eingerichtet wurde(n). Weitere Informationen finden Sie unter [Initialisierung der „pgactive“-Erweiterungsfunktion](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Verwenden Sie `psql`, um sich mit der Instance zu verbinden, die Updates vom Herausgeber erhalten soll.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der zweiten RDS-für-PostgreSQL-Instance:
```
postgres=> CREATE DATABASE app;
```
1. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:
```
\c app
```
1. Erstellen Sie die „`pgactive`“-Erweiterung für die bestehende Datenbank.
```
app=> CREATE EXTENSION pgactive;
```
1. Fügen Sie der „`pgactive`“-Gruppe die zweite DB-Instance von RDS für PostgreSQL mit den folgenden Befehlen hinzu:
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Verwenden Sie die folgenden Befehle als alternative, aber weniger sichere Methode, um der `pgactive`-Gruppe den die zweite DB-Instance von RDS für PostgreSQL hinzuzufügen.
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app ist der Name, den Sie vergeben, um einen Knoten in der „`pgactive`“-Gruppe eindeutig zu identifizieren.
1. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die DB-Instance bereit ist:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Wird der Befehl erfolgreich ausgeführt, wird Ihnen die folgende Ausgabe angezeigt:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Wenn die erste RDS-für-PostgreSQL-Datenbank relativ groß ist, können Sie sehen, dass `pgactive.pgactive_wait_for_node_ready()` den Fortschrittsbericht des Wiederherstellungsvorgangs ausgibt. Die Ausgabe sieht folgendermaßen oder ähnlich aus:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Ab diesem Zeitpunkt werden die Daten zwischen den beiden DB-Instances durch „`pgactive`“ synchronisiert.
1. Sie können den folgenden Befehl verwenden, um zu überprüfen, ob die Datenbank der zweiten DB-Instance die Daten enthält:
```
app=> SELECT count(*) FROM inventory.products;
```
Wenn die Daten erfolgreich synchronisiert wurden, sehen Sie die folgende Ausgabe:
```
count
-------
3
```
1. Führen Sie den folgenden Befehl aus, um neue Werte einzufügen:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Stellen Sie eine Verbindung zur Datenbank der ersten DB-Instance her und führen Sie die folgende Abfrage aus:
```
app=> SELECT count(*) FROM inventory.products;
```
Wenn die Aktiv-Aktiv-Replikation initialisiert ist, sieht die Ausgabe ungefähr wie folgt aus:
```
count
-------
4
```
**So trennen Sie eine DB-Instance von der „`pgactive`“-Gruppe und entfernen Sie daraus**
Sie können eine DB-Instance mit den folgenden Schritten von der „`pgactive`“-Gruppe trennen und daraus entfernen:
1. Sie können die zweite DB-Instance mit dem folgenden Befehl von der ersten DB-Instance trennen:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Entfernen Sie die „`pgactive`“-Erweiterung mit dem folgenden Befehl aus der zweiten DB-Instance:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
So erzwingen Sie die Entfernung der Erweiterung:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Löschen Sie die Erweiterung mit dem folgenden Befehl:
```
app=> DROP EXTENSION pgactive;
```
# Messen der Replikationsverzögerung zwischen pgactive-Mitgliedern
Sie können die folgende Abfrage verwenden, um die Replikationsverzögerung zwischen den `pgactive`-Mitgliedern anzuzeigen. Führen Sie diese Abfrage auf jedem `pgactive`- Knoten aus, um sich ein vollständiges Bild zu machen.
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
Überwachen Sie mindestens die folgenden Diagnosen:
aktiv
Richten Sie Benachrichtigungen ein, wenn „active“ den Wert „false“ hat, was darauf hinweist, dass der Slot derzeit nicht verwendet wird (die Abonnenten-Instance hat die Verbindung zum Publisher getrennt).
pending\$1wal\$1decoding
Bei der logischen Replikation von PostgreSQL werden WAL-Dateien im Binärformat gespeichert. Der Publisher muss diese WAL-Änderungen dekodieren und in logische Änderungen umwandeln (z. B. Einfüge-, Aktualisierungs- oder Löschvorgänge).
Die Metrik „pending\$1wal\$1decoding“ zeigt die Anzahl der WAL-Dateien, die auf der Publisher-Seite darauf warten, dekodiert zu werden.
Diese Zahl kann aufgrund der folgenden Faktoren steigen:
+ Wenn der Abonnent nicht verbunden ist, wird der Status „Aktiv“ auf „Falsch“ gesetzt und der Wert „pending\$1wal\$1decoding“ wird erhöht
+ Der Slot ist aktiv, aber der Publisher kann mit der Menge der WAL-Änderungen nicht Schritt halten
pending\$1wal\$1to\$1apply
Die Metrik „pending\$1wal\$1apply“ gibt die Anzahl der WAL-Dateien an, die auf Abonnentenseite darauf warten, angewendet zu werden.
Verschiedene Faktoren können verhindern, dass der Abonnent Änderungen vornimmt, und möglicherweise zum Szenario einer vollen Festplatte führen:
+ Schemaunterschiede – Wenn beispielsweise Änderungen im WAL-Stream für eine Tabelle mit dem Namen „sample“ vorliegen, diese Tabelle auf der Abonnentenseite jedoch nicht vorhanden ist.
+ Die Werte in den Primärschlüsselspalten wurden aktualisiert.
+ Sekundäre eindeutige Indizes können zu Datendivergenzen führen.
# Konfigurieren von Parametereinstellungen für die pgactive-Erweiterung
Sie können die folgende Abfrage verwenden, um alle mit der „`pgactive`“-Erweiterung verknüpften Parameter anzuzeigen.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Sie können die `pgactive`-Erweiterung mit verschiedenen Parametern konfigurieren. Diese Parameter können entweder über die AWS-Managementkonsole oder die AWS CLI-Schnittstelle eingestellt werden.
## Wichtigste pgactive-Erweiterungsparameter
Die folgende Tabelle enthält eine Referenz für die Hauptparameter der `pgactive`-Erweiterung:
| Parameter | Einheit | Standard | Description |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Protokolliert vollständige Tupel-Informationen für die `pgactive`-Erweiterung. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Legt fest, ob die `pgactive`-Erweiterung die erkannten Konflikte in der `pgactive.pgactive_conflict_history`-Tabelle protokolliert. Weitere Informationen finden Sie unter „Konfliktprotokollierung“. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Legt fest, ob die `pgactive`-Erweiterung die erkannten Konflikte in der PostgreSQL-Protokolldatei protokolliert. Weitere Informationen finden Sie unter „Konfliktprotokollierung“. Ein Serverneustart ist erforderlich, damit Änderungen wirksam werden. |
| pgactive.synchronous\$1commit | `boolean` | aus | Bestimmt das Commit-Verhalten für „pgactive apply“-Worker. Wenn diese Option deaktiviert (aus) ist, führen apply-Worker asynchrone Commits durch. Dadurch wird der PostgreSQL-Durchsatz bei Apply-Vorgängen verbessert, die Wiederholungsbestätigungen an den Upstream werden jedoch verzögert. Die Einstellung auf `off` ist immer sicher und führt nicht zum Verlust oder Überspringen von Transaktionen. Diese Einstellung wirkt sich nur auf den Zeitpunkt der Festplattenleerungen auf dem Downstream-Knoten und darauf aus, wann Bestätigungen upstream gesendet werden. Das System verzögert das Senden von Replay-Flush-Bestätigungen, bis Commits durch unabhängige Vorgänge wie Checkpoints oder regelmäßige Aufgaben auf die Festplatte geschrieben werden. Wenn im Upstream-Bereich jedoch der Downstream unter `synchronous_standby_names` aufgeführt ist, führt die Einstellung auf `off` dazu, dass synchrone Commits auf dem Upstream länger brauchen, bis sie dem Client erfolgreich gemeldet werden. In diesem Fall legen Sie den Parameter auf `on` fest. Selbst wenn dieser Parameter auf `on` mit aufgelisteten Knoten unter `synchronous_standby_names` festgelegt ist, können Replikationskonflikte in active-active-Konfigurationen weiterhin auftreten. Das liegt daran, dass dem System das Sperren zwischen den Knoten und das globale Snapshot-Management fehlen, sodass gleichzeitige Transaktionen auf verschiedenen Knoten dasselbe Tupel ändern können. Darüber hinaus beginnen Transaktionen erst mit der Replikation, nachdem sie auf dem Upstream-Knoten festgeschrieben wurden. Durch die Aktivierung eines synchronen Commits wird die pgactive-Erweiterung nicht in ein stets konsistentes System transformiert. |
| pgactive.temp\$1dump\$1directory | `string` | – | Definiert den temporären Speicherpfad, der für das Klonen von Datenbanken bei der Ersteinrichtung erforderlich ist. Dieses Verzeichnis muss für den Postgres-Benutzer beschreibbar sein und über ausreichend Speicherplatz für einen vollständigen Datenbank-Dump verfügen. Das System verwendet diesen Speicherort nur bei der Ersteinrichtung der Datenbank mit logischen Kopiervorgängen. Dieser Parameter wird nicht von `pgactive_init_copy command` verwendet. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Gibt die maximale Wartezeit für die DDL-Sperre an, bevor gleichzeitige Schreibtransaktionen erzwungen werden. Der Standardwert ist `-1`, der den in `max_standby_streaming_delay` eingestellten Wert übernimmt. Dieser Parameter akzeptiert Zeiteinheiten. Sie können ihn beispielsweise für 10 Sekunden auf 10 Sekunden einstellen. Während dieser Wartezeit versucht das System, DDL-Sperren zu erhalten, während es darauf wartet, dass laufende Schreibtransaktionen entweder festgeschrieben oder rückgängig gemacht werden. Weitere Informationen finden Sie unter „DDL-Sperren“. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Gibt an, wie lange ein DDL-Sperrversuch darauf wartet, die Sperre zu erhalten. Der Standardwert ist `-1`, der den in lock\$1timeout angegebenen Wert verwendet. Sie können diesen Parameter in Zeiteinheiten wie 10s für 10 Sekunden festlegen. Dieser Timer steuert nur die Wartezeit für den Erhalt einer DDL-Sperre. Sobald das System die Sperre erhält und den DDL-Vorgang startet, stoppt der Timer. Dieser Parameter begrenzt weder die Gesamtdauer, für die eine DDL-Sperre aufrechterhalten werden kann, noch die gesamte DDL-Betriebszeit. Um die Gesamtdauer des Vorgangs zu steuern, verwenden Sie stattdessen `statement_timeout`. Weitere Informationen finden Sie unter „DDL-Sperren“. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Setzt die standardmäßige Debug-Protokollebene für DDL-Sperrvorgänge in der `pgactive`-Erweiterung außer Kraft.- Wenn diese Einstellung konfiguriert ist, werden Meldungen im Zusammenhang mit DDL-Sperren auf der LOG-Debug-Ebene statt auf ihrer Standardebene ausgegeben. Verwenden Sie diesen Parameter, um DDL-Sperraktivität zu überwachen, ohne die ausführlichen Protokollebenen `DEBUG1` oder `DEBUG2` Protokollebenen auf Ihrem gesamten Server zu aktivieren. Verfügbare Protokollebenen, in aufsteigender Reihenfolge der Ausführlichkeit: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Weitere Informationen zu Überwachungsoptionen finden Sie unter „Überwachen globaler DDL-Sperren“. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
## Zusätzliche pgactive-Erweiterungsparameter
Die folgende Tabelle enthält weniger häufig verwendete und interne Konfigurationsoptionen, die für die `pgactive`-Erweiterung verfügbar sind.
| Parameter | Einheit | Standard | Description |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Legt eine Anwendungsverzögerung (in Millisekunden) für konfigurierte Verbindungen fest, deren `pgactive.pgactive_connections`-Eintrag keine explizite Anwendungsverzögerung enthält. Diese Verzögerung wird während der Knotenerstellung oder der Verbindungszeit festgelegt, und pgactive gibt eine Transaktion auf Peer-Knoten erst dann wieder, wenn mindestens die angegebene Anzahl von Millisekunden seit dem Festschreiben vergangen ist. Wird in erster Linie verwendet, um Netzwerke mit hoher Latenz in Testumgebungen zu simulieren, um das Erzeugen von Konflikten zu vereinfachen. Beispiel: Bei einer Verzögerung von 500 ms auf den Knoten A und B haben Sie nach dem Einfügen eines Werts auf Knoten A mindestens 500 ms Zeit, um eine widersprüchliche Einfügung auf Knoten B durchzuführen. Erfordert ein erneutes Laden des Servers oder einen Neustart der apply-Worker, um wirksam zu werden. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Gibt die Dauer (in Sekunden) an, für die ein Datenbank-Worker versucht, während fehlgeschlagener Versuche Verbindungen herzustellen. Der Worker unternimmt einen Verbindungsversuch pro Sekunde, bis er erfolgreich ist oder diesen Timeout-Wert erreicht. Diese Einstellung ist hilfreich, wenn die Datenbank-Engine gestartet wird, bevor der Worker bereit ist, Verbindungen herzustellen. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Steuert, wie DDL-Änderungen in Amazon RDS repliziert oder verarbeitet werden, wenn `pgactive` aktiviert ist. Wenn diese Option auf `on` festgelegt ist, verarbeitet der Knoten DDL-Änderungen wie ein Nicht-pgactive-Knoten. Die folgenden Anforderungen gelten bei der Verwendung dieses Parameters: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Sie können diesen Parameter mit Superuser-Berechtigungen auf zwei Arten ändern: global, lokal (Sitzungsebene). Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Dieser Parameter ist nur für die interne Verwendung vorgesehen. Wenn Sie diesen Parameter in einer Transaktion festlegen, werden die Änderungen nicht auf andere Knoten in Ihrem DB-Cluster repliziert. Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Dieser Parameter ist nur für die Verwendung durch Spezialisten vorgesehen. Es wird empfohlen, diesen Parameter nur zur Behebung bestimmter Replikationsprobleme zu verwenden. Verwenden Sie diesen Parameter in folgenden Fällen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Diese Einstellung überschreibt die folgende Fehlermeldung und ermöglicht Datendivergenzen, sodass die Replikation fortgesetzt werden kann: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Wenn Sie diesen Parameter falsch ändern, können Ihre Replikationseinrichtungen beschädigt werden. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Wenn dieser Wert auf `on` festgelegt ist, wird für jede Remote-Aktion, die nachgeschaltete apply-Worker verarbeiten, eine Protokollmeldung ausgegeben. Zu den Protokollen gehören: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) In den Protokollen werden auch DDL-Befehle und Tabellenabbrüche in der Warteschlange erfasst.para> Standardmäßig enthalten die Protokolle keine Zeilenfeldinhalte. Um Zeilenwerte in die Protokolle aufzunehmen, müssen Sie bei der Neukompilierung die folgenden Flags aktiviert haben: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Die Aktivierung dieser Protokollierungseinstellung kann sich auf die Leistung auswirken. Wir empfehlen, sie nur zu aktivieren, wenn sie zur Fehlerbehebung benötigt wird. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Sie können Verbindungsparameter für alle Peer-Knotenverbindungen mit pgactive-Knoten konfigurieren. Diese Parameter steuern Einstellungen wie Keepalives und SSL-Modi. Standardmäßig verwendet pgactive die folgenden Verbindungsparameter: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Verwenden Sie den folgenden ähnlichen Befehl, um die Standardparameter zu überschreiben: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Verbindungszeichenfolgen für einzelne Knoten haben Vorrang vor diesen Einstellungen und den integrierten Verbindungsoptionen von pgactive. Weitere Informationen zu Formaten für Verbindungszeichenfolgen finden Sie unter [libpq-Verbindungszeichenfolgen](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Wir empfehlen, die Keepalive-Standardeinstellungen aktiviert zu lassen. Deaktivieren Sie Keepalives nur, wenn Sie Probleme mit großen Transaktionen haben, die über unzuverlässige Netzwerke abgeschlossen werden. Wir empfehlen, die Keepalive-Standardeinstellungen aktiviert zu lassen. Deaktivieren Sie Keepalives nur, wenn Sie Probleme mit großen Transaktionen haben, die über unzuverlässige Netzwerke abgeschlossen werden. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Gibt die Anzahl der parallelen Aufträge an, die `pg_dump` und `pg_restore` bei logischen Knotenverbindungen mit der Funktion `pgactive.pgactive_join_group` verwenden können. Änderungen an dieser Einstellung werden wirksam, wenn Sie die Konfiguration neu laden. Sie müssen den Server nicht neu starten. |
| pgactive.max\$1nodes | `int` | 4 | Gibt die maximal zulässige Anzahl von Knoten in einer pgactive-Erweiterungsgruppe an. Der Standardwert beträgt 4 Knoten. Sie müssen die folgenden Punkte berücksichtigen, wenn Sie den Wert dieses Parameters festlegen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Sie können diesen Parameter auf zwei Arten festlegen: in der Konfigurationsdatei mit dem Befehl `ALTER SYSTEM SET` Der Standardwert für diesen Parameter ist `4`, was bedeutet, dass zu jedem Zeitpunkt maximal 4 Knoten in der `pgactive`-Erweiterungsgruppe zulässig sind. Die Änderung wird wirksam, nachdem Sie den Server neu gestartet haben. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Dieser Parameter ist nur für die interne Verwendung vorgesehen. Wenn er aktiviert ist, ermöglicht die `pgactive`-Erweiterung die Erstellung der Getter-Funktion für die pgactive-Knoten-ID. |
# Grundlegendes zu active-active-Konflikten
Wenn Sie pgactive im active-active-Modus verwenden, kann das Schreiben in dieselben Tabellen über mehrere Knoten zu Datenkonflikten führen. Während einige Clustering-Systeme verteilte Sperren verwenden, um gleichzeitigen Zugriff zu verhindern, verfolgt pgactive einen optimistischen Ansatz, der sich besser für geografisch verteilte Anwendungen eignet.
Einige Clustering-Systeme von Datenbanken verhindern den gleichzeitigen Datenzugriff mithilfe von verteilten Sperren. Dieser Ansatz funktioniert zwar, wenn sich Server in unmittelbarer Nähe befinden, unterstützt jedoch keine geografisch verteilten Anwendungen, da er für eine gute Leistung eine extrem geringe Latenz erfordert. Anstelle von verteilten Sperren (ein pessimistischer Ansatz) verwendet die pgactive-Erweiterung einen optimistischen Ansatz. Das heißt:
+ Sie hilft Ihnen, Konflikte nach Möglichkeit zu vermeiden.
+ Sie lässt das Auftreten bestimmter Arten von Konflikten zu.
+ Sie stellt Konfliktlösungen bereit, wenn Konflikte auftreten.
Dieser Ansatz bietet Ihnen mehr Flexibilität beim Erstellen verteilter Anwendungen.
## So entstehen Konflikte
Konflikte zwischen Knoten entstehen durch Abfolgen von Ereignissen, die nicht auftreten könnten, wenn alle beteiligten Transaktionen gleichzeitig auf demselben Knoten stattfinden würden. Da die Knoten Änderungen erst nach dem Festschreiben von Transaktionen austauschen, ist jede Transaktion einzeln auf dem Knoten gültig, auf dem sie festgeschrieben wurde. Sie wäre jedoch nicht gültig, wenn sie auf einem anderen Knoten ausgeführt würde, der in der Zwischenzeit andere Aufgaben durchgeführt hat. Da „pgactive apply“ die Transaktion im Wesentlichen auf den anderen Knoten wiedergibt, kann der Wiedergabevorgang fehlschlagen, wenn ein Konflikt zwischen einer angewendeten Transaktion und einer Transaktion besteht, die auf dem Empfängerknoten festgeschrieben wurde.
Der Grund dafür, dass die meisten Konflikte nicht auftreten können, wenn alle Transaktionen auf einem einzigen Knoten ausgeführt werden, besteht darin, dass PostgreSQL über Kommunikationsmechanismen zwischen Transaktionen verfügt, um dies zu verhindern. Hierzu zählen die folgenden:
+ UNIQUE-Indizes
+ SEQUENCEs
+ Sperren von Zeilen und Beziehungen
+ Nachverfolgung von SERIALIZABLE-Abhängigkeiten
All diese Mechanismen sind Möglichkeiten der Kommunikation zwischen Transaktionen zur Vermeidung unerwünschter Parallelitätsprobleme.
pgactive erreicht eine niedrige Latenz und verarbeitet Netzwerkpartitionen gut, da es keinen verteilten Transaktionsmanager oder Sperrmanager verwendet. Dies bedeutet jedoch, dass Transaktionen auf verschiedenen Knoten völlig isoliert voneinander ausgeführt werden. Während die Isolierung in der Regel zu einer Verbesserung der Datenbankkonsistenz beiträgt, müssen Sie sie in diesem Fall reduzieren, um Konflikte zu vermeiden.
## Typen von Konflikten
Zu den möglichen Konflikten gehören:
**Topics**
+ [
### PRIMARY KEY- oder UNIQUE-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [
### INSERT/INSERT-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [
### INSERTs die gegen mehrere UNIQUE-Einschränkungen verstoßen
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [
### UPDATE/UPDATE-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [
### UPDATE-Konflikte beim PRIMARY KEY
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [
### UPDATEs die gegen mehrere UNIQUE-Einschränkungen verstoßen
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [
### UPDATE/DELETE-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [
### INSERT/UPDATE-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [
### DELETE/DELETE-Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [
### Konflikte bei Fremdschlüsseleinschränkungen
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [
### Konflikte bei Ausschlusseinschränkungen
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [
### Konflikte bei globalen Daten
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [
### Sperrkonflikte und Deadlock-Abbrüche
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [
### Divergierende Konflikte
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### PRIMARY KEY- oder UNIQUE-Konflikte
Zeilenkonflikte treten auf, wenn mehrere Vorgänge versuchen, denselben Zeilenschlüssel auf eine Weise zu ändern, die auf einem einzelnen Knoten nicht möglich ist. Diese Konflikte stellen den häufigsten Typ von Datenkonflikten dar.
pgactive löst erkannte Konflikte durch last-update-wins Handling oder Ihren benutzerdefinierten Konflikthandler.
Zu den Zeilenkonflikten gehören:
+ INSERT vs. INSERT
+ INSERT vs. UPDATE
+ UPDATE vs. DELETE
+ INSERT vs. DELETE
+ DELETE vs. DELETE
+ INSERT vs. DELETE
### INSERT/INSERT-Konflikte
Dieser häufigste Konflikt tritt auf, wenn INSERTs auf zwei verschiedenen Knoten ein Tupel mit denselben PRIMARY KEY-Werten (oder identischen UNIQUE-Einschränkungswerten, wenn kein PRIMARY KEY existiert) erstellt wird.
pgactivelink löst INSERT-Konflikte, indem es den Zeitstempel des ursprünglichen Hosts verwendet, um das neueste Tupel beizubehalten. Sie können dieses Standardverhalten mit dem benutzerdefinierten Konflikt-Handler außer Kraft setzen. Dieser Prozess erfordert zwar keine spezielle Administratoraktion, beachten Sie jedoch, dass pgactivelink einen der INSERT-Vorgänge auf allen Knoten verwirft. Es findet keine automatische Datenzusammenführung statt, es sei denn, der benutzerdefinierte Handler implementiert sie.
pgactivelink kann nur Konflikte lösen, die eine einzelne Einschränkungsverletzung betreffen. Wenn ein INSERT-Vorgang gegen mehrere UNIQUE-Einschränkungen verstößt, müssen Sie zusätzliche Strategien zur Konfliktlösung implementieren.
### INSERTs die gegen mehrere UNIQUE-Einschränkungen verstoßen
Ein INSERT/INSERT Konflikt kann mehrere UNIQUE-Einschränkungen verletzen, einschließlich des PRIMÄRSCHLÜSSEL. pgactivelink kann nur Konflikte behandeln, die eine einzige UNIQUE-Einschränkung beinhalten. Wenn Konflikte mehrere UNIQUE-Einschränkungen verletzen, schlägt der Apply-Worker fehl und gibt den folgenden Fehler zurück:
`multiple unique constraints violated by remotely INSERTed tuple.`
In älteren Versionen führte diese Situation stattdessen zu dem Fehler „diverging uniqueness conflict“.
Um diese Konflikte zu lösen, müssen Sie manuelle Maßnahmen ergreifen. Führen Sie für die widersprüchlichen lokalen Tupel entweder einen DELETE- oder einen UPDATE-Vorgang durch, um Konflikte mit dem neuen Remote-Tupel zu beseitigen. Beachten Sie, dass Sie möglicherweise mehrere in Konflikt stehende Tupel beheben müssen. Derzeit stellt pgactivelink keine integrierten Funktionen zum Ignorieren, Verwerfen oder Zusammenführen von Tupeln bereit, die gegen mehrere eindeutige Einschränkungen verstoßen.
**Anmerkung**
Weitere Informationen finden Sie unter Verstöße gegen mehrere UPDATEs UNIQUE-Einschränkungen.
### UPDATE/UPDATE-Konflikte
Dieser Konflikt tritt auf, wenn zwei Knoten gleichzeitig dasselbe Tupel ändern, ohne seinen PRIMÄRSCHLÜSSEL zu ändern. pgactivelink löst diese Konflikte mithilfe von last-update-wins Logik oder Ihrem benutzerdefinierten Konflikthandler, falls definiert. Ein PRIMARY KEY ist für den Tupel-Abgleich und die Konfliktlösung unerlässlich. Für Tabellen ohne PRIMARY KEY lehnt pgactivelink UPDATE-Vorgänge mit dem folgenden Fehler ab:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### UPDATE-Konflikte beim PRIMARY KEY
Für pgactive gelten Einschränkungen beim Verarbeiten von PRIMARY KEY-Aktualisierungen. Sie können zwar eine UPDATE-Operation für einen PRIMÄRSCHLÜSSEL ausführen, aber pgactive kann Konflikte nicht automatisch mithilfe der Logik für diese Operationen lösen. last-update-wins Sie müssen sicherstellen, dass die PRIMARY KEY-Aktualisierungen nicht mit vorhandenen Werten in Konflikt stehen. Wenn während der PRIMARY KEY-Aktualisierungen Konflikte auftreten, werden diese zu divergierenden Konflikten, die Ihr manuelles Eingreifen erfordern. Weitere Informationen zum Umgang mit diesen Situationen finden Sie unter [Divergierende Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs die gegen mehrere UNIQUE-Einschränkungen verstoßen
pgactivelink kann keine last-update-wins Konfliktlösung anwenden, wenn ein eingehendes UPDATE gegen mehrere UNIQUE-Einschränkungen oder PRIMARY KEY-Werte verstößt. Dieses Verhalten entspricht INSERT-Vorgängen mit mehreren Einschränkungsverstößen. Diese Situationen führen zu divergierenden Konflikten, die Ihr manuelles Eingreifen erfordern. Weitere Informationen finden Sie unter [Divergierende Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATE/DELETE-Konflikte
Diese Konflikte treten auf, wenn UPDATEs ein Knoten eine Zeile und ein anderer Knoten gleichzeitig gleichzeitig vorhanden ist. DELETEs In diesem Fall tritt bei der Wiedergabe ein UPDATE/DELETE Konflikt auf. Die Lösung besteht darin, alle nach einem DELETE-Vorgang eingehenden UPDATE-Vorgänge zu verwerfen, sofern der benutzerdefinierte Konflikt-Handler nichts anderes angibt.
pgactivelink erfordert einen PRIMARY KEY, um Tupel abzugleichen und Konflikte zu lösen. Für Tabellen ohne PRIMARY KEY lehnt pgactivelink UPDATE-Vorgänge mit dem folgenden Fehler ab:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**Anmerkung**
pgactivelink kann nicht zwischen und Konflikten unterscheiden. UPDATE/DELETE INSERT/UPDATE In beiden Fällen wirkt sich ein UPDATE-Vorgang auf eine nicht vorhandene Zeile aus. Aufgrund der asynchronen Replikation und der fehlenden Reihenfolge der Wiederholung zwischen den Knoten kann pgactivelink nicht feststellen, ob der UPDATE-Vorgang für eine neue Zeile (INSERT noch nicht empfangen) oder für eine gelöschte Zeile gilt. In beiden Szenarien wird der UPDATE-Vorgang von pgactivelink verworfen.
### INSERT/UPDATE-Konflikte
Dieser Konflikt kann in Umgebungen mit mehreren Knoten auftreten. Es passiert, wenn INSERTs ein Knoten eine Zeile, ein zweiter Knoten UPDATEs sie und ein dritter Knoten das UPDATE vor dem ursprünglichen INSERT empfängt. Standardmäßig löst pgactivelink diese Konflikte, indem es den UPDATE-Vorgang verwirft, sofern der benutzerdefinierte Konflikt-Trigger nichts anderes angibt. Beachten Sie, dass diese Lösungsmethode zu Dateninkonsistenzen zwischen den Knoten führen kann. Weitere Informationen zu ähnlichen Szenarien und deren Handhabung finden Sie unter [UPDATE/DELETE-Konflikte](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### DELETE/DELETE-Konflikte
Dieser Konflikt tritt auf, wenn zwei verschiedene Knoten gleichzeitig dasselbe Tupel löschen. pgactivelink betrachtet diese Konflikte als harmlos, da das Endergebnis beider DELETE-Vorgänge identisch ist. In diesem Szenario ignoriert pgactivelink sicher einen der DELETE-Vorgänge, ohne die Datenkonsistenz zu beeinträchtigen.
### Konflikte bei Fremdschlüsseleinschränkungen
FOREIGN KEY-Einschränkungen können zu Konflikten führen, wenn Remote-Transaktionen auf vorhandene lokale Daten angewendet werden. Diese Konflikte treten in der Regel auf, wenn Transaktionen in einer anderen Reihenfolge als in ihrer logischen Reihenfolge auf die Ursprungsknoten angewendet werden.
Standardmäßig wendet pgactive Änderungen mit session\$1replication\$1role als `replica` an, wodurch Fremdschlüsselprüfungen während der Replikation umgangen werden. In active-active-Konfigurationen kann dies zu Verstößen bei Fremdschlüsseln führen. Die meisten Verstöße sind vorübergehend und werden behoben, sobald die Replikation abgeschlossen ist. Es können jedoch hängende Fremdschlüssel auftreten, da pgactive das knotenübergreifende Sperren von Zeilen nicht unterstützt.
Dieses Verhalten ist partitionstoleranten asynchronen active-active-Systemen inhärent. Beispielsweise kann Knoten A eine neue untergeordnete Zeile einfügen und Knoten B gleichzeitig seine übergeordnete Zeile löschen. Das System kann diese Art der gleichzeitigen knotenübergreifenden Änderung nicht verhindern.
Zur Minimierung von Fremdschlüsselkonflikten wird Folgendes empfohlen:
+ Beschränken Sie Fremdschlüsselbeziehungen auf eng verwandte Entitäten.
+ Ändern Sie verwandte Entitäten, wenn möglich, über einen einzigen Knoten.
+ Wählen Sie Entitäten aus, die selten geändert werden müssen.
+ Implementieren Sie die Parallelitätssteuerung auf Anwendungsebene für Änderungen.
### Konflikte bei Ausschlusseinschränkungen
pgactivelink unterstützt keine Ausschlusseinschränkungen und beschränkt deren Erstellung.
**Anmerkung**
Wenn Sie eine vorhandene eigenständige Datenbank in eine pgactivelink-Datenbank konvertieren, löschen Sie manuell alle Ausschlussbeschränkungen.
In einem verteilten asynchronen System lässt sich nicht gewährleisten, dass kein Satz von Zeilen gegen die Einschränkung verstößt. Dies liegt daran, dass alle Transaktionen auf verschiedenen Knoten vollständig isoliert sind. Ausschlusseinschränkungen können zu Deadlocks bei der Wiederholung führen, sodass die Wiederholung aufgrund von Verstößen gegen Ausschlusseinschränkungen nicht von einem Knoten zum anderen fortgesetzt werden kann.
Wenn Sie pgactivelink zwingen, eine Ausschlusseinschränkung zu erstellen, oder wenn Sie beim Konvertieren einer eigenständigen Datenbank in pgactivelink vorhandene Einschränkungen nicht löschen, führt dies möglicherweise zu einer Unterbrechung der Replikation. Um den Replikationsfortschritt wiederherzustellen, entfernen oder ändern Sie die lokalen Tupel, die mit einem eingehenden Remote-Tupel in Konflikt stehen, sodass die Remote-Transaktion angewendet werden kann.
### Konflikte bei globalen Daten
Bei der Verwendung von pgactivelink können Konflikte auftreten, wenn Knoten unterschiedliche globale systemweite PostgreSQL-Daten wie beispielsweise Rollen aufweisen. Diese Konflikte können dazu führen, dass Vorgänge – in erster Linie DDL – auf einem Knoten erfolgreich ausgeführt und festgeschrieben, jedoch nicht auf andere Knoten angewendet werden.
Wenn ein Benutzer auf einem Knoten vorhanden ist, auf einem anderen jedoch nicht, können Replikationsprobleme auftreten:
+ Node1 verfügt über einen Benutzer namens `fred`, der jedoch nicht auf Node2 vorhanden ist.
+ Wenn `fred` eine Tabelle auf Node1 erstellt, wird die Tabelle mit `fred` als Eigentümer repliziert.
+ Wenn dieser DDL-Befehl auf Node2 angewendet wird, schlägt er fehl, da der Benutzer `fred` nicht vorhanden ist.
+ Dieser Fehler generiert einen ERROR in den PostgreSQL-Protokollen auf Node2 und erhöht den Zähler `pgactive.pgactive_stats.nr_rollbacks`.
**Lösung:** Erstellen Sie den Benutzer `fred` auf Node2. Der Benutzer benötigt keine identischen Berechtigungen, sondern muss auf beiden Knoten vorhanden sein.
Wenn eine Tabelle auf einem Knoten vorhanden ist, auf einem anderen jedoch nicht, schlagen Datenänderungsvorgänge fehl:
+ Node1 verfügt über eine Tabelle mit dem Namen `foo`, die auf Node2 nicht vorhanden ist.
+ Alle DML-Vorgänge in der Tabelle `foo` auf Node1 schlagen fehl, wenn sie auf Node2 repliziert werden.
**Lösung:** Erstellen Sie die Tabelle `foo` auf Node2 mit derselben Struktur.
**Anmerkung**
pgactivelink repliziert derzeit keine CREATE USER-Befehle oder DDL-Vorgänge. Die DDL-Replikation ist für eine zukünftige Version geplant.
### Sperrkonflikte und Deadlock-Abbrüche
Da „pgactive apply“-Prozesse wie normale Benutzersitzungen funktionieren, folgen sie den Standardregeln für das Sperren von Zeilen und Tabellen. Dies kann dazu führen, dass „pgactive apply“-Prozesse auf Sperren warten, die von Benutzertransaktionen oder anderen apply-Prozessen gehalten werden.
Die folgenden Typen von Sperren können sich auf apply-Prozesse auswirken:
+ Explizites Sperren auf Tabellenebene (LOCK TABLE...) durch Benutzersitzungen
+ Explizites Sperren auf Zeilenebene (SELECT... FOR UPDATE/FOR SHARE) nach Benutzersitzungen
+ Sperren mit Fremdschlüsseln
+ Implizites Sperren aufgrund von Zeilen UPDATEs, INSERTs, oder DELETEs, entweder aufgrund lokaler Aktivitäten oder aufgrund von Anwendungen von anderen Servern
Deadlocks können auftreten zwischen
+ einem „pgactivelink apply“-Prozess und einer Benutzertransaktion,
+ zwei apply-Prozessen.
Wenn Deadlocks auftreten, beendet Deadlock Detector von PostgreSQL eine der problematischen Transaktionen. Wenn der Prozess des „pgactivelink apply“-Workers beendet wird, versucht er es automatisch erneut, was in der Regel erfolgreich ist.
**Anmerkung**
Diese Probleme sind vorübergehend und erfordern im Allgemeinen kein Eingreifen des Administrators. Wenn ein apply-Prozess durch die Sperre einer inaktiven Benutzersitzung für einen längeren Zeitraum blockiert wird, können Sie die Benutzersitzung beenden, um die Replikation fortzusetzen. Diese Situation ähnelt einer Situation, in der ein Benutzer eine lange Sperre hält, die sich auf eine andere Benutzersitzung auswirkt.
Um Verzögerungen bei der Wiederholung im Zusammenhang mit Sperren zu identifizieren, aktivieren Sie die Funktion `log_lock_waits` in PostgreSQL.
### Divergierende Konflikte
Divergierende Konflikte treten auf, wenn Daten, die knotenübergreifend identisch sein sollten, unerwartet voneinander abweichen. Obwohl diese Konflikte nicht auftreten sollten, können Sie in der aktuellen Implementierung nicht alle zuverlässig verhindert werden.
**Anmerkung**
Das Ändern des PRIMARY KEY einer Zeile kann zu unterschiedlichen Konflikten führen, wenn ein anderer Knoten den Schlüssel derselben Zeile ändert, bevor alle Knoten die Änderung verarbeiten. Vermeiden Sie es, Primärschlüssel zu ändern, oder beschränken Sie Änderungen auf einen bestimmten Knoten. Weitere Informationen finden Sie unter [UPDATE-Konflikte beim PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
Divergierende Konflikte, die Zeilendaten betreffen, erfordern in der Regel ein Eingreifen des Administrators. Um diese Konflikte zu lösen, müssen Sie die Daten auf einem Knoten manuell so anpassen, dass sie mit denen eines anderen Knotens übereinstimmen, und gleichzeitig die Replikation mit `pgactive.pgactive_do_not_replicate` vorübergehend deaktivieren. Diese Konflikte sollten nicht auftreten, wenn Sie pgactive wie dokumentiert verwenden und Einstellungen oder Funktionen vermeiden, die als unsicher markiert sind.
Als Administrator müssen Sie diese Konflikte manuell lösen. Je nach Konflikttyp ist die Verwendung erweiterter Optionen wie `pgactive.pgactive_do_not_replicate` erforderlich. Nutzen Sie diese Optionen mit Vorsicht, da sich die Situation durch eine unsachgemäße Verwendung verschlechtern kann. Aufgrund der Vielzahl möglicher Konflikte können wir keine allgemeingültigen Lösungsansätze bereitstellen.
Divergierende Konflikte treten auf, wenn Daten, die auf verschiedenen Knoten identisch sein sollten, unerwartet voneinander abweichen. Obwohl diese Konflikte nicht auftreten sollten, können Sie in der aktuellen Implementierung nicht alle zuverlässig verhindert werden.
## Vermeiden oder Tolerieren von Konflikten
In den meisten Fällen können Sie ein geeignetes Anwendungsdesign verwenden, um Konflikte zu vermeiden oder die Anwendung konflikttolerant zu gestalten.
Konflikte treten nur auf, wenn Vorgänge auf mehreren Knoten gleichzeitig ausgeführt werden. So vermeiden Sie Konflikte:
+ Schreiben Sie nur in einen Knoten.
+ Schreiben Sie in unabhängige Datenbankuntergruppen auf jedem Knoten (weisen Sie beispielsweise jedem Knoten ein separates Schema zu).
Verwenden Sie bei „INSERT vs. INSERT“-Konflikten globale Sequenzen, um Konflikte vollständig zu vermeiden.
Wenn Konflikte für Ihren Anwendungsfall nicht akzeptabel sind, sollten Sie die Implementierung verteilter Sperren auf Anwendungsebene erwägen. Häufig ist es am besten, die Anwendung so zu gestalten, dass sie mit den Konfliktlösungsmechanismen von pgactive funktioniert, anstatt zu versuchen, alle Konflikte zu vermeiden. Weitere Informationen finden Sie unter [Typen von Konflikten](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Protokollierung von Konflikten
pgactivelink protokolliert Konfliktvorfälle in der Tabelle `pgactive.pgactive_conflict_history`, um Sie bei der Diagnose und Behandlung von active-active-Konflikten zu unterstützen. Die Konfliktprotokollierung in dieser Tabelle erfolgt nur, wenn Sie `pgactive.log_conflicts_to_table` auf „true“ festlegen. Die pgactive-Erweiterung protokolliert Konflikte auch dann in der PostgreSQL-Protokolldatei, wenn log\$1min\$1messages auf `LOG` oder `lower` festgelegt ist, und zwar unabhängig von der Einstellung `pgactive.log_conflicts_to_table`.
Verwenden Sie die Konfliktverlaufstabelle, um die folgenden Schritte auszuführen:
+ Messen, wie häufig die Anwendung Konflikte verursacht
+ Identifizieren, wo Konflikte auftreten
+ Verbessern der Anwendung zur Reduzierung der Konfliktrate
+ Erkennen von Fällen, in denen Konfliktlösungen nicht zu den gewünschten Ergebnissen führen
+ Ermitteln, wo benutzerdefinierte Konfliktauslöser oder Änderungen am Anwendungsdesign benötigt werden
Bei Zeilenkonflikten können Sie optional Zeilenwerte protokollieren. Dies wird durch die Einstellung `pgactive.log_conflicts_to_table` gesteuert. Beachten Sie Folgendes:
+ Dies ist eine globale datenbankweite Option.
+ Es gibt keine tabellenbezogene Kontrolle über die Protokollierung von Zeilenwerten.
+ Für Feldnummern, Array-Elemente oder Feldlängen gelten keine Beschränkungen.
+ Die Aktivierung dieser Funktion ist möglicherweise nicht ratsam, wenn Sie mit Zeilen mit mehreren Megabyte arbeiten, die Konflikte auslösen können.
Da die Konfliktverlaufstabelle Daten aus jeder Tabelle in der Datenbank (jede mit potenziell unterschiedlichen Schemas) enthält, werden protokollierte Zeilenwerte als JSON-Felder gespeichert. Die JSON-Datei wird mit `row_to_json` erstellt, ähnlich wie beim direkten Aufruf aus SQL. PostgreSQL bietet keine `json_to_row` Funktion, daher benötigen Sie tabellenspezifischen Code (in usw.)PL/pgSQL, PL/Python, PL/Perl, um ein zusammengesetztes Tupel aus dem protokollierten JSON zu rekonstruieren.
**Anmerkung**
Die Unterstützung für benutzerdefinierte Konflikte ist als zukünftige Erweiterungsfunktion geplant.
# Verstehen des pgactive-Schemas
Das pgactive-Schema verwaltet die Active-Active-Replikation in RDS für PostgreSQL. Dieses Schema enthält Tabellen, in denen die Replikationskonfiguration und Statusinformationen gespeichert werden.
**Anmerkung**
Das pgactive-Schema entwickelt sich weiter und kann geändert werden. Ändern Sie die Daten in diesen Tabellen nicht direkt.
Zu den wichtigsten Tabellen im pgactive-Schema gehören:
+ `pgactive_nodes` – Speichert Informationen über Knoten in der aktiv-aktiven Replikationsgruppe.
+ `pgactive_connections` – Speichert Verbindungsdetails für jeden Knoten.
## pgactive\$1nodes
Die Datei „pgactive\$1nodes“ speichert Informationen zu den Knoten, die an der active-active-Replikationsgruppe teilnehmen.
| Spalte | Typ | Kollation | NULLABLE | Standard |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | nicht NULL | – |
| node\$1timeline | oid | – | nicht NULL | – |
| node\$1dboid | oid | – | nicht NULL | – |
| node\$1status | char | – | nicht NULL | – |
| node\$1name | text | – | nicht NULL | – |
| knoten\$1dsn | text | – | nicht NULL | – |
| node\$1init\$1from\$1dsn | text | – | nicht NULL | – |
| node\$1read\$1only | boolesch | – | – | false |
| node\$1seq\$1id | smallint | – | nicht NULL | – |
**node\$1sysid**
Eindeutige ID für einen Knoten, generiert während `pgactive_create_group` oder `pgactive_join_group`
**node\$1status**
Bereitschaft des Knotens:
+ **b** – Beginn der Einrichtung
+ **i** – wird initialisiert
+ **c** – catchup
+ **o** – Outbound-Slots erstellen
+ **r** – bereit
+ **k** – beendet
Diese Spalte gibt nicht an, ob ein Knoten verbunden oder getrennt ist.
**node\$1name**
Vom Benutzer bereitgestellter eindeutiger Knotenname
**knoten\$1dsn**
Verbindungszeichenfolge oder Name der Benutzerzuordnung
**node\$1init\$1from\$1dsn**
DSN, aus dem dieser Knoten erstellt wurde.
## pgactive\$1connection
Die pgactive\$1connections speichert Verbindungsdetails für jeden Knoten.
| Spalte | Typ | Kollation | NULLABLE | Standard |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | Keine | nicht NULL | Keine |
| conn\$1timeline | oid | Keine | nicht NULL | Keine |
| conn\$1dboid | oid | Keine | nicht NULL | Keine |
| conn\$1dsn | text | Keine | nicht NULL | Keine |
| conn\$1apply\$1delay | Ganzzahl | Keine | Keine | Keine |
| conn\$1replication\$1sets | text | Keine | Keine | Keine |
conn\$1sysid
Knoten-ID für den Knoten, auf den sich dieser Eintrag bezieht.
conn\$1dsn
Wie pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Wenn diese Option festgelegt ist, warten Sie Millisekunden, bevor jede Transaktion vom Remote-Knoten angewendet wird. Dient in erster Linie zum Debuggen. Bei Null gilt der globale Standard.
## Arbeiten mit Replikationssätzen
Replikationssätze bestimmen, welche Tabellen in Replikationsvorgänge aufgenommen oder von ihnen ausgeschlossen werden sollen. Standardmäßig werden alle Tabellen repliziert, sofern Sie mit den folgenden Funktionen nichts anderes angeben:
+ `pgactive_exclude_table_replication_set()` – Schließt angegebene Tabellen von der Replikation aus.
+ `pgactive_include_table_replication_set()` – Schließt bestimmte Tabellen in die Replikation ein.
**Anmerkung**
Berücksichtigen Sie Folgendes, bevor Sie Replikationssätze konfigurieren:
Sie können das Ein- oder Ausschließen von Tabellen erst nach der Ausführung von `pgactive_create_group()`, aber vor der Ausführung von `pgactive_join_group()` konfigurieren.
Nachdem Sie `pgactive_exclude_table_replication_set()` verwendet haben, kann `pgactive_include_table_replication_set()` nicht mehr verwendet werden.
Nachdem Sie `pgactive_include_table_replication_set()` verwendet haben, kann `pgactive_exclude_table_replication_set()` nicht mehr verwendet werden.
Das System behandelt neu erstellte Tabellen je nach Ihrer ursprünglichen Konfiguration unterschiedlich:
+ Wenn Sie Tabellen ausgeschlossen haben: Alle neuen Tabellen, die nach `pgactive_join_group()` erstellt wurden, werden automatisch in die Replikation einbezogen.
+ Wenn Sie Tabellen ausgeschlossen haben: Alle neuen Tabellen, die nach `pgactive_join_group()` erstellt wurden, werden automatisch aus der Replikation ausgeschlossen.
Verwenden Sie die Funktion `pgactive.pgactive_get_table_replication_sets()`, um die Replikationssatz-Konfiguration für eine bestimmte Tabelle anzuzeigen.
# Referenz für pgactive-Funktionen
Im Folgenden finden Sie eine Liste der pgactive-Funktionen mit ihren Parametern, Rückgabewerten und praktischen Anwendungshinweisen, die Ihnen dabei helfen, sie effektiv zu verwenden:
## get\$1last\$1applied\$1xact\$1info
Ruft die zuletzt angewendeten Transaktionsinformationen für einen angegebenen Knoten ab.
**Argumente**
+ sysid (Text) - Zeitleisten-OID
+ dboid (OID)
**Rückgabetyp**
Folgende Aktionen werden aufgezeichnet:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (Zeitstempel mit Zeitzone)
+ last\$1applied\$1xact\$1at (Zeitstempel mit Zeitzone)
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die zuletzt angewendeten Transaktionsinformationen für einen bestimmten Knoten abzurufen.
## pgactive\$1apply\$1pause
Hält den Prozess zum Anwenden der Replikation an.
**Argumente**
Keine
**Rückgabetyp**
Boolean
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Prozess zum Anwenden der Replikation anzuhalten.
## pgactive\$1apply\$1resume
Setzt den Prozess zum Anwenden der Replikation fort.
**Argumente**
Keine
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Prozess zum Anwenden der Replikation fortzusetzen.
## pgactive\$1is\$1apply\$1paused
Prüft, ob die Anwendung der Replikation derzeit angehalten wurde.
**Argumente**
Keine
**Rückgabetyp**
Boolean
**Nutzungshinweise**
Verwenden Sie diese Funktion, um zu überprüfen, ob die Anwendung der Replikation derzeit angehalten wurde.
## pgactive\$1create\$1group
Erstellt eine pgactive-Gruppe, indem eine eigenständige Datenbank in den ursprünglichen Knoten konvertiert wird.
**Argumente**
+ node\$1name (Text)
+ node\$1dsn (Text)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Rückgabetyp**
void
**Nutzungshinweise**
Erstellt eine pgactive-Gruppe, indem eine eigenständige Datenbank in den ursprünglichen Knoten konvertiert wird. Die Funktion führt Plausibilitätsprüfungen durch, bevor der Knoten in einen pgactive-Knoten umgewandelt wird. Vergewissern Sie sich vor der Verwendung der Funktion, dass für die PostgreSQL-Cluster eine ausreichende Anzahl von `max_worker_processes` zur Verfügung steht, um die pgactive-Hintergrund-Worker zu unterstützen.
## pgactive\$1detach\$1nodes
Entfernt die angegebenen Knoten aus der pgactive-Gruppe.
**Argumente**
+ p\$1nodes (text[])
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die angegebenen Knoten aus der pgactive-Gruppe zu entfernen.
## pgactive\$1exclude\$1table\$1replication\$1set
Schließt eine bestimmte Tabelle von der Replikation aus.
**Argumente**
+ p\$1relation (regclass)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um eine bestimmte Tabelle von der Replikation auszuschließen.
## pgactive\$1get\$1replication\$1lag\$1info
Ruft detaillierte Informationen zur Replikationsverzögerung ab, einschließlich Knotendetails, WAL-Status und LSN-Werten.
**Argumente**
Keine
**Rückgabetyp**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Ungefähre WAL-Größe in Byte, die auf dem Senderknoten dekodiert werden soll - pending\$1wal\$1to\$1apply bigint - Ungefähre WAL-Größe in Byte, die auf den Empfängerknoten angewendet werden soll - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um Informationen zur Replikationsverzögerung abzurufen, einschließlich Knotendetails, WAL-Status und LSN-Werten.
## pgactive\$1get\$1stats
Ruft pgactive-Replikationsstatistiken ab.
**Argumente**
Keine
**Rückgabetyp**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**Nutzungshinweise**
Verwenden Sie diese Funktion, um pgactive-Replikationsstatistiken abzurufen.
## pgactive\$1get\$1table\$1replication\$1sets
Ruft die Replikationssatzkonfiguration für eine bestimmte Relation ab.
**Argumente**
+ relation (regclass)
**Rückgabetyp**
SETOF-Datensatz
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die Replikationssatzkonfiguration für eine bestimmte Relation abzurufen.
## pgactive\$1include\$1table\$1replication\$1set
Schließt eine bestimmte Tabelle in die Replikation ein.
**Argumente**
+ p\$1relation (regclass)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um eine bestimmte Tabelle in die Replikation einzubeziehen.
## pgactive\$1join\$1group
Fügt einer vorhandenen pgactive-Gruppe einen Knoten hinzu.
**Argumente**
+ node\$1name (Text)
+ node\$1dsn (Text)
+ join\$1using\$1dsn (Text)
+ apply\$1delay (Ganzzahl, optional)
+ replication\$1sets (text[], Standard: ['default'])
+ bypass\$1collation\$1check (boolesch, Standard: false)
+ bypass\$1node\$1identifier\$1creation (boolesch, Standard: false)
+ bypass\$1user\$1tables\$1check (boolesch, Standard: false)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um einer vorhandenen pgactive-Gruppe einen Knoten hinzuzufügen. Vergewissern Sie sich, dass der PostgreSQL-Cluster über eine ausreichende Anzahl von max\$1worker\$1processes für die pgactive-Hintergrund-Worker verfügt.
## pgactive\$1remove
Entfernt alle pgactive-Komponenten vom lokalen Knoten.
**Argumente**
+ force (boolesch, Standard: false)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um alle pgactive-Komponenten vom lokalen Knoten zu entfernen.
## pgactive\$1snowflake\$1id\$1nextval
Generiert knotenspezifische eindeutige Sequenzwerte.
**Argumente**
+ regclass
**Rückgabetyp**
bigint
**Nutzungshinweise**
Verwenden Sie diese Funktion, um knotenspezifische eindeutige Sequenzwerte zu generieren.
## pgactive\$1update\$1node\$1conninfo
Aktualisiert die Verbindungsinformationen für einen pgactive-Knoten.
**Argumente**
+ node\$1name\$1to\$1update (Text)
+ node\$1dsn\$1to\$1update (Text)
**Rückgabetyp**
void
**Nutzungshinweise**
Verwenden Sie diese Funktion, um die Verbindungsinformationen für einen pgactive-Knoten zu aktualisieren.
## pgactive\$1wait\$1for\$1node\$1ready
Überwacht den Fortschritt der Gruppenerstellung oder der Zusammenführung.
**Argumente**
+ timeout (Ganzzahl, Standard: 0)
+ progress\$1interval (Ganzzahl, Standard: 60)
**Rückgabetyp**
void
**Nutzungshinweise**
Rufen Sie diese Funktion auf, um den Fortschritt der Gruppenerstellung oder der Zusammenführung zu überwachen.
# Umgang mit Konflikten bei der Aktiv-Aktiv-Replikation
Die „`pgactive`“-Erweiterung funktioniert pro Datenbank und nicht pro Cluster. Jede DB-Instance, die „`pgactive`“ verwendet, ist eine unabhängige Instance und kann Datenänderungen aus jeder Quelle akzeptieren. Wenn eine Änderung an eine DB-Instance gesendet wird, schreibt PostgreSQL sie lokal fest und repliziert die Änderung dann mithilfe von „`pgactive`“ asynchron auf andere DB-Instances. Wenn zwei PostgreSQL-DB-Instances denselben Datensatz fast zur gleichen Zeit aktualisieren, kann ein Konflikt auftreten.
Die Erweiterung „`pgactive`“ bietet Mechanismen zur Konflikterkennung und automatischen Lösung. Sie verfolgt den Zeitstempel, zu dem die Transaktion auf beiden DB-Instances festgeschrieben wurde, und wendet die Änderung automatisch mit dem neuesten Zeitstempel an. Die Erweiterung „`pgactive`“ protokolliert auch, wenn in der Tabelle `pgactive.pgactive_conflict_history` ein Konflikt auftritt.
`pgactive.pgactive_conflict_history` nimmt zu. Möglicherweise möchten Sie eine Löschrichtlinie definieren. Dies kann erreicht werden, indem Sie regelmäßig einige Datensätze löschen oder ein Partitionierungsschema für diese Beziehung definieren (und später die gewünschten Partitionen trennen, löschen oder kürzen). Um die Löschrichtlinie regelmäßig zu implementieren, besteht eine Möglichkeit darin, die `pg_cron`-Erweiterung zu verwenden. Im Folgenden finden Sie ein Beispiel für die Verlaufstabelle `pg_cron`, [Planen der Wartung mit der PostgreSQL-Erweiterung pg\$1cron](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation
Eine RDS-für-PostgreSQL-DB-Instance mit der Erweiterung „`pgactive`“ verwendet zwei verschiedene Sequenzmechanismen, um eindeutige Werte zu generieren.
**Globale Sequenzen**
Um eine globale Sequenz zu verwenden, erstellen Sie mit der Anweisung `CREATE SEQUENCE` eine lokale Sequenz. Verwenden Sie `pgactive.pgactive_snowflake_id_nextval(seqname)` statt `usingnextval(seqname)`, um den nächsten eindeutigen Wert der Sequenz abzurufen.
Mit dem folgenden Beispiel wird eine globale Sequenz erstellt:
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**Partitionierte Sequenzen**
In Split-Step- oder partitionierten Sequenzen wird auf jedem Knoten eine normale PostgreSQL-Sequenz verwendet. Jede Sequenz wird um den gleichen Betrag inkrementiert und beginnt mit unterschiedlichen Offsets. Bei Schritt 100 generiert Knoten 1 beispielsweise die Sequenz 101, 201, 301 usw. und Knoten 2 generiert die Sequenz 102, 202, 302 usw. Dieses Schema funktioniert auch dann gut, wenn die Knoten über einen längeren Zeitraum nicht kommunizieren können. Es ist jedoch erforderlich, dass der Designer bei der Einrichtung des Schemas eine maximale Anzahl von Knoten festlegt und jeden Knoten einzeln konfiguriert. Fehler können leicht zu überlappenden Sequenzen führen.
Es ist relativ einfach, diesen Ansatz mit `pgactive` zu konfigurieren, indem Sie die gewünschte Sequenz auf einem Knoten wie folgt erstellen:
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
Rufen Sie dann `setval` auf jedem Knoten auf, um einen anderen Offset-Startwert wie folgt anzugeben.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg\$1repack
Sie können die `pg_repack`-Erweiterung verwenden, um überflüssige Daten aus Tabellen und Indizes als Alternative zu `VACUUM FULL` zu entfernen. Die Erweiterung wird auf den RDS-for-PostgreSQL-Versionen 9.6.3 und höher unterstützt. Weitere Informationen zur `pg_repack` Erweiterung und zum vollständigen Table Repack finden Sie in der [GitHub Projektdokumentation](https://reorg.github.io/pg_repack/).
Im `VACUUM FULL` Gegensatz dazu erfordert die `pg_repack` Erweiterung in den folgenden Fällen nur für einen kurzen Zeitraum während der Neuerstellung der Tabelle eine exklusive Sperre (AccessExclusiveLock):
+ Erste Erstellung der Protokolltabelle – Eine Protokolltabelle wird erstellt, um Änderungen aufzuzeichnen, die beim ersten Kopieren der Daten vorgenommen wurden, wie im folgenden Beispiel gezeigt:
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ Letzte swap-and-drop Phase.
Für den Rest des Neuerstellungsvorgangs ist lediglich eine `ACCESS SHARE`-Sperre für die ursprüngliche Tabelle erforderlich, um Zeilen aus dieser Tabelle in die neue Tabelle zu kopieren. Dadurch können die INSERT-, UPDATE- und DELETE-Vorgänge wie gewohnt ausgeführt werden.
## Empfehlungen
Die folgenden Empfehlungen gelten, wenn Sie die Aufblähung aus den Tabellen und Indizes mithilfe der `pg_repack`-Erweiterung entfernen:
+ Führen Sie die Neuverpackung außerhalb der Geschäftszeiten oder während eines Wartungsfensters durch, um die Auswirkungen auf die Leistung anderer Datenbankaktivitäten so gering wie möglich zu halten.
+ Überwachen Sie blockierende Sitzungen während der Neuerstellungsaktivität genau und stellen Sie sicher, dass es in der Originaltabelle keine Aktivität gibt, die möglicherweise blockiert werden könnte`pg_repack`, insbesondere in der letzten swap-and-drop Phase, in der eine exklusive Sperre für die Originaltabelle erforderlich ist. Weitere Informationen finden Sie unter [Identifizieren, was eine Abfrage blockiert](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked).
Wenn Sie eine blockierende Sitzung sehen, können Sie sie nach reiflicher Überlegung mit dem folgenden Befehl beenden. Dies hilft bei der Fortsetzung von `pg_repack`, um die Neuerstellung abzuschließen:
```
SELECT pg_terminate_backend(pid);
```
+ Beim Anwenden der angesammelten Änderungen aus der `pg_repack's`-Protokolltabelle auf Systeme mit einer sehr hohen Transaktionsrate kann der apply-Prozess möglicherweise nicht mit der Änderungsrate mithalten. In solchen Fällen könnte `pg_repack` den apply-Prozess nicht abschließen. Weitere Informationen finden Sie unter [Überwachen der neuen Tabelle während der Neuverpackung](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring). Wenn Indizes stark aufgebläht sind, besteht eine alternative Lösung darin, nur den Index neu zu packen. Dies trägt auch dazu bei, dass die Indexbereinigungszyklen von VACUUM schneller abgeschlossen werden.
Sie können die Indexbereinigungsphase mit manuellem VACUUM ab PostgreSQL Version 12 überspringen, und sie wird während der Notfallselbstbereinigung ab PostgreSQL Version 14 automatisch übersprungen. Auf diese Weise kann VACUUM schneller abgeschlossen werden, ohne dass die Index-Aufblähung entfernt wird, und ist nur für Notfallsituationen vorgesehen, z. B. zur Vermeidung von Wraparound-VACUUM. Weitere Informationen finden Sie unter [Vermeiden von Aufblähungen in Indizes](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes) im Amazon Aurora-Benutzerhandbuch.
## Voraussetzungen
+ Die Tabelle muss die UNIQUE-Einschränkung PRIMARY KEY oder einen Wert ungleich Null haben.
+ Die Erweiterungsversion muss sowohl für den Client als auch für den Server identisch sein.
+ Stellen Sie sicher, dass die RDS-Instance mehr als `FreeStorageSpace` der Gesamtgröße der Tabelle ohne Aufblähung hat. Nehmen wir als Beispiel an, dass die Gesamtgröße der Tabelle einschließlich TOAST und Indizes 2 TB beträgt und die Gesamtaufblähung in der Tabelle 1 TB. Der erforderliche `FreeStorageSpace` muss größer sein als der von der folgenden Berechnung zurückgegebene Wert:
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
Mit der folgenden Abfrage können Sie die Gesamtgröße der Tabelle überprüfen und mit `pgstattuple` die Aufblähung ableiten. Weitere Informationen finden Sie unter [Diagnostizieren von Tabellen- und Index-Aufblähungen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html) im Amazon Aurora-Benutzerhandbuch.
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
Dieser Speicherplatz wird nach Abschluss der Aktivität zurückgewonnen.
+ Stellen Sie sicher, dass die RDS-Instance über genügend Rechen- und I/O-Kapazität verfügt, um den Neuverpackungsvorgang zu bewältigen. Sie könnten erwägen, die Instance-Klasse zu skalieren, um ein optimales Leistungsgleichgewicht zu erzielen.
**So richten Sie die `pg_repack`-Erweiterung ein**
1. Installieren Sie die `pg_repack`-Erweiterung auf Ihrer RDS-for-PostgreSQL-DB-Instance, indem Sie den folgenden Befehl ausführen.
```
CREATE EXTENSION pg_repack;
```
1. Führen Sie die folgenden Befehle aus, um Schreibzugriff auf temporäre Protokolltabellen zu gewähren, die von `pg_repack` erstellt wurden.
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. Stellen Sie mithilfe des `pg_repack`-Client-Dienstprogramms eine Verbindung mit der Datenbank her. Verwenden Sie ein Konto, das `rds_superuser`-Berechtigungen hat. Nehmen Sie beispielsweise an, dass die `rds_test`-Rolle `rds_superuser`-Berechtigungen hat. Die folgende Syntax führt `pg_repack` für vollständige Tabellen, einschließlich aller Tabellenindizes in der `postgres`- Datenbank durch.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**Anmerkung**
Stellen Sie die Verbindung mit der Option „-k“ her. Die Option -a wird nicht unterstützt.
Die Antwort des `pg_repack`-Clients stellt Informationen zu den Tabellen in der DB-Instance bereit, die neu verpackt werden.
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. Die folgende Syntax packt eine einzelne `orders`-Tabelle einschließlich der Indizes in der `postgres`-Datenbank neu.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
Mit der folgenden Syntax werden nur Indizes für die `orders`-Tabelle in der `postgres`-Datenbank erneut gepackt.
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## Überwachen der neuen Tabelle während der Neuverpackung
+ Die Größe der Datenbank wird bis zur swap-and-drop Phase des Neupackens um die Gesamtgröße der Tabelle abzüglich des Bloats erhöht. Sie können die Wachstumsrate der Datenbankgröße überwachen, die Geschwindigkeit der Neuverpackung berechnen und die Zeit, die bis zum Abschluss der ersten Datenübertragung benötigt wird, grob abschätzen.
Stellen Sie sich als Beispiel die Gesamtgröße der Tabelle mit 2 TB, die Größe der Datenbank mit 4 TB und die Gesamtgröße der Tabelle mit 1 TB vor. Der Wert für die Gesamtgröße der Datenbank, der durch die Berechnung am Ende des Neuverpackungsvorgangs zurückgegeben wurde, lautet wie folgt:
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
Sie können die Geschwindigkeit des Neuverpackungsvorgangs grob schätzen, indem Sie die Wachstumsrate in Byte zwischen zwei Zeitpunkten als Stichproben ermitteln. Wenn die Wachstumsrate 1 GB pro Minute beträgt, kann es etwa 1000 Minuten oder 16,6 Stunden dauern, bis die erste Tabellenerstellung abgeschlossen ist. Zusätzlich zur ersten Tabellenerstellung muss `pg_repack` auch die aufgelaufenen Änderungen anwenden. Die dafür benötigte Zeit hängt von der Geschwindigkeit ab, mit der die laufenden Änderungen und die aufgelaufenen Änderungen angewendet werden.
**Anmerkung**
Sie können die `pgstattuple`-Erweiterung verwenden, um die Aufblähung in der Tabelle zu berechnen. Weitere Informationen finden Sie unter [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html).
+ Die Anzahl der Zeilen in der Protokolltabelle `pg_repack's` gemäß dem Neuverpackungsschema entspricht der Menge der Änderungen, die nach dem ersten Laden noch auf die neue Tabelle angewendet werden müssen.
Sie können die Protokolltabelle `pg_repack's` in `pg_stat_all_tables` überprüfen, um die Änderungen zu überwachen, die auf die neue Tabelle angewendet wurden. `pg_stat_all_tables.n_live_tup` gibt die Anzahl der Datensätze an, deren Übernahme auf die neue Tabelle noch aussteht. Weitere Informationen finden Sie unter [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW).
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ Sie können die `pg_stat_statements`-Erweiterung verwenden, um herauszufinden, wie viel Zeit für jeden Schritt des Neuverpackungsvorgangs benötigt wird. Dies ist hilfreich bei der Vorbereitung auf die Anwendung desselben Neuverpackungsvorgangs in einer Produktionsumgebung. Sie können die `LIMIT`-Klausel anpassen, um die Ausgabe weiter zu erweitern.
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
Beim Umpacken handelt es sich ausschließlich um einen out-of-place Vorgang, sodass die Originaltabelle nicht beeinträchtigt wird und wir nicht mit unerwarteten Problemen rechnen, die eine Wiederherstellung der Originaltabelle erforderlich machen. Wenn das Neuverpacken unerwartet fehlschlägt, müssen Sie die Ursache des Fehlers untersuchen und ihn beheben.
Wenn das Problem behoben ist, löschen Sie die `pg_repack`-Erweiterung, erstellen Sie sie in der Datenbank, in der sich die Tabelle befindet, und wiederholen Sie den Schritt `pg_repack`. Darüber hinaus spielen die Verfügbarkeit von Rechenressourcen und der gleichzeitige Zugriff auf die Tabelle eine entscheidende Rolle für den rechtzeitigen Abschluss des Neuverpackungsvorgangs.
# Erweiterung aktualisieren und verwenden PLV8
PLV8 ist eine vertrauenswürdige Javascript-Spracherweiterung für PostgreSQL. Sie können sie für gespeicherte Prozeduren, Trigger und anderen prozeduralen Code verwenden, der von SQL aus aufrufbar ist. Diese Spracherweiterung wird von allen aktuellen Releases von PostgreSQL unterstützt.
Wenn Sie PostgreSQL verwenden [PLV8](https://plv8.github.io/)und auf eine neue PLV8 Version aktualisieren, nutzen Sie sofort die Vorteile der neuen Erweiterung. Führen Sie die folgenden Schritte aus, um Ihre Katalogmetadaten mit der neuen Version von zu synchronisieren. PLV8 Diese Schritte sind optional, aber wir empfehlen, sie durchzuführen, um Warnungen aufgrund fehlender Übereinstimmung von Metadaten zu vermeiden.
Durch den Upgrade-Vorgang werden alle Ihre vorhandenen PLV8 Funktionen gelöscht. Daher empfehlen wir, vor dem Upgrade einen Snapshot Ihrer DB-Instance von RDS für PostgreSQL zu erstellen. Weitere Informationen finden Sie unter [Erstellen eines DB-Snapshots für eine DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md).
**Wichtig**
Ab PostgreSQL-Version 18 werden in Amazon RDS für PostgreSQL die PostgreSQL-Erweiterungen `plcoffee` und `plls` eingestellt. Wir empfehlen Ihnen, die Verwendung von CoffeeScript und LiveScript in Ihren Anwendungen einzustellen, um sicherzustellen, dass Sie über einen Upgrade-Pfad für future Engine-Versions-Upgrades verfügen.
**Um Ihre Katalogmetadaten mit einer neuen Version von zu synchronisieren PLV8**
1. Überprüfen, ob Sie ein Update benötigen. Führen Sie dazu den folgenden Befehl aus, während Sie mit Ihrer Instance verbunden sind.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Wenn Ihre Ergebnisse Werte für eine installierte Version enthalten, die niedriger ist als die Standardversion, setzen Sie dieses Verfahren fort, um Ihre Erweiterungen zu aktualisieren. Die folgende Ergebnismenge beispielsweise deutet darauf hin, dass Sie ein Update vornehmen sollten.
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. Erstellen Sie einen Snapshot Ihrer RDS-for-PostgreSQL-DB-Instance, wenn Sie dies noch nicht getan haben. Sie können die folgenden Schritte fortsetzen, während der Snapshot erstellt wird.
1. Ermitteln Sie die Anzahl der PLV8 Funktionen in Ihrer DB-Instance, sodass Sie nach dem Upgrade überprüfen können, ob sie alle vorhanden sind. Die folgende SQL-Abfrage gibt beispielsweise die Anzahl der in plv8, plcoffee und plls geschriebenen Funktionen zurück.
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. Erstellen Sie mit pg\$1dump eine Dump-Datei, die nur das Schema enthält. Erstellen Sie beispielsweise eine Datei auf Ihrem Client-Computer im Verzeichnis `/tmp`.
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
In diesem Beispiel werden die folgenden Optionen verwendet:
+ `-Fc` – Benutzerdefiniertes Format
+ --schema-only – Erstellen Sie nur einen Dump von Befehlen, die zum Erstellen des Schemas erforderlich sind (in diesem Fall Funktionen)
+ `-U` – Der RDS-Hauptbenutzername
+ `database` – Der Datenbankname für unsere DB-Instance
Weitere Informationen zu pg\$1dump finden Sie unter [pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html ) in der PostgreSQL-Dokumentation.
1. Extrahieren Sie die in der Dump-Datei vorhandene DDL-Anweisung „CREATE FUNCTION”. Im folgenden Beispiel wird der `grep`-Befehl verwendet, um die DDL-Anweisung zu extrahieren, die die Funktionen erstellt, und sie in einer Datei zu speichern. Sie verwenden diese in nachfolgenden Schritten, um die Funktionen neu zu erstellen.
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
Weitere Informationen zu pg\$1restore finden Sie unter [pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html) in der PostgreSQL-Dokumentation.
1. Verwerfen Sie die Funktionen und Erweiterungen. Im folgenden Beispiel werden alle PLV8 basierten Objekte gelöscht. Die Option cascade stellt sicher, dass alle Abhängigkeiten verworfen werden.
```
DROP EXTENSION plv8 CASCADE;
```
Wenn Ihre PostgreSQL-Instance Objekte enthält, die auf plcoffee oder plls basieren, wiederholen Sie diesen Schritt für diese Erweiterungen.
1. Erstellen Sie die Erweiterungen. Das folgende Beispiel erstellt die plv8-, plcoffee- und plls-Erweiterungen.
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. Erstellen Sie die Funktionen unter Verwendung der Dump-Datei und der „Treiber“-Datei.
Das folgende Beispiel erstellt die zuvor extrahierten Funktionen neu.
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. Prüfen Sie mithilfe der folgenden Abfrage, ob all Ihre Funktionen neu erstellt wurden.
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
Die PLV8 Version 2 fügt Ihrer Ergebnismenge die folgende zusätzliche Zeile hinzu:
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# Verwenden PL/Rust , um PostgreSQL-Funktionen in der Sprache Rust zu schreiben
PL/Rust is a trusted Rust language extension for PostgreSQL. You can use it for stored procedures, functions, and other procedural code that's callable from SQL. The PL/RustDie Spracherweiterung ist in den folgenden Versionen verfügbar:
+ RDS für PostgreSQL 17.1 und höhere 17-Versionen
+ RDS für PostgreSQL 16.1 und höhere 16-Versionen
+ RDS für PostgreSQL 15.2-R2 und höhere 15-Versionen
+ RDS für PostgreSQL 14.9 und höhere 14-Versionen
+ RDS für PostgreSQL 13.12 und höhere 13-Versionen
Weitere Informationen finden Sie unter [PL/Rust on](https://github.com/tcdi/plrust#readme). GitHub
**Topics**
+ [
## Einrichten von PL/Rust
](#PL_Rust-setting-up)
+ [
## Erstellen von Funktionen mit PL/Rust
](#PL_Rust-create-function)
+ [
## Verwenden von Kisten mit PL/Rust
](#PL_Rust-crates)
+ [
## Einschränkungen von PL/Rust
](#PL_Rust-limitations)
## Einrichten von PL/Rust
Um die plrust-Erweiterung auf Ihrer DB-Instance zu installieren, fügen Sie plrust zum Parameter `shared_preload_libraries` in der DB-Parametergruppe hinzu, die mit Ihrer DB-Instance verknüpft ist. Wenn die plrust-Erweiterung installiert ist, können Sie Funktionen erstellen.
Damit der Parameter `shared_preload_libraries` geändert werden kann, muss Ihre DB-Instance mit einer benutzerdefinierten Parametergruppe verknüpft sein. Informationen zum Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können die Plrust-Erweiterung mit dem oder dem AWS-Managementkonsole installieren. AWS CLI
Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist.
### Konsole
**Installieren der plrust-Erweiterung im Parameter `shared_preload_libraries`**
Führen Sie die folgenden Schritte mit einem Konto aus, das Mitglied der `rds_superuser`-Gruppe (Rolle) ist.
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 im Navigationsbereich **Datenbanken** aus.
1. Wählen Sie den Namen Ihrer DB-Instance aus, um ihre Details anzuzeigen.
1. Öffnen Sie die Registerkarte **Konfiguration** für Ihre DB-Instance und suchen Sie den Link zur DB-Instance-Parametergruppe.
1. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer DB-Instance zugeordnet sind.
1. Geben Sie in das Suchfeld **Parameters** (Parameter) `shared_pre` ein, um den **`shared_preload_libraries`**-Parameter zu finden.
1. Wählen Sie **Edit parameters** (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.
1. Fügen Sie der Liste im Feld **Werte** „plrust“ hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.
1. Starten Sie die DB-Instance neu, damit die Änderung am Parameter `shared_preload_libraries` in Kraft tritt. Der erste Neustart kann zusätzliche Zeit in Anspruch nehmen.
1. Wenn die Instance verfügbar ist, überprüfen Sie, ob „plrust“ initialisiert wurde. Stellen Sie mit `psql` eine Verbindung mit der DB-Instance her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
```
Ihre Ausgabe sollte wie folgt aussehen:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**Installieren der plrust-Erweiterung im Parameter shared\$1preload\$1libraries**
Führen Sie die folgenden Schritte mit einem Konto aus, das Mitglied der `rds_superuser`-Gruppe (Rolle) ist.
1. Verwenden Sie den [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI Befehl, um plrust zum `shared_preload_libraries` Parameter hinzuzufügen.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Verwenden Sie den [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI Befehl, um die DB-Instance neu zu starten und die Plrust-Bibliothek zu initialisieren. Der erste Neustart kann zusätzliche Zeit in Anspruch nehmen.
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Wenn die Instance verfügbar ist, können Sie überprüfen, ob „plrust“ initialisiert wurde. Stellen Sie mit `psql` eine Verbindung mit der DB-Instance her und führen Sie den folgenden Befehl aus.
```
SHOW shared_preload_libraries;
```
Ihre Ausgabe sollte wie folgt aussehen:
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## Erstellen von Funktionen mit PL/Rust
PL/Rust kompiliert die Funktion als dynamische Bibliothek, lädt sie und führt sie aus.
Die folgende Rust-Funktion filtert Vielfache aus einem Array.
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## Verwenden von Kisten mit PL/Rust
In den Versionen 16.3-R2 und höher von RDS für PostgreSQL werden in den Versionen 15.7-R2 und höher 15, 14.12-R2 und höher (14 Versionen) und 13.15-R2 und höher (13) zusätzliche Crates unterstützt: PL/Rust
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
In den Versionen 15.5-R2 und höher von RDS für PostgreSQL, 14.10-R2 und höher, 14 und 13.13-R2 und höher, 13, werden zwei zusätzliche Crates unterstützt: PL/Rust
+ `croaring-rs`
+ `num-bigint`
Beginnend mit den Versionen 15.4, 14.9 und 13.12 von Amazon RDS for PostgreSQL werden die folgenden Kisten unterstützt: PL/Rust
+ `aes`
+ `ctr`
+ `rand`
Für diese Kisten werden nur die Standardfunktionen unterstützt. Neue Versionen von RDS für PostgreSQL enthalten möglicherweise aktualisierte Versionen von Kisten und ältere Versionen von Kisten werden möglicherweise nicht mehr unterstützt.
Folgen Sie den bewährten Methoden für die Durchführung eines Hauptversions-Upgrades, um zu testen, ob Ihre PL/Rust Funktionen mit der neuen Hauptversion kompatibel sind. Weitere Informationen finden Sie im Blog [Bewährte Methoden für das Upgrade von Amazon RDS auf Haupt- und Nebenversionen von PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/) und [Upgrade einer PostgreSQL-DB-Engine für Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html) im Amazon-RDS-Benutzerhandbuch.
Beispiele für die Verwendung von Abhängigkeiten bei der Erstellung einer PL/Rust Funktion finden [Sie unter Abhängigkeiten verwenden](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies).
## Einschränkungen von PL/Rust
Standardmäßig können Datenbankbenutzer den folgenden Befehl nicht verwendenPL/Rust. To provide access to PL/Rust, sich als Benutzer mit der Berechtigung rds\$1superuser verbinden und ihn ausführen:
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# Verwalten von Geodaten mit der PostGIS-Erweiterung
PostGIS ist eine Erweiterung von PostgreSQL zur Speicherung und Verwaltung von Geodaten. Weitere Informationen zu PostGIS finden Sie unter [PostGIS.net](https://postgis.net/).
Ab Version 10.5 unterstützt PostgreSQL die libprotobuf-1.3.0-Bibliothek, die von PostGIS für die Arbeit mit Vektorkacheldaten der Kartenbox verwendet wird.
Für das Einrichten der PostGIS-Erweiterung sind `rds_superuser`-Berechtigungen erforderlich. Wir empfehlen Ihnen, einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung und Ihrer räumlichen Daten zu erstellen. Die PostGIS-Erweiterung und ihre zugehörigen Komponenten fügen PostgreSQL Tausende von Funktionen hinzu. Erstellen Sie die PostGIS-Erweiterung ggf. in einem eigenen Schema, wenn dies für Ihren Anwendungsfall sinnvoll ist. Das folgende Beispiel zeigt, wie die Erweiterung in einer eigenen Datenbank installiert wird. Dies ist jedoch nicht erforderlich.
**Topics**
+ [
## Schritt 1: Erstellen Sie einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung.
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [
## Schritt 2: Laden der PostGIS-Erweiterungen.
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [
## Schritt 3: Übertragen der Eigentümerschaft der Erweiterungsschemas
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [
## Schritt 4: Übertragen der Eigentümerschaft der PostGIS-Tabellen
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [
## Schritt 5: Testen der Erweiterungen
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [
## Schritt 6: Upgrade der PostGIS-Erweiterung
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [PostGIS-Erweiterungsversionen](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Upgrade von PostGIS 2 auf PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Schritt 1: Erstellen Sie einen Benutzer (Rolle) zum Verwalten der PostGIS-Erweiterung.
Zuerst stellen Sie eine Verbindung mit Ihrer DB-Instance von RDS für PostgreSQL als Benutzer her, der über `rds_superuser`-Berechtigungen verfügt. Wenn Sie beim Einrichten Ihrer Instance den Standardnamen beibehalten haben, stellen Sie eine Verbindung als `postgres` her.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Erstellen Sie eine separate Rolle (Benutzer), um die PostGIS-Erweiterung zu verwalten.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Gewähren Sie dieser Rolle `rds_superuser`-Berechtigungen, damit die Rolle die Erweiterung installieren kann.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Erstellen Sie eine Datenbank, die Sie für Ihre PostGIS-Artefakte verwenden können. Dieser Schritt ist optional. Oder Sie können in Ihrer Benutzerdatenbank ein Schema für die PostGIS-Erweiterungen erstellen, aber das ist auch nicht erforderlich.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Gewähren Sie `gis_admin` alle Berechtigungen für die `lab_gis`-Datenbank.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Beenden Sie die Sitzung und stellen Sie wieder eine Verbindung mit Ihrer RDS-for-PostgreSQL-DB-Instance als `gis_admin` her.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Fahren Sie mit der Einrichtung der Erweiterung fort, wie in den nächsten Schritten beschrieben.
## Schritt 2: Laden der PostGIS-Erweiterungen.
Die PostGIS-Erweiterung enthält mehrere verwandte Erweiterungen, die zusammenarbeiten, um Geodatenfunktionen bereitzustellen. Je nach Anwendungsfall benötigen Sie möglicherweise nicht alle Erweiterungen, die Sie in diesem Schritt erstellt haben.
Verwenden Sie `CREATE EXTENSION`-Anweisungen, um die PostGIS-Erweiterungen zu laden.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
Sie können die Ergebnisse überprüfen, indem Sie die in dem folgenden Beispiel gezeigte SQL-Abfrage ausführen, in der die Erweiterungen und ihre Besitzer aufgeführt sind.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Schritt 3: Übertragen der Eigentümerschaft der Erweiterungsschemas
Verwenden Sie die ALTER SCHEMA-Anweisungen, um die Eigentümerschaft der Schemata auf die Rolle `gis_admin` zu übertragen.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
Sie können die Eigentümeränderung bestätigen, indem Sie die folgende SQL-Abfrage ausführen. Oder Sie können den Metabefehl `\dn` über die psql-Befehlszeile verwenden.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Schritt 4: Übertragen der Eigentümerschaft der PostGIS-Tabellen
**Anmerkung**
Ändern Sie nicht die Eigentümerschaft der PostGIS-Funktionen. Ein ordnungsgemäßer Betrieb sowie zukünftige Upgrades von PostGIS setzen voraus, dass sich an der Eigentümerschaft dieser Funktionen nichts ändert. Weitere Informationen zu PostGIS-Berechtigungen finden Sie unter [PostgreSQL-Sicherheit](https://postgis.net/workshops/postgis-intro/security.html).
Verwenden Sie die folgende Funktion, um die Eigentümerschaft der PostGIS-Tabellen auf die Rolle `gis_admin` zu übertragen. Führen Sie die folgende Anweisung aus der psql-Aufforderung aus, um die Funktion zu erstellen.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Führen Sie als Nächstes die folgende Abfrage aus, um die `exec`-Funktion auszuführen, die wiederum die Anweisungen ausführt und die Berechtigungen ändert.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Schritt 5: Testen der Erweiterungen
Um zu vermeiden, dass der Schemaname angegeben werden muss, fügen Sie das `tiger`-Schema Ihrem Suchpfad unter Verwendung des folgenden Befehls hinzu.
```
SET search_path=public,tiger;
SET
```
Testen Sie das `tiger`-Schema unter Verwendung der folgenden SELECT-Anweisung.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
Weitere Informationen zu dieser Erweiterung finden Sie unter [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) in der PostGIS-Dokumentation.
Testen Sie den Zugriff auf das `topology`-Schema, indem Sie folgende `SELECT`-Anweisung verwenden. Das ruft die `createtopology`-Funktion zum Registrieren eines neuen Topologieobjekts (my\$1new\$1topo) mit der angegebenen Raumbezugskennung (26986) und der Standardtoleranz (0,5) auf. Weitere Informationen finden Sie [CreateTopology](https://postgis.net/docs/CreateTopology.html)in der PostGIS-Dokumentation.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Schritt 6: Upgrade der PostGIS-Erweiterung
Jede neue Version von PostgreSQL unterstützt eine oder mehrere Versionen der PostGIS-Erweiterung, die mit dieser Version kompatibel sind. Bei einem Upgrade der PostgreSQL-Engine auf eine neue Version wird die PostGIS-Erweiterung nicht automatisch aktualisiert. Vor dem Upgrade der PostgreSQL-Engine aktualisieren Sie PostGIS in der Regel auf die neueste verfügbare Version für die aktuelle PostgreSQL-Version. Details hierzu finden Sie unter [PostGIS-Erweiterungsversionen](#CHAP_PostgreSQL.Extensions.PostGIS).
Nach dem Upgrade der PostgreSQL-Engine aktualisieren Sie die PostGIS-Erweiterung erneut auf die Version, die für die neu aktualisierte PostgreSQL-Engine-Version unterstützt wird. Weitere Informationen zum Upgrade der PostgreSQL-Engine finden Sie unter [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)..
Sie können jederzeit prüfen, ob eine neue Version der PostGIS-Erweiterung auf der DB-Instance von RDS für PostgreSQL verfügbar ist. Führen Sie dazu den folgenden Befehl aus. Diese Funktion ist mit PostGIS 2.5.0 und höheren Versionen verfügbar.
```
SELECT postGIS_extensions_upgrade();
```
Wenn Ihre Anwendung die neueste PostGIS-Version nicht unterstützt, können Sie weiterhin eine ältere Version von PostGIS installieren, die in Ihrer Hauptversion wie folgt verfügbar ist.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
Wenn Sie von einer älteren Version auf eine bestimmte PostGIS-Version aktualisieren möchten, können Sie auch den folgenden Befehl verwenden.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Abhängig von der Version, von der Sie ein Upgrade durchführen, müssen Sie diese Funktion möglicherweise noch einmal verwenden. Das Ergebnis des ersten Durchlaufs der Funktion bestimmt, ob eine zusätzliche Upgrade-Funktion benötigt wird. Dies ist beispielsweise bei einem Upgrade von PostGIS 2 auf PostGIS 3 der Fall. Weitere Informationen finden Sie unter [Upgrade von PostGIS 2 auf PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
Wenn Sie diese Erweiterung aktualisiert haben, um ein Upgrade der Hauptversion der PostgreSQL-Engine vorzubereiten, können Sie mit anderen vorbereitenden Aufgaben fortfahren. Weitere Informationen finden Sie unter [Durchführen eines Hauptversion-Upgrades von RDS für PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
## PostGIS-Erweiterungsversionen
Wir empfehlen Ihnen, die Versionen aller Erweiterungen wie PostGIS zu installieren, wie sie unter [Extension versions for Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) (Versionen aller Erweiterungen für Amazon RDS für PostgreSQL) in *Versionshinweise für Amazon RDS für PostgreSQL.*. Sie können mithilfe des folgenden Befehls auflisten, welche Versionen in Ihrer Version verfügbar sind.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
Versionsinformationen finden Sie in den folgenden Abschnitten in den *Versionshinweisen zu Amazon RDS für PostgreSQL*:
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 11](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [In Amazon RDS unterstützte Erweiterungen von PostgreSQL Version 9.6.x](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## Upgrade von PostGIS 2 auf PostGIS 3
Ab Version 3.0 ist die PostGIS-Raster-Funktionalität jetzt eine separate Erweiterung, `postgis_raster`. Diese Erweiterung hat einen eigenen Installations- und Upgrade-Pfad. Dadurch werden Dutzende von Funktionen, Datentypen und anderen Artefakten, die für die Rasterbildverarbeitung erforderlich sind, aus der `postgis`-Kernerweiterung entfernt. Das heißt, wenn Ihr Anwendungsfall keine Raster-Verarbeitung erfordert, müssen Sie die `postgis_raster`-Erweiterung nicht installieren.
Im folgenden Upgrade-Beispiel extrahiert der erste Upgrade-Befehl die Raster-Funktionalität in die `postgis_raster`-Erweiterung. Ein zweiter Upgrade-Befehl ist dann erforderlich, um ein Upgrade von `postgis_raster` auf die neue Version durchzuführen.
**So führen Sie ein Upgrade von PostGIS 2 auf PostGIS 3 durch**
1. Identifizieren Sie die Standardversion von PostGIS, die für die PostgreSQL-Version auf Ihrem verfügbar ist. DB-Instance von RDS für PostgreSQL. Führen Sie dazu die folgende Abfrage durch.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identifizieren Sie die Versionen von PostGIS, die in jeder Datenbank auf Ihrer DB-Instance von RDS für PostgreSQL installiert sind. Anders gesagt: Fragen Sie jede Benutzerdatenbank wie folgt ab.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
Diese Nichtübereinstimmung zwischen der Standardversion (PostGIS 3.1.4) und der installierten Version (PostGIS 2.3.7) bedeutet, dass Sie die PostGIS-Erweiterung aktualisieren müssen.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Führen Sie die folgende Abfrage aus, um sicherzustellen, dass sich die Raster-Funktionalität jetzt in einem eigenen Paket befindet.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
Die Ausgabe zeigt, dass es immer noch einen Unterschied zwischen den Versionen gibt. Die PostGIS-Funktionen sind Version 3 (postgis-3), während die Raster-Funktionen (rtpostgis) Version 2 (rtpostgis-2.3) sind. Um das Upgrade abzuschließen, führen Sie den Upgrade-Befehl erneut wie folgt aus.
```
postgres=> SELECT postgis_extensions_upgrade();
```
Die Warnmeldungen können Sie ohne Bedenken ignorieren. Führen Sie die folgende Abfrage erneut aus, um zu überprüfen, ob das Upgrade abgeschlossen ist. Das Upgrade ist abgeschlossen, wenn PostGIS und alle zugehörigen Erweiterungen nicht als aktualisierungsbedürftig gekennzeichnet sind.
```
SELECT postgis_full_version();
```
1. Verwenden Sie die folgende Abfrage, um den abgeschlossenen Upgrade-Vorgang und die separat gepackten Erweiterungen anzuzeigen und zu überprüfen, ob ihre Versionen übereinstimmen.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
Die Ausgabe zeigt, dass die PostGIS-2-Erweiterung auf PostGIS 3 aktualisiert wurde und beide `postgis` und die jetzt getrennte `postgis_raster`-Erweiterungen Version 3.1.5 sind.
Wenn Sie nach Abschluss dieses Upgrades die Raster-Funktionalität nicht verwenden möchten, können Sie die Erweiterung wie folgt löschen.
```
DROP EXTENSION postgis_raster;
```