Verwenden von SQL Postgre-Erweiterungen mit Amazon RDS for Postgre SQL - 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 SQL Postgre-Erweiterungen mit Amazon RDS for Postgre SQL

Sie können die Funktionalität von Postgre erweitern, SQL indem Sie eine Vielzahl von Erweiterungen und Modulen installieren. Um beispielsweise mit räumlichen Daten zu arbeiten, können Sie die GIS Post-Erweiterung installieren und verwenden. Weitere Informationen finden Sie unter Verwaltung von Geodaten mit der GIS Post-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 Postgre SQL 14.5 SQL unterstützt Postgre Trusted Language Extensions RDS für Postgre. RDS SQL Diese Funktion ist als Erweiterung implementiertpg_tle, die Sie zu Ihrer RDS for Postgre-DB-Instance hinzufügen können. SQL Mithilfe dieser Erweiterung können Entwickler ihre eigenen SQL Postgre-Erweiterungen in einer sicheren Umgebung erstellen, was die Einrichtungs- und Konfigurationsanforderungen vereinfacht. Weitere Informationen finden Sie unter Arbeiten mit Trusted Language Extensions für PostgreSQL.

In einigen Fällen können Sie, anstatt eine Erweiterung zu installieren, ein bestimmtes Modul zur Liste der benutzerdefinierten shared_preload_libraries SQL DB-Parametergruppen Ihrer RDS für Postgre-DB-Instance 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 im AWS Knowledge Center unter Ausführungspläne von Abfragen protokollieren.

Abhängig von Ihrer Version von RDS for Postgre SQL sind für die Installation einer Erweiterung möglicherweise folgende rds_superuser Berechtigungen erforderlich:

  • RDSFür SQL Postgre-Versionen 12 und frühere Versionen sind für die Installation von Erweiterungen Rechte erforderlichrds_superuser.

  • RDSFür SQL Postgre-Versionen 13 und höher können Benutzer (Rollen) mit Erstellungsberechtigungen für eine bestimmte Datenbankinstanz alle vertrauenswürdigen Erweiterungen installieren und verwenden. Eine Liste mit vertrauenswürdigen Erweiterungen finden Sie unter Vertrauenswürdige SQL Postgre-Erweiterungen.

Sie können auch genau angeben, welche Erweiterungen auf Ihrer RDS for SQL Postgre-DB-Instance installiert werden können, indem Sie sie im rds.allowed_extensions Parameter auflisten. Weitere Informationen finden Sie unter Einschränkung der Installation von Postgre-Erweiterungen SQL.

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 Orace-Erweiterung erleichtert Ihnen die Portierung einer Oracle-Anwendung nach Postgre. SQL RDSfür SQL Postgre-Versionen 9.6.6 und höher wird diese Erweiterung unterstützt. Weitere Informationen zu Oracle finden Sie unter orafce on. GitHub

Anmerkung

