Verwenden von PostgreSQL-Erweiterungen mit Amazon RDS for PostgreSQL - Amazon Relational Database Service

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 for 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. 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_partman.

Anmerkung

Ab RDS für PostgreSQL 14.5 unterstützt RDS für PostgreSQL Trusted Language Extensions für PostgreSQL. Diese Funktion ist als Erweiterung pg_tle implementiert, die Sie Ihrer DB-Instance von RDS für PostgreSQL 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 finden Sie unter Arbeiten mit Trusted Language Extensions für PostgreSQL.

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_cron beschrieben. Als weiteres Beispiel können Sie Abfrageausführungspläne protokollieren, indem Sie das auto_explain-Modul laden. Weitere Informationen finden Sie unter Protokollieren von Ausführungsplänen von Abfragen im AWS -Wissenscenter.

Abhängig von Ihrer Version von RDS for 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.

Sie können auch genau angeben, welche Erweiterungen auf Ihrer DB-Instance von RDS for 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.

Weitere Informationen über die rds_superuser-Rolle finden Sie unter Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen.

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 orafce finden Sie unter orafce auf 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.

  2. Aktivieren Sie die orafce-Erweiterung mit der Anweisung CREATE EXTENSION.

    CREATE EXTENSION orafce;
  3. Übertragen Sie den Besitz der oracle-Schemas mit der Anweisung ALTER SCHEMA auf die rds_superuser-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 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. Amazon RDS for PostgreSQL unterstützt die -pgactiveErweiterung auf den folgenden 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.

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 die AWS Management Console oder die verwenden AWS CLI , um die erforderlichen DB-Instances von RDS für PostgreSQL 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 Arbeiten mit Parametergruppen.

So initialisieren Sie die „pgactive“-Erweiterungsfunktion
  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Ihre DB-Instance von RDS für PostgreSQL aus.

  3. Ö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.

  4. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer RDS-für-PostgreSQL-DB-Instance zugeordnet sind.

  5. Suchen Sie den Parameter „rds.enable_pgactive“ und setzen Sie ihn auf „1“, um die „pgactive“-Funktion zu initialisieren.

  6. Wählen Sie Änderungen speichern aus.

  7. Wählen Sie im Navigationsbereich der Amazon-RDS-Konsole die Option Databases (Datenbanken) aus.

  8. Wählen Sie Ihre RDS-für-PostgreSQL-DB-Instance aus und wählen Sie dann im Menü Aktionen die Option Neustart aus.

  9. Bestätigen Sie den Neustart der DB-Instance, damit die Änderungen in Kraft treten.

  10. 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-für-PostgreSQL-DB-Instance über eine Standarddatenbank namens postgres verfügt.

    psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master username --password --dbname=postgres
  11. 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
  12. Erstellen Sie die Erweiterung wie folgt.

    postgres=> CREATE EXTENSION pgactive;
So initialisieren Sie die „pgactive“-Erweiterungsfunktion

Um die pgactive mit der zu initialisieren AWS CLI, rufen Sie die -modify-db-parameter-groupOperation auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.

  1. Verwenden Sie den folgenden AWS CLI Befehl, um rds.enable_pgactive auf festzulegen, 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
  2. Verwenden Sie den folgenden AWS CLI Befehl, um die DB-Instance von RDS für PostgreSQL neu zu starten, damit die pgactive Bibliothek initialisiert wird.

    aws rds reboot-db-instance \ --db-instance-identifier your-instance \ --region aws-region
  3. 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 --dbname=postgres
  4. Erstellen Sie die Erweiterung wie folgt.

    postgres=> CREATE EXTENSION pgactive;

Einrichten der Aktiv-Aktiv-Replikation für die DB-Instances von RDS für PostgreSQL

