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 „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);
```