RDSfür Postgre unterstützt das utl_file Paket SQL nicht, das Teil der Orafce-Erweiterung 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. Da es sich um einen verwalteten Dienst handelt, RDS bietet er für Postgre SQL 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 pgactive Erweiterung verwendet die Active-Active-Replikation, um Schreibvorgänge auf mehreren Datenbanken für Postgre-Datenbanken zu unterstützen und zu koordinieren. RDS SQL Amazon RDS for Postgre SQL unterstützt die pgactive Erweiterung in den folgenden Versionen:

  • RDSfür Postgre SQL 16.1 und höhere 16-Versionen

  • RDSfür Postgre SQL 15.4-R2 und höhere Versionen 15

  • RDSfür Postgre SQL 14.10 und höhere 14-Versionen

  • RDSfür Postgre SQL 13.13 und höhere 13-Versionen

  • RDSfür Postgre SQL 12.17 und höhere 12-Versionen

  • RDSfür Postgre 11.22 SQL

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 pgactive Erweiterungsfunktion auf Ihrer RDS for SQL Postgre-DB-Instance zu initialisieren, setzen Sie den Wert des rds.enable_pgactive Parameters 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 Management Console oder das verwenden AWS CLI , um die RDS für Postgre SQL erforderlichen DB-Instances zu erstellen. Bei den folgenden Schritten wird davon ausgegangen, dass Ihre RDS for SQL Postgre-DB-Instance einer benutzerdefinierten DB-Parametergruppe zugeordnet ist. Informationen zum Erstellen einer benutzerdefinierten DB-Parametergruppe finden Sie unter Parametergruppen für Amazon RDS.

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

  2. Wählen Sie im Navigationsbereich Ihre RDS SQL Postgre-DB-Instance aus.

  3. Öffnen Sie die Registerkarte Konfiguration für Ihre RDS for SQL Postgre-DB-Instance. Suchen Sie in den Instance-Details nach dem Link DB-Instance-Parametergruppe.

  4. Wählen Sie den Link, um die benutzerdefinierten Parameter zu öffnen, die mit Ihrer RDS for SQL Postgre-DB-Instance verknüpft 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.

  7. Wählen Sie im Navigationsbereich der RDS Amazon-Konsole Datenbanken aus.

  8. Wählen Sie Ihre RDS für SQL Postgre-DB-Instance aus und wählen Sie dann im Aktionsmenü die Option Reboot 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 einen beliebigen anderen SQL Postgre-Client verwendenpsql, um eine Verbindung zur RDS for Postgre-DB-Instance herzustellen. SQL

    Im folgenden Beispiel wird davon ausgegangen, dass Ihre RDS for SQL Postgre-DB-Instance eine Standarddatenbank mit dem Namen hat postgres.

    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 das pgactive mit dem zu initialisieren AWS CLI, rufen Sie den modify-db-parameter-groupVorgang auf, um bestimmte Parameter in Ihrer benutzerdefinierten Parametergruppe zu ändern, wie im folgenden Verfahren gezeigt.

  1. Verwenden Sie den folgenden AWS CLI Befehl, um auf festzulegenrds.enable_pgactive, 1 um die pgactive Funktion RDS für die Postgre-DB-Instance zu initialisieren. SQL

    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 RDS for SQL Postgre-DB-Instance neu zu starten, sodass 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, verwenden Sie psql sie, um eine Verbindung zur herzustellen. RDSfür die SQL Postgre-DB-Instance.

    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;

Einrichtung der aktiv-aktiven Replikation für den SQL

Das folgende Verfahren zeigt Ihnen, wie Sie die aktiv-aktive Replikation zwischen zwei starten, auf denen Postgre SQL 15.4 oder höher in derselben Region ausgeführt wird. Um das Beispiel für Hochverfügbarkeit in mehreren Regionen auszuführen, müssen Sie Amazon RDS for SQL Postgre-Instances in zwei verschiedenen Regionen bereitstellen und Peering einrichtenVPC. Weitere Informationen finden Sie unter Peering. VPC

Anmerkung

Beim Senden von Datenverkehr zwischen mehreren Regionen können zusätzliche Kosten anfallen.

Bei diesen Schritten wird davon ausgegangen, dass die RDS for SQL Postgre-DB-Instance mit der pgactive Erweiterung eingerichtet wurde. Weitere Informationen finden Sie unter Initialisierung der „pgactive“-Erweiterungsfunktion.

Um die erste RDS für SQL Postgre-DB-Instance mit der Erweiterung zu konfigurieren pgactive

Das folgende Beispiel zeigt, wie die pgactive Gruppe erstellt wird, zusammen mit anderen Schritten, die zum Erstellen der pgactive Erweiterung auf der RDS for SQL Postgre-DB-Instance erforderlich sind.

  1. Verwenden Sie psql oder ein anderes Client-Tool, um eine Verbindung zu Ihrer ersten RDS for SQL Postgre-DB-Instance 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 for SQL Postgre-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 eine Beispieltabelle und füllen Sie sie mit den folgenden Anweisungen aus: SQL

    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 einigen Beispieldaten auf, indem Sie die folgende SQL Anweisung verwenden.

      app=> INSERT INTO inventory.products (id, product_name) VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
    3. Überprüfen Sie mithilfe der folgenden SQL Anweisung, ob Daten in der Tabelle vorhanden sind.

      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)