Das folgende Verfahren zeigt, wie Sie die Aktiv-Aktiv-Replikation zwischen zwei DB-Instances von RDS für PostgreSQL starten, die PostgreSQL Version 15.4 oder höher in der gleichen Region ausführen. 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.

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.

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=master username --password --dbname=postgres
  2. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der RDS-für-PostgreSQL-Instance:

    postgres=> CREATE DATABASE app;
  3. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:

    \c app
  4. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Parameter „shared_preload_libraries“ „pgactive“ enthält:

    app=>SELECT setting ~ 'pgactive' FROM pg_catalog.pg_settings WHERE name = 'shared_preload_libraries';
    ?column? ---------- t
  5. 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);
    2. 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');
    3. 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
  6. Erstellen Sie eine „pgactive“-Erweiterung für die bestehende Datenbank.

    app=> CREATE EXTENSION pgactive;
  7. Erstellen und initialisieren Sie die Gruppe „pgactive“ mit den folgenden Befehlen:

    app=> SELECT pgactive.pgactive_create_group( node_name := 'node1-app', node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=master username 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.

  8. 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.

  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=master username --password --dbname=postgres
  2. Erstellen Sie mit dem folgenden Befehl eine Datenbank auf der zweiten RDS-für-PostgreSQL-Instance:

    postgres=> CREATE DATABASE app;
  3. Wechseln Sie mit dem folgenden Befehl die Verbindung zur neuen Datenbank:

    \c app
  4. Erstellen Sie die „pgactive“-Erweiterung für die bestehende Datenbank.

    app=> CREATE EXTENSION pgactive;
  5. Fügen Sie den die zweite DB-Instance von RDS für PostgreSQL auf folgende Weise zu der „pgactive“-Gruppe hinzu.

    app=> SELECT pgactive.pgactive_join_group( node_name := 'node2-app', node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=master username 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.

  6. 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.

  7. 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
  8. Führen Sie den folgenden Befehl aus, um neue Werte einzufügen:

    app=> INSERT INTO inventory.products (id, product_name) VALUES ('lotion');
  9. 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']);
  2. 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);
  3. Löschen Sie die Erweiterung mit dem folgenden Befehl:

    app=> DROP EXTENSION pgactive;

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.

Die pgactive.pgactive_conflict_history wird weiter wachsen. Möglicherweise möchten Sie eine Bereinigungsrichtlinie definieren. Dazu können Sie einige Datensätze regelmäßig löschen oder ein Partitionierungsschema für diese Relation definieren (und später Partitionen von Interesse trennen, löschen, kürzen). Um die Bereinigungsrichtlinie regelmäßig zu implementieren, besteht eine Option darin, die -pg_cronErweiterung zu verwenden. Sehen Sie sich die folgenden Informationen eines Beispiels für die pg_cron Verlaufstabelle Planen der Wartung mit der PostgreSQL-Erweiterung pg_cron an.

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:

postgres=> CREATE TABLE gstest ( id bigint primary key, parrot text );
postgres=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
postgres=> 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);
postgres=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
postgres=> 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.

postgres=> -- On node 1 SELECT setval('some_seq', 1); -- On node 2 SELECT setval('some_seq', 2);

Parameterreferenz für die pgactive-Erweiterung

Sie können die folgende Abfrage verwenden, um alle mit der „pgactive“-Erweiterung verknüpften Parameter anzuzeigen.

postgres=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';

Messung der Replikationsverzögerung unter pgaktiven 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 das vollständige Bild zu erhalten.

postgres=# SELECT *, (last_applied_xact_at - last_applied_xact_committs) AS lag FROM pgactive.pgactive_node_slots; -{ RECORD 1 ]----------------+----------------------------------------------------------------- node_name | node2-app slot_name | pgactive_5_7332551165694385385_0_5__ slot_restart_lsn | 0/1A898A8 slot_confirmed_lsn | 0/1A898E0 walsender_active | t walsender_pid | 69022 sent_lsn | 0/1A898E0 write_lsn | 0/1A898E0 flush_lsn | 0/1A898E0 replay_lsn | 0/1A898E0 last_sent_xact_id | 746 last_sent_xact_committs | 2024-02-06 18:04:22.430376+00 last_sent_xact_at | 2024-02-06 18:04:22.431359+00 last_applied_xact_id | 746 last_applied_xact_committs | 2024-02-06 18:04:22.430376+00 last_applied_xact_at | 2024-02-06 18:04:52.452465+00 lag | 00:00:30.022089

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.

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

Reduzieren von überflüssigen Daten in Tabellen und Indizes mit der Erweiterung pg_repack

Sie können die pg_repack Erweiterung verwenden, um Überlastungen aus Tabellen und Indizes als Alternative zu zu entfernenVACUUM FULL. 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 Tabellenumpacken finden Sie in der GitHub Projektdokumentation .

Im Gegensatz zu erfordert VACUUM FULLdie pg_repack Erweiterung in den folgenden Fällen AccessExclusiveLocknur für kurze Zeit während der Neuerstellung der Tabelle eine exklusive Sperre ():

  • Erste Erstellung einer Protokolltabelle – Es wird eine Protokolltabelle erstellt, um Änderungen aufzuzeichnen, die beim ersten Kopieren der Daten auftreten, 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 |
  • Endgültige swap-and-drop Phase.

Für den Rest des Neuerstellungsvorgangs benötigt es nur eine ACCESS SHARE Sperre für die ursprüngliche Tabelle, um Zeilen aus der Tabelle in die neue Tabelle zu kopieren. Auf diese Weise können die Operationen INSERT, UPDATE und DELETE wie gewohnt fortgesetzt werden.

Empfehlungen

Die folgenden Empfehlungen gelten, wenn Sie mit der pg_repack Erweiterung überflüssige Daten aus den Tabellen und Indizes entfernen:

  • Führen Sie das Umpacken außerhalb der Geschäftszeiten oder über ein Wartungsfenster durch, um die Auswirkungen anderer Datenbankaktivitäten auf die Leistung zu minimieren.

  • Überwachen Sie Blockiersitzungen während der Neuerstellungsaktivität genau und stellen Sie sicher, dass die ursprüngliche Tabelle keine Aktivität enthält, die möglicherweise blockieren könntepg_repack, insbesondere in der letzten swap-and-drop Phase, wenn sie eine exklusive Sperre für die ursprüngliche Tabelle benötigt. Weitere Informationen finden Sie unter Identifizieren, was eine Abfrage blockiert.

    Wenn Sie eine blockierende Sitzung sehen, können Sie sie mit dem folgenden Befehl beenden, nachdem Sie sie sorgfältig geprüft haben. Dies hilft bei der Fortsetzung von pg_repack, um die Neuerstellung abzuschließen:

    SELECT pg_terminate_backend(pid);
  • Während die angesammelten Änderungen aus der pg_repack's Protokolltabelle auf Systeme mit einer sehr hohen Transaktionsrate angewendet werden, kann der Anwendungsprozess möglicherweise nicht mit der Änderungsrate Schritt halten. In solchen Fällen pg_repack könnte den Anwendungsprozess nicht abschließen. Weitere Informationen finden Sie unter Überwachen der neuen Tabelle während des Umpackens. Wenn Indizes stark aufgebläht sind, besteht eine alternative Lösung darin, nur einen Index neu zu packen. Dies hilft auch, die Indexbereinigungszyklen von VACUUM schneller abzuschließen.

    Sie können die Indexbereinigungsphase mit manuellem VACUUM aus PostgreSQL Version 12 überspringen und sie wird während der Notfall-Selbstbereinigung aus PostgreSQL Version 14 automatisch übersprungen. Dies hilft VACUUM, schneller abzuschließen, ohne die Indexüberlastung zu entfernen, und ist nur für Notfallsituationen wie die Verhinderung von Wraparound-VACUUM vorgesehen. Weitere Informationen finden Sie unter Vermeiden von Überlastungen in Indizes im Amazon-Aurora-Benutzerhandbuch.

Voraussetzungen

  • Die Tabelle muss die Einschränkung PRIMARY KEY oder non-null UNIQUE 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 FreeStorageSpace als die Gesamtgröße der Tabelle hat, ohne dass die Überlastung auftritt. Betrachten Sie als Beispiel die Gesamtgröße der Tabelle einschließlich TOAST und Indizes als 2TB und die gesamte Überlastung in der Tabelle als 1TB. Der erforderliche FreeStorageSpace muss größer als der von der folgenden Berechnung zurückgegebene Wert sein:

    2TB (Table size) - 1TB (Table bloat) = 1TB

    Sie können die folgende Abfrage verwenden, um die Gesamtgröße der Tabelle zu überprüfen und pgstattuple mit eine Überlastung abzuleiten. Weitere Informationen finden Sie unter Diagnostizieren einer Überlastung von Tabellen und Indizes 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 E/A-Kapazität verfügt, um den Umpackvorgang zu bewältigen. Sie könnten erwägen, die Instance-Klasse hochzuskalieren, um ein optimales Leistungsgleichgewicht zu erzielen.