Um die zweite RDS für SQL Postgre-Instanz zu konfigurieren und sie der pgactive Gruppe hinzuzufügen

Das folgende Beispiel zeigt, wie Sie der pgactive Gruppe eine RDS for SQL Postgre-DB-Instance hinzufügen können, zusammen mit anderen Schritten, die zum Erstellen der pgactive Erweiterung auf der DB-Instance erforderlich sind.

Bei diesen Schritten wird davon ausgegangen, dass ein weiterer für SQL Postgre-DB-Instances mit der pgactive Erweiterung eingerichtet wurde. 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 SQL Postgre-DB-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 für die SQL zweite Postgre-DB-Instance wie folgt 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 SQL Datenbank RDS für Postgre relativ groß ist, können Sie sehenpgactive.pgactive_wait_for_node_ready(), dass der Fortschrittsbericht über den Wiederherstellungsvorgang ausgegeben wird. 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, überträgt Postgre SQL sie lokal und repliziert die Änderung anschließend asynchron pgactive auf andere DB-Instances. Wenn zwei SQL Postgre-DB-Instances denselben Datensatz fast zur gleichen Zeit aktualisieren, kann es zu einem Konflikt kommen.

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.

Sie pgactive.pgactive_conflict_history werden weiter wachsen. 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 Bereinigungsrichtlinie regelmäßig zu implementieren, besteht eine Möglichkeit darin, die Erweiterung zu verwenden. pg_cron Im Folgenden finden Sie ein Beispiel für die pg_cron History-Tabelle Scheduling maintenance with the Postgre SQL pg_cron extension.

Umgang mit Sequenzen bei der Aktiv-Aktiv-Replikation

Eine RDS SQL For-Postgre-DB-Instance mit der pgactive Erweiterung 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 SQL Postgre-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 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.

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.

  • DDLund 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 als Alternative zu verwenden, um Aufblähungen aus Tabellen und Indizes zu entfernen. VACUUM FULL Diese Erweiterung wird auf RDS SQL Postgre-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.

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 während der ersten Kopie 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 Neuaufbauvorgangs ist lediglich eine ACCESS SHARE Sperre für die Originaltabelle erforderlich, um Zeilen aus dieser Tabelle in die neue Tabelle zu kopieren. Dadurch können die DELETE Operationen INSERTUPDATE, und wie gewohnt weitergeführt werden.

Empfehlungen

Die folgenden Empfehlungen gelten, wenn Sie Bloat aus den Tabellen und Indizes mithilfe der pg_repack Erweiterung entfernen:

  • Führen Sie das Umpacken 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 keine Aktivität in der Originaltabelle gibt, die möglicherweise blockiert werden könntepg_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.

    Wenn Sie eine blockierende Sitzung sehen, können Sie sie nach reiflicher Überlegung mit dem folgenden Befehl beenden. Dies hilft bei der Fortsetzung der pg_repack Fertigstellung des Neuaufbaus:

    SELECT pg_terminate_backend(pid);
  • Beim Anwenden der aufgelaufenen Änderungen aus der pg_repack's Protokolltabelle auf Systeme mit einer sehr hohen Transaktionsrate kann der Anwenden-Prozess möglicherweise nicht mit der Änderungsrate Schritt halten. In solchen Fällen pg_repack könnte das Antragsverfahren nicht abgeschlossen werden. Weitere Informationen finden Sie unter Überwachung der neuen Tabelle während des Repackens. Wenn Indizes stark aufgebläht sind, besteht eine alternative Lösung darin, nur den Index neu zu packen. Dies trägt auch dazu bei, VACUUM dass die Indexbereinigungszyklen schneller abgeschlossen werden.

    Ab SQL Postgre-Version 12 können Sie die Phase der Indexbereinigung manuell überspringen. VACUUM Ab Postgre Version 14 wird sie beim automatischen Notabsaugen automatisch übersprungen. SQL Auf diese Weise können Sie schneller VACUUM fertig werden, ohne den aufgeblähten Index zu entfernen, und ist nur für Notfallsituationen gedacht, z. B. zur Vermeidung von Wraparound-Vorgängen. VACUUM Weitere Informationen finden Sie unter Vermeidung von Aufblähungen in Indizes im Amazon Aurora Aurora-Benutzerhandbuch.