So verwenden Sie die pg_repack Erweiterung
  1. Installieren Sie die Erweiterung pg_repack auf Ihrer RDS-for-PostgreSQL-DB-Instance, indem Sie den folgenden Befehl ausführen.

    CREATE EXTENSION pg_repack;
  2. Führen Sie die folgenden Befehle aus, um Schreibzugriff auf temporäre Protokolltabellen zu gewähren, die von erstellt wurdenpg_repack.

    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;
  3. 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 wird pg_repack für vollständige Tabellen ausgeführt, einschließlich aller Tabellenindizes in der postgres Datenbank.

    pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
    Anmerkung

    Sie müssen eine Verbindung mit der Option -k herstellen. Die Option -a wird nicht unterstützt.

    Die Antwort des pg_repack Clients enthält Informationen zu den Tabellen auf der DB-Instance, die neu verpackt werden.

    INFO: repacking table "pgbench_tellers" INFO: repacking table "pgbench_accounts" INFO: repacking table "pgbench_branches"
  4. Mit der folgenden Syntax wird eine einzelne Tabelle orders mit Indizes in der postgres Datenbank neu verpackt.

    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 neu verpackt.

    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 des Umpackens

  • Die Größe der Datenbank wird um die Gesamtgröße der Tabelle abzüglich Überlastung bis zur swap-and-drop Phase des Umpackens erhöht. Sie können die Wachstumsrate der Datenbankgröße überwachen, die Geschwindigkeit des Repacks berechnen und ungefähr die Zeit schätzen, die für den Abschluss der ersten Datenübertragung benötigt wird.

    Betrachten Sie beispielsweise die Gesamtgröße der Tabelle als 2TB, die Größe der Datenbank als 4TB und die gesamte Überlastung in der Tabelle als 1TB. Der Wert für die Gesamtgröße der Datenbank, der von der Berechnung am Ende des Umpackvorgangs zurückgegeben wird, ist der folgende:

    2TB (Table size) + 4 TB (Database size) - 1TB (Table bloat) = 5TB

    Sie können die Geschwindigkeit des Repack-Vorgangs ungefähr schätzen, indem Sie die Wachstumsrate zwischen zwei Zeitpunkten abfragen. Wenn die Wachstumsrate 1GB pro Minute beträgt, kann es etwa 1000 Minuten oder 16,6 Stunden dauern, bis der erste Tabellenerstellungsvorgang abgeschlossen ist. Zusätzlich zum ersten Tabellenaufbau muss pg_repack auch aufgelaufene Änderungen anwenden. Die benötigte Zeit hängt von der Rate der Anwendung laufender Änderungen plus angesammelter Änderungen ab.

    Anmerkung

    Sie können die pgstattuple Erweiterung verwenden, um die Überlastung in der Tabelle zu berechnen. Weitere Informationen finden Sie unter pgstattuple.

  • Die Anzahl der Zeilen in der pg_repack's Protokolltabelle unter dem Repack-Schema stellt das Volumen der Änderungen dar, die nach dem ersten Laden auf die neue Tabelle angewendet werden sollen.

    Sie können die pg_repack's Protokolltabelle in überprüfenpg_stat_all_tables, um die Änderungen zu überwachen, die auf die neue Tabelle angewendet werden. pg_stat_all_tables.n_live_tup gibt die Anzahl der Datensätze an, die noch auf die neue Tabelle angewendet werden sollen. Weitere Informationen finden Sie unter pg_stat_all_tables.

    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 die Zeit zu ermitteln, die für jeden Schritt des Umpackvorgangs benötigt wird. Dies ist hilfreich bei der Vorbereitung der Anwendung desselben Repack-Vorgangs in einer Produktionsumgebung. Sie können die -LIMITKlausel 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)

Das Umpacken ist ein vollständiger out-of-place Vorgang, sodass die ursprüngliche Tabelle nicht beeinträchtigt wird und wir keine unerwarteten Herausforderungen erwarten, die eine Wiederherstellung der ursprünglichen Tabelle erfordern. Wenn das Umpacken unerwartet fehlschlägt, müssen Sie die Ursache des Fehlers untersuchen und beheben.

Nachdem das Problem behoben wurde, löschen Sie die pg_repack Erweiterung in der Datenbank, in der die Tabelle vorhanden ist, und erstellen Sie sie neu. Versuchen Sie dann den pg_repack Schritt erneut. Darüber hinaus spielen die Verfügbarkeit von Rechenressourcen und die gleichzeitige Zugänglichkeit der Tabelle eine entscheidende Rolle für den rechtzeitigen Abschluss des Umpackvorgangs.

Upgrade und Verwendung der PLV8-Erweiterung

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 PLV8 verwenden und PostgreSQL auf eine neue PLV8-Version aktualisieren, steht Ihnen die neue Erweiterung sofort zur Verfügung. Führen Sie die folgenden Schritte aus, um Ihre Katalogmetadaten mit der neuen Version von PLV8 zu synchronisieren. Diese Schritte sind optional, aber wir empfehlen, sie durchzuführen, um Warnungen aufgrund fehlender Übereinstimmung von Metadaten zu vermeiden.