Voraussetzungen

  • Die Tabelle muss eine Einschränkung haben PRIMARY KEY oder nicht UNIQUE Null.

  • Die Erweiterungsversion muss sowohl für den Client als auch für den Server identisch sein.

  • Stellen Sie sicher, dass die RDS Instanz mehr FreeStorageSpace als die Gesamtgröße der Tabelle ohne Aufblähung hat. Stellen Sie sich als Beispiel die Gesamtgröße der Tabelle einschließlich Indizes mit 2 TB TOAST und die Gesamtgröße der Tabelle mit 1 TB vor. Der erforderliche Wert FreeStorageSpace muss größer sein als der von der folgenden Berechnung zurückgegebene Wert:

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

    Sie können die folgende Abfrage verwenden, um die Gesamtgröße der Tabelle zu überprüfen und daraus eine Aufblähung pgstattuple abzuleiten. Weitere Informationen finden Sie unter Diagnosing Table and Index Bloat im Amazon Aurora 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 Repack-Vorgang abzuwickeln. Sie könnten erwägen, die Instance-Klasse zu skalieren, um ein optimales Leistungsgleichgewicht zu erzielen.

Um die pg_repack Erweiterung zu verwenden
  1. Installieren Sie die pg_repack Erweiterung auf Ihrer RDS for SQL Postgre-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 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;
  3. Stellen Sie mithilfe des pg_repack Client-Dienstprogramms eine Connect zur 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 gilt pg_repack für vollständige Tabellen, 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 die 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 gepackt wurden.

    INFO: repacking table "pgbench_tellers" INFO: repacking table "pgbench_accounts" INFO: repacking table "pgbench_branches"
  4. Die folgende Syntax packt eine einzelne Tabelle orders einschließlich der Indizes in der Datenbank neu. postgres

    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 orders Tabellen in der Datenbank neu gepackt. postgres

    pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres

Überwachung der neuen Tabelle während des Repackens

  • Die Größe der Datenbank wird bis zur swap-and-drop Phase des Repacks um die Gesamtgröße der Tabelle abzüglich des Bloats erhöht. Sie können die Wachstumsrate der Datenbankgröße überwachen, die Geschwindigkeit des Neupackens 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 durch die Berechnung am Ende des Repack-Vorgangs zurückgegebene Wert für die Gesamtgröße der Datenbank lautet wie folgt:

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

    Sie können die Geschwindigkeit des Repack-Vorgangs 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 müssen pg_repack auch die aufgelaufenen Änderungen übernommen werden. 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.

  • Die Anzahl der Zeilen in der pg_repack's Protokolltabelle gemäß dem Repack-Schema entspricht der Menge der Änderungen, die nach dem ersten Laden noch auf die neue Tabelle angewendet werden müssen.

    Sie können die pg_repack's Protokolltabelle eincheckenpg_stat_all_tables, um die Änderungen zu überwachen, die auf die neue Tabelle angewendet wurden. pg_stat_all_tables.n_live_tupgibt die Anzahl der Datensätze an, deren Übernahme auf die neue Tabelle noch aussteht. 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 herauszufinden, wie viel Zeit für jeden Schritt des Repack-Vorgangs benötigt wird. Dies ist hilfreich bei der Vorbereitung auf die Anwendung desselben Upack-Vorgangs 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 um einen kompletten 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 Umpacken 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 Repack-Vorgangs.

Aktualisierung und Verwendung der Erweiterung PLV8

PLV8ist eine vertrauenswürdige Javascript-Spracherweiterung für SQL Postgre. Sie können sie für gespeicherte Prozeduren, Trigger und anderen prozeduralen Code verwenden, von dem aus aufgerufen werden kann. SQL Diese Spracherweiterung wird von allen aktuellen Versionen von SQL Postgre unterstützt.

Wenn Sie Postgre verwenden PLV8und SQL 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 PLV8 zu synchronisieren. 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. Wir empfehlen Ihnen daher, vor dem Upgrade einen Snapshot Ihrer RDS for SQL Postgre-DB-Instance zu erstellen. Weitere Informationen finden Sie unter Erstellen eines DB-Snapshots für eine Single-AZ-DB-Instance.

Um Ihre Katalog-Metadaten 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)
  2. Erstellen Sie einen Snapshot Ihrer RDS für SQL Postgre-DB-Instance, falls Sie dies noch nicht getan haben. Sie können die folgenden Schritte fortsetzen, während der Snapshot erstellt wird.

  3. 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');
  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 Hauptbenutzername RDS

    • database – Der Datenbankname für unsere DB-Instance

    Weitere Informationen zu pg_dump finden Sie unter pg_dump in der Postgre-Dokumentation. SQL

  5. Extrahieren Sie die "CREATEFUNCTION" DDL -Anweisung, die in der Dump-Datei enthalten ist. Im folgenden Beispiel wird der grep Befehl verwendet, um die DDL Anweisung zu extrahieren, mit der die Funktionen erstellt wurden, 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 Postgre-Dokumentation. SQL

  6. Verwerfen Sie die Funktionen und Erweiterungen. Im folgenden Beispiel werden alle basierten Objekte gelöscht. PLV8 Die Option cascade stellt sicher, dass alle Abhängigkeiten verworfen werden.

    DROP EXTENSION plv8 CASCADE;

    Wenn Ihre SQL Postgre-Instanz 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');

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

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

Verwenden von PL/Rust zum Schreiben von SQL Postgre-Funktionen in der Rust-Sprache

PL/Rust ist eine vertrauenswürdige Rust-Spracherweiterung für Postgre. SQL Sie können es für gespeicherte Prozeduren, Funktionen und anderen prozeduralen Code verwenden, von dem aus aufgerufen werden kann. SQL Die PL/Rust-Spracherweiterung ist in den folgenden Versionen verfügbar:

  • RDSfür Postgre SQL 16.1 und höhere Versionen 16

  • RDSfür Postgre SQL 15.2-R2 und höhere 15-Versionen

  • RDSfür Postgre SQL 14.9 und höhere 14-Versionen

  • RDSfür Postgre SQL 13.12 und höhere 13-Versionen

Weitere Informationen finden Sie unter PL/Rust on. 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 Parametergruppen für Amazon RDS.

Sie können die Plrust-Erweiterung mit dem oder dem AWS Management Console 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 RDS Amazon-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

In den RDS SQL Postgre-Versionen 16.3-R2 und höher, 15.7-R2 und höher 15 Versionen, 14.12-R2 und höher 14 Versionen und 13.15-R2 und höher 13 Versionen unterstützt PL/Rust zusätzliche Crates:

  • url

  • regex

  • serde

  • serde_json

In den RDS SQL Postgre-Versionen 15.5-R2 und höher, 14.10-R2 und höher (14) und 13.13-R2 und höher (13) unterstützt PL/Rust zwei zusätzliche Crates:

  • croaring-rs

  • num-bigint

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

  • aes

  • ctr

  • rand

Für diese Kisten werden nur die Standardfunktionen unterstützt. Neue Versionen RDS für Postgre enthalten möglicherweise aktualisierte SQL Versionen von Crates, und ältere Versionen von Crates 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 in den Blog-Beiträgen Best Practices für das Upgrade von Amazon RDS auf Haupt- und Nebenversionen von Postgre SQL und Upgrading the Postgre SQL DB Engine for Amazon RDS im RDS Amazon-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;