Der Upgrade-Prozess verwirft alle Ihre vorhandenen PLV8-Funktionen. Daher empfehlen wir, vor dem Upgrade einen Snapshot Ihrer DB-Instance von RDS for PostgreSQL zu erstellen. Weitere Informationen finden Sie unter Erstellen eines DB-Snapshots für eine Single-AZ-DB-Instance.

Ihre Katalogmetadaten mit einer neuen Version von PLV8 synchronisieren
  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)
  2. 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.

  3. Rufen Sie die Anzahl der PLV8-Funktionen in Ihrer DB-Instance ab, damit 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');
  4. Erstellen Sie mit pg_dump 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_dump finden Sie unter pg_dump in der PostgreSQL-Dokumentation.

  5. 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_restore finden Sie unter pg_restore in der PostgreSQL-Dokumentation.

  6. Verwerfen Sie die Funktionen und Erweiterungen. Im folgenden Beispiel werden alle auf PLV8 basierenden Objekte verworfen. 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.

  7. Erstellen Sie die Erweiterungen. Das folgende Beispiel erstellt die plv8-, plcoffee- und plls-Erweiterungen.

    CREATE EXTENSION plv8; CREATE EXTENSION plcoffee; CREATE EXTENSION plls;
  8. 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
  9. 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');

    PLV8-Version 2 fügt Ihrer Ergebnismenge die folgende zusätzliche Zeile hinzu:

    proname | nspname | lanname ---------------+------------+---------- plv8_version | pg_catalog | plv8

Verwendung von PL/Rust zum Schreiben von PostgreSQL-Funktionen in der Sprache Rust

PL/Rust ist eine vertrauenswürdige Rust-Spracherweiterung für PostgreSQL. Sie können sie für gespeicherte Prozeduren, Funktionen und anderen prozeduralen Code verwenden, der von SQL aus aufrufbar ist. Die PL/Rust-Spracherweiterung ist in den folgenden Versionen verfügbar:

  • 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 auf GitHub.

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 Arbeiten mit Parametergruppen.

Sie können die plrust-Erweiterung mit der AWS Management Console oder der installieren AWS CLI.

Bei den folgenden Schritten wird davon ausgegangen, dass Ihre DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist.

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 Management Console und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Datenbanken aus.

  3. Wählen Sie den Namen Ihrer DB-Instance aus, um ihre Details anzuzeigen.

  4. Öffnen Sie die Registerkarte Konfiguration für Ihre DB-Instance und suchen Sie den Link zur DB-Instance-Parametergruppe.

  5. Wählen Sie den Link aus, um die benutzerdefinierten Parameter zu öffnen, die Ihrer DB-Instance zugeordnet sind.

  6. Geben Sie in das Suchfeld Parameters (Parameter) shared_pre ein, um den shared_preload_libraries-Parameter zu finden.

  7. Wählen Sie Edit parameters (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen.

  8. Fügen Sie der Liste im Feld Werte „plrust“ hinzu. Verwenden Sie ein Komma, um Elemente in der Werteliste zu trennen.

  9. 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.

  10. 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)
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. Verwenden Sie den modify-db-parameter-group AWS CLI Befehl , um dem shared_preload_libraries Parameter plrust 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
  2. Verwenden Sie den 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
  3. 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

Ab den Amazon RDS for PostgreSQL-Versionen 15.4, 14.9 und 13.12 unterstützt PL/Rust die folgenden Kisten:

  • aes

  • ctr

  • rand

Beginnend mit den RDS-for-PostgreSQL-Versionen 15.5-R2, 14.10-R2 und 13.13-R2 unterstützt PL/Rust zwei zusätzliche Kisten:

  • croaring-rs

  • num-bigint

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 und Upgrade einer PostgreSQL-DB-Engine für Amazon RDS im Amazon-RDS-Benutzerhandbuch.

Beispiele für die Verwendung von Abhängigkeiten bei der Erstellung einer PL/Rust-Funktion finden Sie unter Use dependencies.

Einschränkungen von PL/Rust

Standardmäßig können Datenbankbenutzer PL/Rust nicht verwenden. Um Zugriff auf PL/Rust zu gewähren, stellen Sie eine Verbindung als Benutzer mit der Berechtigung „rds_superuser“ her und führen Sie den folgenden Befehl aus:

postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;