Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo di pgactive per supportare la replica active-active
L'estensione `pgactive` utilizza la replica active-active per supportare e coordinare le operazioni di scrittura su più database RDS per PostgreSQL. Amazon RDS per PostgreSQL supporta l’estensione `pgactive` sulle seguenti versioni:
+ RDS per PostgreSQL 17.0 e tutte le versioni successive
+ RDS per PostgreSQL 16.1 e versioni successive 16
+ RDS per PostgreSQL 15.4-R2 e versioni successive 15
+ RDS per PostgreSQL 14.10 e versioni successive (14)
+ RDS per PostgreSQL 13.13 e versioni successive (13)
+ RDS per PostgreSQL 12.17 e versioni successive (12)
+ RDS per PostgreSQL 11.22
**Nota**
Quando sono presenti operazioni di scrittura su più di un database in una configurazione di replica, sono possibili conflitti. Per ulteriori informazioni, consulta [Gestione dei conflitti nella replica active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
**Topics**
+ [Limitazioni per l'estensione pgactive](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [Inizializzazione della funzionalità di estensione pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [Configurazione della replica active-active per istanze database RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [Misurazione del ritardo di replica tra i membri pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [Configurazione delle impostazioni dei parametri per l’estensione pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [Comprensione dei conflitti in modalità attivo-attivo](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [Informazioni sullo schema pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [Informazioni di riferimento sulle funzioni pgactive](pgactive-functions-reference.md)
+ [Gestione dei conflitti nella replica active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [Gestione delle sequenze nella replica active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## Limitazioni per l'estensione pgactive
+ Tutte le tabelle richiedono una chiave primaria, altrimenti le opzioni di aggiornamento ed eliminazione non sono consentite. I valori nella colonna Chiave primaria non devono essere aggiornati.
+ Le sequenze possono presentare delle lacune e talvolta potrebbero non seguire un ordine. Le sequenze non vengono replicate. Per ulteriori informazioni, consulta [Gestione delle sequenze nella replica active-active](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md).
+ DDL e oggetti di grandi dimensioni non vengono replicati.
+ Gli indici univoci secondari possono causare divergenze tra i dati.
+ Le regole di confronto devono essere identiche su tutti i nodi del gruppo.
+ Il bilanciamento del carico tra i nodi è un anti-pattern.
+ Le transazioni di grandi dimensioni possono causare ritardi nella replica.
# Inizializzazione della funzionalità di estensione pgactive
Per inizializzare la funzionalità dell'estensione `pgactive` sull'istanza database RDS per PostgreSQL, imposta il valore del parametro `rds.enable_pgactive` su `1` e quindi crea l'estensione nel database. In questo modo si attivano automaticamente i parametri `rds.logical_replication` e `track_commit_timestamp` e il valore `wal_level` viene impostato su `logical`.
Per eseguire queste attività sono richieste le autorizzazioni del ruolo `rds_superuser`.
È possibile utilizzare Console di gestione AWS o the AWS CLI per creare l'RDS richiesto per le istanze DB PostgreSQL. I passaggi seguenti si basano sull'ipotesi che l'istanza database Amazon RDS per PostgreSQL sia associata a un gruppo di parametri di database personalizzato. Per ulteriori informazioni sulla creazione di un gruppo di parametri personalizzato, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md).
## Console
**Inizializzazione della funzionalità di estensione pgactive**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegli l'istanza database RDS per PostgreSQL.
1. Apri la scheda **Configurazione** per l'istanza database RDS per PostgreSQL. Nei dettagli dell'istanza, trova il link **Gruppo di parametri dell'istanza database**.
1. Scegli il link per aprire i parametri personalizzati associati all'istanza database RDS per PostgreSQL.
1. Trova il parametro `rds.enable_pgactive` e impostalo su `1` per inizializzare la funzionalità `pgactive`.
1. Scegli **Save changes** (Salva modifiche).
1. Nel pannello di navigazione della console di Amazon RDS, scegli **Database**.
1. Seleziona l'istanza database RDS per PostgreSQL, quindi scegli **Riavvia** dal menu **Operazioni**.
1. Conferma il riavvio dell'istanza database per applicare le modifiche.
1. Quando l'istanza database è disponibile, puoi usare `psql` o qualsiasi altro client PostgreSQL per connetterti all'istanza database RDS per PostgreSQL.
L'esempio seguente presuppone che l'istanza DB RDS per PostgreSQL abbia un database predefinito denominato. *postgres*
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Per verificare che l'estensione pgactive sia inizializzata, esegui il seguente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Se `pgactive` è presente in `shared_preload_libraries`, il comando precedente restituirà quanto segue:
```
?column?
----------
t
```
## AWS CLI
**Inizializzazione della funzionalità di estensione pgactive**
Per inizializzare l'`pgactive`utilizzo di AWS CLI, richiamate l'[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html)operazione per modificare determinati parametri nel gruppo di parametri personalizzato, come illustrato nella procedura seguente.
1. Utilizzare il AWS CLI comando seguente `rds.enable_pgactive` per `1` impostare l'inizializzazione della `pgactive` funzionalità per l'istanza DB RDS for PostgreSQL.
```
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. Utilizzare il AWS CLI comando seguente per riavviare l'istanza DB RDS for PostgreSQL in modo che la libreria venga inizializzata. `pgactive`
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. Quando l'istanza è disponibile, utilizza `psql` per connetterti all'istanza database RDS per PostgreSQL.
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. Per verificare che l'estensione pgactive sia inizializzata, esegui il seguente comando.
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
Se `pgactive` è presente in `shared_preload_libraries`, il comando precedente restituirà quanto segue:
```
?column?
----------
t
```
# Configurazione della replica active-active per istanze database RDS per PostgreSQL
La seguente procedura mostra come avviare la replica attiva-attiva istanze database RDS per PostgreSQL in cui è disponibile `pgactive`. Per eseguire l'esempio di elevata disponibilità multiregionale, devi distribuire istanze Amazon RDS per PostgreSQL in due regioni diverse e configurare il peering VPC. Per ulteriori informazioni, consulta [Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
**Nota**
L'invio di traffico tra più regioni può comportare costi aggiuntivi.
Questi passaggi presuppongono che l’istanza database RDS per PostgreSQL sia stata abilitata con l’estensione `pgactive`. Per ulteriori informazioni, consulta [Inizializzazione della funzionalità di estensione pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
**Configurazione della prima istanza database RDS per PostgreSQL con l'estensione `pgactive`**
L'esempio seguente illustra come viene creato il gruppo `pgactive`, insieme ad altri passaggi necessari per creare l'estensione `pgactive`sull'istanza database RDS per PostgreSQL.
1. Usa `psql` o un altro strumento client per connetterti alla tua prima istanza database RDS per PostgreSQL.
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Crea un database sull'istanza RDS per PostgreSQL utilizzando il seguente comando:
```
postgres=> CREATE DATABASE app;
```
1. Passa alla connessione al nuovo database utilizzando il seguente comando:
```
\c app
```
1. Crea e popola una tabella di esempio utilizzando le seguenti istruzioni SQL:
1. Crea una tabella di esempio utilizzando la seguente istruzione SQL.
```
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. Popola la tabella con alcuni dati di esempio utilizzando la seguente istruzione SQL.
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. Verifica che i dati siano presenti nella tabella utilizzando la seguente istruzione SQL.
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. Crea l'estensione `pgactive` database esistente.
```
app=> CREATE EXTENSION pgactive;
```
1. Per creare e inizializzare il gruppo pgactive in modo sicuro, utilizza i seguenti comandi:
```
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 '');
```
Ora puoi inizializzare il gruppo di replica e aggiungere questa prima istanza:
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
Utilizza i seguenti comandi come metodo alternativo, ma meno sicuro, per creare e inizializzare il gruppo pgactive:
```
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 è il nome che assegni per identificare in modo univoco un nodo nel gruppo `pgactive`.
**Nota**
Per eseguire correttamente questo passaggio su un'istanza database accessibile pubblicamente, è necessario attivare il parametro `rds.custom_dns_resolution` impostandolo su `1`.
1. Per verificare se l'istanza database è pronta, usa il seguente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Se il comando viene eseguito correttamente, verrà visualizzato il seguente output:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**Configurazione della seconda istanza RDS per PostgreSQL e collegamento al gruppo `pgactive`**
L'esempio seguente illustra come puoi collegare un'istanza database RDS per PostgreSQL al gruppo `pgactive`, insieme ad altri passaggi necessari per creare l'estensione `pgactive` sull'istanza database.
Questi passaggi presuppongono che sia stata eseguita la configurazione di un ulteriore istanza database RDS per PostgreSQL con l'estensione `pgactive`. Per ulteriori informazioni, consulta [Inizializzazione della funzionalità di estensione pgactive](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md).
1. Utilizza `psql` per connetterti all'istanza per cui vuoi ricevere gli aggiornamenti dal publisher.
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. Crea un database sulla seconda istanza database RDS per PostgreSQL utilizzando il seguente comando:
```
postgres=> CREATE DATABASE app;
```
1. Passa alla connessione al nuovo database utilizzando il seguente comando:
```
\c app
```
1. Crea l'estensione `pgactive` database esistente.
```
app=> CREATE EXTENSION pgactive;
```
1. Unisci la seconda istanza database RDS per PostgreSQL al gruppo `pgactive` in modo più sicuro utilizzando i seguenti comandi:
```
-- 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'
);
```
Utilizza i comandi indicati di seguito come metodo alternativo, ma meno sicuro, per unire la seconda istanza database RDS per PostgreSQL al gruppo `pgactive`
```
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 è il nome che assegni per identificare in modo univoco un nodo nel gruppo `pgactive`.
1. Per verificare se l'istanza database è pronta, usa il seguente comando:
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
Se il comando viene eseguito correttamente, verrà visualizzato il seguente output:
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
Se il primo database RDS per PostgreSQL è relativamente grande, puoi vedere l'emissione di `pgactive.pgactive_wait_for_node_ready()` del report sullo stato di avanzamento dell'operazione di ripristino. L'esito si presenta in maniera analoga all'immagine riportata di seguito.
```
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)
```
Da questo momento in poi, `pgactive` sincronizza i dati tra le due istanze database.
1. Puoi utilizzare il comando seguente per verificare se il database della seconda istanza database contiene i dati:
```
app=> SELECT count(*) FROM inventory.products;
```
Se i dati vengono sincronizzati correttamente, verrà visualizzato il seguente output:
```
count
-------
3
```
1. Esegui il seguente comando per inserire nuovi valori:
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. Connettiti al database della prima istanza database ed esegui la seguente query:
```
app=> SELECT count(*) FROM inventory.products;
```
Se la replica active-active è inizializzata, l'output è simile al seguente:
```
count
-------
4
```
**Scollegamento e rimozione di un'istanza database dal gruppo `pgactive`**
Puoi scollegare e rimuovere un'istanza database dal gruppo `pgactive` utilizzando la procedura seguente:
1. Puoi scollegare la seconda istanza database dalla prima istanza database utilizzando il seguente comando:
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. Rimuovi l'estensione `pgactive` dalla seconda istanza database utilizzando il seguente comando:
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
Per rimuovere forzatamente l'estensione:
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. Elimina l'estensione usando il seguente comando:
```
app=> DROP EXTENSION pgactive;
```
# Misurazione del ritardo di replica tra i membri pgactive
È possibile utilizzare la seguente query per visualizzare il ritardo di replica tra i membri `pgactive`. Esegui questa query su ogni nodo `pgactive` per ottenere il quadro completo.
```
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
```
Monitora almeno la seguente diagnostica:
attiva
Imposta avvisi quando active è false, il che indica che lo slot non è al momento in uso (l’istanza subscriber si è disconnessa dal publisher).
pending\$1wal\$1decoding
Nella replica logica di PostgreSQL, i file WAL vengono archiviati in formato binario. Il publisher deve decodificare queste modifiche WAL e convertirle in modifiche logiche (come operazioni di inserimento, aggiornamento o eliminazione).
La metrica pending\$1wal\$1decoding mostra il numero di file WAL in attesa di essere decodificati sul lato del publisher.
Questo numero può aumentare a causa di questi fattori:
+ Quando il subscriber non è connesso, lo stato active sarà false e pending\$1wal\$1decoding aumenterà
+ Lo slot è attivo, ma il publisher non riesce a tenere il passo con il volume delle modifiche WAL
pending\$1wal\$1to\$1apply
La metrica pending\$1wal\$1apply indica il numero di file WAL in attesa di essere applicati sul lato del subscriber.
Diversi fattori possono impedire al subscriber di applicare le modifiche e potenzialmente causare uno scenario di disco pieno:
+ Differenze nello schema: ad esempio, quando si apportano modifiche nel flusso WAL per una tabella denominata sample, ma tale tabella non esiste sul lato del subscriber
+ I valori nelle colonne chiave primaria erano stati aggiornati
+ Gli indici univoci secondari possono causare divergenze tra i dati.
# Configurazione delle impostazioni dei parametri per l’estensione pgactive
È possibile utilizzare la seguente query per visualizzare tutti i parametri associati all’estensione `pgactive`.
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
Puoi configurare l’estensione `pgactive` utilizzando vari parametri. Questi parametri possono essere impostati tramite l'interfaccia CLI Console di gestione AWS o l' AWS interfaccia CLI.
## Principali parametri dell’estensione pgactive
La tabella seguente fornisce un riferimento per i parametri principali dell’estensione `pgactive`:
| Parametro | Unità | Predefinita | Description |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | Registra le informazioni complete sulla tupla per l’estensione `pgactive`. Per rendere effettive le modifiche apportate, è necessario riavviare il server. |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | Determina se l’estensione `pgactive` registra i conflitti rilevati nella tabella `pgactive.pgactive_conflict_history`. Per ulteriori informazioni, consulta la sezione relativa alla registrazione di log dei conflitti per maggiori dettagli. Per rendere effettive le modifiche apportate, è necessario riavviare il server. |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | Determina se l’estensione `pgactive` registra i conflitti rilevati nel file di log PostgreSQL. Per ulteriori informazioni, consulta la sezione relativa alla registrazione di log dei conflitti per maggiori dettagli. Per rendere effettive le modifiche apportate, è necessario riavviare il server. |
| pgactive.synchronous\$1commit | `boolean` | off | Determina il comportamento di commit per i worker apply pgactive. Se sono disabilitati (off), i worker apply eseguono commit asincroni. Ciò migliora il throughput di PostgreSQL durante le operazioni apply, ma ritarda le conferme di riproduzione all’upstream. Impostarli su `off` è sempre sicuro ed eviterà che le transazioni vengano perse o ignorate. Questa impostazione influisce solo sulla tempistica del flush su disco sul nodo downstream e sull’invio delle conferme upstream. Il sistema ritarda l’invio delle conferme di replay flush finché non viene eseguito il flush dei commit su disco tramite operazioni non correlate come checkpoint o operazioni periodiche. Tuttavia, se nel nodo upstream il nodo downstream è elencato in `synchronous_standby_names`, impostando il parametro su `off` i commit sincroni del nodo upstream impiegheranno più tempo a segnalare l’esito positivo al client. In tal caso, imposta il parametro su `on`. Anche quando questo parametro è impostato su `on` con nodi elencati in `synchronous_standby_names`, è comunque possibile che si verifichino conflitti di replica nelle configurazioni attive-attive. Questo accade perché il sistema non dispone del blocco tra i nodi e della gestione globale delle snapshot, il che consente alle transazioni simultanee su nodi diversi di modificare la stessa tupla. Inoltre, le transazioni iniziano la replica solo dopo il commit sul nodo upstream. L’abilitazione del commit sincrono non trasforma l’estensione pgactive in un sistema sempre coerente. |
| pgactive.temp\$1dump\$1directory | `string` | – | Definisce il percorso di archiviazione temporaneo richiesto per le operazioni di clonazione del database durante la configurazione iniziale. Questa directory deve essere scrivibile dall’utente postgres e deve disporre di spazio di archiviazione sufficiente per contenere un dump completo del database. Il sistema utilizza questa posizione solo durante la configurazione iniziale del database con operazioni di copia logica. Questo parametro non viene utilizzato da `pgactive_init_copy command`. |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | Specifica il tempo di attesa massimo per il blocco DDL prima dell’interruzione forzata delle transazioni di scrittura simultanee. Il valore predefinito è `-1`, che adotta il valore impostato in `max_standby_streaming_delay`. Questo parametro accetta unità temporali. Ad esempio, puoi impostarlo su 10 secondi per 10 secondi. Durante questo periodo di attesa, il sistema tenta di acquisire blocchi DDL in attesa del commit o del rollback delle transazioni di scrittura in corso. Per ulteriori informazioni, consulta la sezione sul blocco DDL. |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | Specifica il lasso di tempo che un tentativo di blocco DDL attende per ottenere il blocco. Il valore predefinito è `-1`, che utilizza il valore specificato in lock\$1timeout. Puoi impostare questo parametro utilizzando unità di tempo come 10s per 10 secondi. Questo timer controlla solo il periodo di attesa per ottenere un blocco DDL. Una volta che il sistema ottiene il blocco e inizia l’operazione DDL, il timer si arresta. Questo parametro non limita la durata totale di mantenimento di un blocco DDL né il tempo complessivo dell’operazione DDL. Per controllare la durata totale dell’operazione, usa `statement_timeout` invece. Per ulteriori informazioni, consulta la sezione sul blocco DDL. |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | Sostituisce il livello di log di debug predefinito per le operazioni di blocco DDL nell’estensione `pgactive`. Se configurata, questa impostazione fa sì che i messaggi relativi al blocco DDL vengano emessi al livello di debug del LOG anziché al livello predefinito. Utilizza questo parametro per monitorare l’attività di blocco DDL senza abilitare i livelli di log `DEBUG1` `DEBUG2` dettagliati sull’intero server. Livelli di log disponibili, in ordine crescente di dettaglio: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Per ulteriori informazioni sulle opzioni di monitoraggio, consulta la sezione sul monitoraggio dei blocchi DDL globali. Le modifiche a questa impostazione vengono eseguite quando ricarichi la configurazione. Non è necessario riavviare il server. |
## Parametri aggiuntivi dell’estensione pgactive
La tabella seguente presenta le opzioni di configurazione interne e utilizzate meno di frequente disponibili per l’estensione `pgactive`.
| Parametro | Unità | Predefinita | Description |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | Imposta un ritardo di applicazione (in millisecondi) per le connessioni configurate che non hanno un ritardo di applicazione esplicito nella voce `pgactive.pgactive_connections`. Questo ritardo viene impostato durante la creazione del nodo o al momento del join e pgactive non riprodurrà una transazione sui nodi peer finché non sarà trascorso almeno il numero di millisecondi specificato dal momento in cui è stato eseguito il commit. Utilizzato principalmente per simulare reti ad alta latenza in ambienti di test per facilitare la creazione di conflitti. Ad esempio, con un ritardo di 500 ms sui nodi A e B, hai almeno 500 ms per eseguire un inserimento in conflitto sul nodo B dopo aver inserito un valore sul nodo A. Per rendere effettivi i worker apply, è necessario ricaricare o riavviare il server. |
| pgactive.connectability\$1check\$1duration | `integer` | – | Specifica la durata (in secondi) del tempo che un worker del database attende per stabilire connessioni durante i tentativi falliti. Il worker effettua un tentativo di connessione al secondo finché non riesce o non raggiunge questo valore di timeout. Questa impostazione è utile quando il motore del database si avvia prima che il worker sia pronto a stabilire delle connessioni. |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | Controlla il modo in cui le modifiche DDL vengono replicate o gestite in Amazon RDS con il parametro `pgactive` abilitato. Se impostato su `on`, il nodo elabora le modifiche DDL come un nodo non-pgactive. Quando si lavora con questo parametro, vengono applicati i seguenti requisiti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puoi modificare questo parametro in due modi con i privilegi di super utente: globalmente e localmente (a livello di sessione). Modificare questo parametro in modo errato può comportare l’interruzione delle configurazioni di replica. |
| pgactive.do\$1not\$1replicate | `boolean` | – | Questo parametro è solo per l’uso interno. Quando imposti questo parametro in una transazione, le modifiche non vengono replicate su altri nodi del cluster di database. Modificare questo parametro in modo errato può comportare l’interruzione delle configurazioni di replica. |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | Questo parametro è destinato esclusivamente all’uso da parte di specialisti. Si consiglia di utilizzare questo parametro solo per la risoluzione di problemi di replica specifici. Utilizza questo parametro quando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Questa impostazione sovrascrive il messaggio di errore seguente e consente la divergenza dei dati per fare in modo che la replica continui: `cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute` Modificare questo parametro in modo errato può comportare l’interruzione delle configurazioni di replica. |
| pgactive.debug\$1trace\$1replay | `boolean` | – | Se impostato su `on`, emette un messaggio di log per ogni azione remota che i worker apply downstream elaborano. I log includono: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) I log registrano anche i comandi DDL in coda e le eliminazioni di tabelle.para> Per impostazione predefinita, i log non includono il contenuto dei campi riga. Per includere i valori delle righe nei log, è necessario eseguire di nuovo la compilazione con i seguenti flag abilitati: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) L’attivazione di questa impostazione di log può influire sulle prestazioni. Si consiglia di abilitarla solo se necessario per la risoluzione dei problemi. Le modifiche a questa impostazione vengono eseguite quando ricarichi la configurazione. Non è necessario riavviare il server. |
| pgactive.extra\$1apply\$1connection\$1options | | – | Puoi configurare i parametri di connessione per tutte le connessioni tra nodi peer con nodi pgactive. Questi parametri controllano impostazioni quali keepalives e modalità SSL. Per impostazione predefinita, pgactive utilizza i seguenti parametri di connessione: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Per sovrascrivere i parametri predefiniti, utilizza il seguente comando simile: pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' Le stringhe di connessione dei singoli nodi hanno la precedenza su entrambe queste impostazioni e sulle opzioni di connessione integrate di pgactive. Per ulteriori informazioni sui formati delle stringhe di connessione, consulta la sezione sulle [stringhe di connessione libpq](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). Consigliamo di mantenere abilitate le impostazioni keepalive predefinite. Disabilita keepalive solo se riscontri problemi con il completamento di transazioni di grandi dimensioni su reti inaffidabili. Consigliamo di mantenere abilitate le impostazioni keepalive predefinite. Disabilita keepalive solo se riscontri problemi con il completamento di transazioni di grandi dimensioni su reti inaffidabili. Le modifiche a questa impostazione vengono eseguite quando ricarichi la configurazione. Non è necessario riavviare il server. |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | Specifica il numero di lavori paralleli che `pg_dump` e `pg_restore` possono utilizzare durante l’unione del nodo logico con la funzione `pgactive.pgactive_join_group`. Le modifiche a questa impostazione vengono eseguite quando ricarichi la configurazione. Non è necessario riavviare il server. |
| pgactive.max\$1nodes | `int` | 4 | Specifica il numero massimo di nodi permessi in un gruppo di estensioni pgactive. Il valore predefinito è 4 nodi. È necessario considerare quanto segue quando si imposta il valore di questo parametro: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) Puoi impostare questo parametro in due modi: nel file di configurazione, utilizzando il comando `ALTER SYSTEM SET` Il valore predefinito per questo parametro è `4`, il che significa che possono essere consentiti al massimo 4 nodi nel gruppo di estensioni `pgactive` in qualsiasi momento. La modifica ha effetto dopo il riavvio del server. |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | Questo parametro è destinato esclusivamente all’uso interno. Se abilitata, l’estensione `pgactive` consente la creazione della funzione getter dell’identificatore del nodo pgactive. |
# Comprensione dei conflitti in modalità attivo-attivo
Quando utilizzi pgactive in modalità attivo-attivo, la scrittura da più nodi sulle stesse tabelle può creare conflitti di dati. Anche se alcuni sistemi di clustering utilizzano blocchi distribuiti per impedire l’accesso simultaneo, pgactive adotta un approccio ottimistico più adatto per applicazioni distribuite geograficamente.
Alcuni sistemi di clustering di database impediscono l’accesso simultaneo ai dati utilizzando blocchi distribuiti. Sebbene sia efficace quando i server sono nelle immediate vicinanze, questo approccio non supporta applicazioni distribuite geograficamente, perché per offrire buone prestazioni richiede una latenza estremamente bassa. Anziché ricorrere a blocchi distribuiti (approccio pessimistico), l’estensione pgactive utilizza un approccio ottimistico. Questo significa che:
+ Contribuisce a evitare i conflitti quando possibile.
+ Consente il verificarsi di determinati tipi di conflitti.
+ Fornisce la risoluzione dei conflitti quando questi si verificano.
Questo approccio offre una maggiore flessibilità durante la creazione di applicazioni distribuite.
## Come avvengono i conflitti
I conflitti tra nodi derivano da sequenze di eventi che non potrebbero verificarsi se tutte le transazioni coinvolte avvenissero contemporaneamente sullo stesso nodo. Poiché i nodi scambiano le modifiche solo dopo il completamento delle transazioni, ogni transazione è valida individualmente sul nodo su cui è stata effettuata, ma non lo sarebbe se eseguita su un altro nodo che nel frattempo ha svolto altre operazioni. Poiché, essenzialmente, pgactive apply riproduce la transazione sugli altri nodi, in caso di conflitto tra una transazione applicata e una transazione che è stata effettuata sul nodo ricevente, l’operazione di riproduzione può fallire.
Il motivo per cui la maggior parte dei conflitti non può verificarsi quando tutte le transazioni vengono eseguite su un singolo nodo è che PostgreSQL dispone di meccanismi di comunicazione tra transazioni che ne consentono la prevenzione, tra cui:
+ Indici UNIQUE
+ SEQUENCEs
+ Blocco di righe e relazioni
+ Tracciamento delle dipendenze in modalità SERIALIZABLE
Tutti questi meccanismi consentono la comunicazione tra le transazioni per prevenire problemi di concorrenza indesiderati
pgactive raggiunge una bassa latenza e gestisce correttamente le partizioni di rete, perché non utilizza un gestore di transazioni distribuito o un gestore di blocchi. Questo significa, tuttavia, che le transazioni su nodi diversi vengono eseguite in completo isolamento l’una dall’altra. Sebbene in genere l’isolamento migliori la coerenza del database, in questo caso è necessario ridurlo per prevenire i conflitti.
## Tipi di conflitti
I conflitti che possono verificarsi includono:
**Topics**
+ [Conflitti con vincoli PRIMARY KEY o UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [Conflitti INSERT/INSERT](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [INSERTs che violano più vincoli UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [Conflitti UPDATE/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [Conflitti UPDATE sulla PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [UPDATEs che violano più vincoli UNIQUE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [Conflitti UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [Conflitti INSERT/UPDATE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [Conflitti DELETE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [Conflitti con vincoli di chiave esterna](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [Conflitti con vincoli di esclusione](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [Conflitti di dati globali](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [Conflitti di blocco e interruzioni per deadlock](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [Conflitti divergenti](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### Conflitti con vincoli PRIMARY KEY o UNIQUE
I conflitti di riga si verificano quando più operazioni tentano di modificare la stessa chiave di riga in modi che non sarebbero consentiti su un singolo nodo. Questi conflitti rappresentano il tipo di conflitti sui dati più comune.
pgactive risolve i conflitti rilevati tramite la last-update-wins gestione o il tuo gestore di conflitti personalizzato.
I conflitti di riga includono:
+ INSERT/INSERT
+ INSERT/UPDATE
+ UPDATE/DELETE
+ INSERT/DELETE
+ DELETE/DELETE
+ INSERT/DELETE
### Conflitti INSERT/INSERT
Questo conflitto più comune si verifica quando INSERTs su due nodi diversi si crea una tupla con gli stessi valori PRIMARY KEY (o valori di vincolo UNIQUE identici quando non esiste una CHIAVE PRIMARIA).
pgactivelink risolve i conflitti INSERT utilizzando il timestamp dell’host di origine per mantenere la tupla più recente. Puoi sovrascrivere questo comportamento predefinito con il tuo gestore di conflitti personalizzato. Sebbene questo processo non richieda alcuna azione speciale da parte dell’amministratore, tieni presente che pgactivelink scarta una delle operazioni INSERT su tutti i nodi. Non si verifica alcuna unione automatica dei dati, a meno che il gestore personalizzato non la implementi.
pgactivelink può risolvere solo i conflitti che coinvolgono la violazione di un solo vincolo. Se un INSERT viola più vincoli UNIQUE, è necessario implementare ulteriori strategie di risoluzione dei conflitti.
### INSERTs che violano più vincoli UNIQUE
Un INSERT/INSERT conflitto può violare più vincoli UNIQUE, inclusa la CHIAVE PRIMARIA. pgactivelink può gestire solo i conflitti che coinvolgono un singolo vincolo UNIQUE. Quando i conflitti violano più vincoli UNIQUE, il worker di applicazione fallisce e restituisce il seguente errore:
`multiple unique constraints violated by remotely INSERTed tuple.`
Nelle versioni precedenti, questa situazione generava invece un errore di conflitto di unicità divergente.
Per risolvere questi conflitti, è necessario intraprendere un’azione manuale. Esegui operazioni DELETE per le tuple locali in conflitto o operazioni UPDATE per rimuovere i conflitti con la nuova tupla remota. Tieni presente che potresti dover risolvere conflitti tra più tuple. Attualmente, pgactivelink non fornisce alcuna funzionalità integrata per ignorare, scartare o unire le tuple che violano più vincoli unici.
**Nota**
Per ulteriori informazioni, vedi che violano più vincoli UNIQUE. UPDATEs
### Conflitti UPDATE/UPDATE
Questo conflitto si verifica quando due nodi modificano contemporaneamente la stessa tupla senza cambiarne la CHIAVE PRIMARIA. pgactivelink risolve questi conflitti utilizzando la logica o il gestore dei conflitti personalizzato, se definito. last-update-wins Una PRIMARY KEY è essenziale per la corrispondenza delle tuple e la risoluzione dei conflitti. Per quanto riguarda le tabelle senza PRIMARY KEY, pgactivelink rifiuta le operazioni UPDATE restituendo il seguente errore:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### Conflitti UPDATE sulla PRIMARY KEY
pgactive presenta delle limitazioni nella gestione degli aggiornamenti della PRIMARY KEY. Sebbene sia possibile eseguire l'operazione UPDATE su una CHIAVE PRIMARIA, pgactive non può risolvere automaticamente i conflitti utilizzando la logica per queste operazioni. last-update-wins È necessario assicurarsi che gli aggiornamenti della PRIMARY KEY non siano in conflitto con i valori esistenti. Se si verificano conflitti durante gli aggiornamenti della PRIMARY KEY, questi diventano conflitti divergenti, che richiedono l’intervento manuale dell’utente. Per ulteriori informazioni sulla gestione di queste situazioni, consulta [Conflitti divergenti](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### UPDATEs che violano più vincoli UNIQUE
pgactivelink non può applicare la risoluzione dei last-update-wins conflitti quando un UPDATE in entrata viola più vincoli UNIQUE o valori PRIMARY KEY. Questo funzionamento è simile alle operazioni INSERT con violazioni di più vincoli. Tali situazioni creano conflitti divergenti che richiedono l’intervento manuale dell’utente. Per ulteriori informazioni, consulta [Conflitti divergenti](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14).
### Conflitti UPDATE/DELETE
Questi conflitti si verificano quando un nodo è una riga e un altro nodo contemporaneamente UPDATEs . DELETEs In questo caso si verifica un UPDATE/DELETE conflitto durante la riproduzione. La soluzione consiste nell’eliminare qualsiasi operazione UPDATE successiva a un’operazione DELETE, a meno che il gestore dei conflitti personalizzato non specifichi diversamente.
pgactivelink richiede una PRIMARY KEY per abbinare le tuple e risolvere i conflitti. Per quanto riguarda le tabelle senza PRIMARY KEY, pgactivelink rifiuta le operazioni DELETE restituendo il seguente errore:
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**Nota**
pgactivelink non è in grado di distinguere tra e conflitti. UPDATE/DELETE INSERT/UPDATE In entrambi i casi, un’operazione UPDATE influisce su una riga inesistente. A causa della replica asincrona e della mancanza di un ordine di riproduzione tra i nodi, pgactivelink non è in grado di determinare se l’operazione UPDATE si riferisce a una nuova riga (operazione INSERT non ancora ricevuta) o a una riga eliminata. In entrambi gli scenari, pgactivelink elimina l’operazione UPDATE.
### Conflitti INSERT/UPDATE
Questo conflitto può verificarsi in ambienti con più nodi. Succede quando INSERTs un nodo una riga, un secondo nodo e un terzo nodo UPDATEs ricevono l'UPDATE prima dell'INSERT originale. Per impostazione predefinita, pgactivelink risolve questi conflitti eliminando l’operazione UPDATE, a meno che il trigger per la gestione dei conflitti personalizzato non specifichi diversamente. Tieni presente che questo metodo di risoluzione può causare incongruenze nei dati tra i nodi. Per ulteriori informazioni su scenari simili e su come gestirli, consulta [Conflitti UPDATE/DELETE](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7).
### Conflitti DELETE/DELETE
Questo conflitto si verifica quando due nodi diversi eliminano contemporaneamente la stessa tupla. pgactivelink considera questi conflitti innocui, perché entrambe le operazioni DELETE hanno lo stesso risultato finale. In questo scenario, pgactivelink ignora in modo sicuro una delle operazioni DELETE senza influire sulla coerenza dei dati.
### Conflitti con vincoli di chiave esterna
I vincoli FOREIGN KEY possono causare conflitti quando si applicano transazioni remote a dati locali esistenti. Questi conflitti si verificano, in genere, quando le transazioni vengono applicate in una sequenza diversa rispetto al loro ordine logico sui nodi di origine.
Per impostazione predefinita, pgactive applica le modifiche con session\$1replication\$1role come `replica`, che ignora i controlli delle chiavi esterne durante la replica. Nelle configurazioni in modalità attivo-attivo, questo può portare a violazioni delle chiavi esterne. La maggior parte delle violazioni è temporanea e si risolve una volta ripristinata la replica. Tuttavia, possono verificarsi chiavi esterne non valide perché pgactive non supporta il blocco delle righe tra nodi.
Questo comportamento è inerente ai sistemi in modalità attivo-attivo asincroni con tolleranza della partizione. Ad esempio, il nodo A potrebbe inserire una nuova riga secondaria mentre il nodo B elimina contemporaneamente la riga principale. Il sistema non può impedire questo tipo di modifica simultanea tra i nodi.
Per ridurre al minimo i conflitti tra chiavi esterne, è consigliabile:
+ Limitare le relazioni con chiave esterna a entità strettamente correlate.
+ Modificare le entità correlate da un singolo nodo, quando possibile.
+ Scegliere entità che raramente richiedono modifiche.
+ Implementare il controllo della concorrenza a livello di applicazione per le modifiche.
### Conflitti con vincoli di esclusione
pgactive link non supporta i vincoli di esclusione e ne limita la creazione.
**Nota**
Se converti un database autonomo esistente in un database pgactivelink, elimina manualmente tutti i vincoli di esclusione.
In un sistema asincrono distribuito, non è possibile garantire che nessun insieme di righe violi il vincolo. Questo perché tutte le transazioni su nodi diversi sono completamente isolate. I vincoli di esclusione possono portare a deadlock della riproduzione, che le impediscono di passare da un nodo all’altro a causa delle violazioni dei vincoli di esclusione.
Se forzi pgactive Link a creare un vincolo di esclusione o se non elimini quelli esistenti durante la conversione di un database autonomo in pgactive Link, è probabile che la replica si interrompa. Per ripristinare l’avanzamento della replica, rimuovi o modifica le tuple locali in conflitto con una tupla remota in entrata, in modo da poter applicare la transazione remota.
### Conflitti di dati globali
Quando utilizzi pgactivelink, possono verificarsi conflitti se i nodi hanno dati globali diversi a livello di sistema PostgreSQL, ad esempio i ruoli. Questi conflitti possono determinare il successo e il commit delle operazioni, soprattutto quelle di tipo DDL, su un nodo, impedendone tuttavia l’applicazione sugli altri nodi.
Se un utente esiste su un nodo ma non su un altro, possono verificarsi problemi di replica:
+ Su Node1 è presente un utente denominato `fred`, che risulta però inesistente su Node2
+ Quando `fred` crea una tabella su Node1, questa viene replicata con `fred` come nome di proprietario
+ Quando questo comando DDL viene applicato a Node2, l’esito è negativo, perché l’utente `fred` non esiste
+ Questo errore genera un’operazione ERROR nei log PostgreSQL su Node2 e incrementa il conteggio di `pgactive.pgactive_stats.nr_rollbacks`
**Risoluzione:** creazione dell’utente `fred` su Node2. L’utente non necessita di autorizzazioni identiche, ma deve esistere su entrambi i nodi.
Se una tabella esiste su un nodo ma non su un altro, le operazioni di modifica dei dati non riusciranno:
+ In Node1 è presente una tabella denominata `foo` che risulta inesistente in Node2
+ Qualsiasi operazione DML sulla tabella `foo` su Node1 avrà esito negativo se replicata su Node2
**Risoluzione:** creazione della tabella `foo` su Node2 con la stessa struttura.
**Nota**
pgactivelink attualmente non replica i comandi CREATE USER o le operazioni DDL. La replica DDL verrà introdotta in versioni future.
### Conflitti di blocco e interruzioni per deadlock
Poiché funzionano come normali sessioni utente, i processi di applicazione di pgactive seguono le regole standard di blocco delle righe e delle tabelle. È quindi possibile che i processi di applicazione di pgactivelink restino bloccati dalle transazioni degli utenti o da altri processi di applicazione.
I seguenti tipi di blocchi possono influire sui processi di applicazione:
+ Blocco esplicito a livello di tabella (LOCK TABLE...) da parte delle sessioni utente
+ Blocco esplicito a livello di riga (SELECT... FOR UPDATE/FOR SHARE) per sessioni utente
+ Blocco da chiavi esterne
+ Blocco implicito dovuto alla riga UPDATEs o DELETEs all'attività locale o applicato da altri server INSERTs
I deadlock possono verificarsi tra:
+ Un processo di applicazione di pgactivelink e una transazione utente
+ Due processi di applicazione
Quando si verifica un deadlock, il rilevatore di deadlock di PostgreSQL interrompe una delle transazioni che causa problemi. Se il processo del worker di applicazione di pgactivelink viene terminato, esegue automaticamente un nuovo tentativo che, in genere, ha esito positivo.
**Nota**
Questi problemi sono temporanei e di norma non richiedono l’intervento dell’amministratore. Se un processo di applicazione viene bloccato per un periodo prolungato a causa del blocco di una sessione utente inattiva, è possibile interrompere tale sessione per riprendere la replica. Questa situazione è simile a quando un utente mantiene un blocco prolungato che influisce su un’altra sessione utente.
Per identificare i ritardi di riproduzione legati ai blocchi, abilita la funzionalità `log_lock_waits` in PostgreSQL.
### Conflitti divergenti
I conflitti divergenti si verificano quando i dati che dovrebbero essere identici tra i nodi differiscono inaspettatamente. Questi conflitti non dovrebbero verificarsi, ma nell’implementazione attuale non è possibile evitarli tutti in modo affidabile.
**Nota**
La modifica della PRIMARY KEY di una riga può causare conflitti divergenti se un altro nodo cambia la chiave della stessa riga prima che tutti i nodi elaborino la modifica. Evita di modificare le chiavi primarie o limita le modifiche a un nodo designato. Per ulteriori informazioni, consulta [Conflitti UPDATE sulla PRIMARY KEY](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5).
I conflitti divergenti che coinvolgono i dati delle righe richiedono, in genere, l’intervento dell’amministratore. Per risolvere tali conflitti, è necessario modificare manualmente i dati su un nodo in modo che corrispondano a quelli di un altro, disabilitando temporaneamente la replica ricorrendo a `pgactive.pgactive_do_not_replicate`. Questi conflitti non dovrebbero verificarsi quando si utilizza pgactive come prescritto e si evitano impostazioni o funzioni contrassegnate come non sicure.
In qualità di amministratore, devi risolvere questi conflitti manualmente. A seconda del tipo di conflitto, è necessario utilizzare opzioni avanzate come `pgactive.pgactive_do_not_replicate`. Utilizza queste opzioni con cautela, poiché un uso improprio può peggiorare la situazione. A causa della varietà dei possibili conflitti, non possiamo fornire istruzioni universalmente valide per la risoluzione.
I conflitti divergenti si verificano quando i dati che dovrebbero essere identici tra i nodi differiscono inaspettatamente. Questi conflitti non dovrebbero verificarsi, ma nell’implementazione attuale non è possibile evitarli tutti in modo affidabile.
## Come evitare o tollerare i conflitti
Nella maggior parte dei casi, per evitare conflitti è possibile utilizzare un design appropriato dell’applicazione o rendere l’applicazione tollerante nei confronti dei conflitti.
I conflitti si verificano solo quando operazioni simultanee avvengono su più nodi. Per evitare conflitti:
+ Scrivi su un solo nodo
+ Scrivi su sottoinsiemi di database indipendenti su ogni nodo (ad esempio, assegna a ogni nodo uno schema separato)
Per i conflitti INSERT/INSERT, utilizza le sequenze Global che prevengono completamente i conflitti.
Se i conflitti non sono accettabili per il tuo caso d’uso, prendi in considerazione l’implementazione del blocco distribuito a livello di applicazione. Spesso, l’approccio migliore è progettare l’applicazione in modo che funzioni con i meccanismi di risoluzione dei conflitti di pgactive piuttosto che cercare di prevenire tutti i conflitti. Per ulteriori informazioni, consulta [Tipi di conflitti](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes).
## Registrazione di log dei conflitti
pgactivelink registra gli incidenti di conflitto nella tabella `pgactive.pgactive_conflict_history` per aiutarti a diagnosticare e gestire i conflitti in modalità attivo-attivo. La registrazione di log dei conflitti in questa tabella si verifica solo se `pgactive.log_conflicts_to_table` è impostato su true. L’estensione pgactive registra i conflitti anche nel file di log di PostgreSQL quando log\$1min\$1messages è impostato su `LOG` o `lower`, indipendentemente dall’impostazione `pgactive.log_conflicts_to_table`.
Utilizza la tabella della cronologia dei conflitti per:
+ Misurare la frequenza con cui l’applicazione crea conflitti
+ Identificare dove si verificano i conflitti
+ Migliorare l’applicazione per ridurre i tassi di conflitto
+ Rilevare i casi in cui la risoluzione dei conflitti non produce i risultati desiderati
+ Stabilire dove è necessario utilizzare i trigger per la gestione dei conflitti definiti dall’utente o modificare la progettazione delle applicazioni
Per i conflitti di riga, puoi facoltativamente registrare i valori di riga. Questa operazione è controllata dall’impostazione `pgactive.log_conflicts_to_table`. Note:
+ Questa è un’opzione globale per l’intero database
+ Non esiste un controllo per tabella sulla registrazione di log dei valori di riga
+ Ai numeri di campo, agli elementi dell’array o alla lunghezza dei campi non viene applicato alcun limite
+ L’attivazione di questa funzionalità potrebbe non essere consigliabile se si lavora con righe da più megabyte che potrebbero causare conflitti
Poiché la tabella della cronologia dei conflitti contiene i dati di ogni tabella del database (ognuna con schemi potenzialmente diversi), i valori delle righe registrati vengono archiviati come campi JSON. Il file JSON viene creato utilizzando `row_to_json`, in modo simile a una chiamata diretta da SQL. PostgreSQL non fornisce `json_to_row` una funzione, quindi avrai bisogno di codice specifico per la tabella (PL/pgSQL, PL/Python, PL/Perlin, ecc.) per ricostruire una tupla di tipo composito dal JSON registrato.
**Nota**
Il supporto dei conflitti definiti dall’utente verrà introdotto come funzionalità di estensione futura.
# Informazioni sullo schema pgactive
Lo schema pgactive gestisce la replica attiva-attiva in RDS per PostgreSQL. Questo schema contiene tabelle che memorizzano le informazioni sullo stato e sulla configurazione della replica.
**Nota**
Lo schema pgactive è in evoluzione ed è soggetto a modifica. Non modificare i dati direttamente in queste tabelle.
Le tabelle chiave dello schema pgactive includono:
+ `pgactive_nodes`: memorizza le informazioni sui nodi nel gruppo di replica attiva-attiva.
+ `pgactive_connections`: memorizza i dettagli di connessione per ogni nodo.
## pgactive\$1nodes
Il pgactive\$1nodes memorizza le informazioni sui nodi che partecipano al gruppo di replica attiva-attiva.
| Colonna | Tipo | Collation (Regola di confronto) | Nullable | Default |
| --- | --- | --- | --- | --- |
| node\$1sysid | testo | – | Non null | – |
| node\$1timeline | oid | – | non null | – |
| node\$1dboid | oid | – | non null | – |
| node\$1status | char | – | non null | – |
| node\$1name | testo | – | non null | – |
| node\$1dsn | testo | – | non null | – |
| node\$1init\$1from\$1dsn | testo | – | non null | – |
| node\$1read\$1only | booleano | – | – | false |
| node\$1seq\$1id | smallint | – | non null | – |
**node\$1sysid**
ID univoco per un nodo, generato durante `pgactive_create_group` o `pgactive_join_group`
**node\$1status**
Disponibilità del nodo:
+ **b** - beginning setup (avvio della configurazione)
+ **i** - initializing (inizializzazione)
+ **c** - catchup (recupero)
+ **o** - creating outbound slots (creazione di slot in uscita)
+ **r** - ready (pronto)
+ **k** - killed (terminato)
Questa colonna non indica se un nodo è connesso o disconnesso.
**node\$1name**
Nome del nodo univoco fornito dall’utente.
**node\$1dsn**
Stringa di connessione o nome della mappatura utente
**node\$1init\$1from\$1dsn**
DSN da cui è stato creato questo nodo.
## pgactive\$1connection
Il pgactive\$1connections memorizza i dettagli di connessione per ogni nodo.
| Colonna | Tipo | Collation (Regola di confronto) | Nullable | Default |
| --- | --- | --- | --- | --- |
| conn\$1sysid | testo | nessuno | non null | nessuno |
| conn\$1timeline | oid | nessuno | non null | nessuno |
| conn\$1dboid | oid | nessuno | non null | nessuno |
| conn\$1dsn | testo | nessuno | non null | nessuno |
| conn\$1apply\$1delay | intero | nessuno | nessuno | nessuno |
| conn\$1replication\$1sets | testo | nessuno | nessuno | nessuno |
conn\$1sysid
Identificatore del nodo per il nodo a cui si riferisce questa voce.
conn\$1dsn
Uguale a pgactive.pgactive\$1nodes `node_dsn`.
conn\$1apply\$1delay
Se impostato, mostra i millisecondi di attesa prima di applicare ogni transazione dal nodo remoto. Principalmente per il debug. Se null, si applica l’impostazione predefinita globale.
## Utilizzo delle dei set di replica
I set di replica determinano quali tabelle includere o escludere dalle operazioni di replica. Per impostazione predefinita, tutte le tabelle vengono replicate, a meno che non venga specificato diversamente, utilizzando le seguenti funzioni:
+ `pgactive_exclude_table_replication_set()`: esclude le tabelle specificate dalla replica
+ `pgactive_include_table_replication_set()`: include le tabelle specificate nella replica
**Nota**
Prima di configurare i set di replica, valuta quanto segue:
È possibile configurare l’inclusione o l’esclusione delle tabelle solo dopo aver eseguito `pgactive_create_group()`, ma prima di `pgactive_join_group()`.
Dopo aver utilizzato `pgactive_exclude_table_replication_set()`, non è possibile utilizzare `pgactive_include_table_replication_set()`.
Dopo aver utilizzato `pgactive_include_table_replication_set()`, non è possibile utilizzare `pgactive_exclude_table_replication_set()`.
Il sistema gestisce le tabelle appena create in modo diverso in base alla configurazione iniziale:
+ Se hai escluso le tabelle: tutte le nuove tabelle create dopo `pgactive_join_group()` vengono automaticamente incluse nella replica
+ Se sono state incluse tabelle: tutte le nuove tabelle create dopo `pgactive_join_group()` vengono automaticamente escluse dalla replica.
Per visualizzare la configurazione del set di repliche per una tabella specifica, utilizza la funzione `pgactive.pgactive_get_table_replication_sets()`.
# Informazioni di riferimento sulle funzioni pgactive
Di seguito è riportato un elenco di funzioni pgactive con i relativi parametri, valori restituiti e note pratiche per facilitarne l’utilizzo efficace:
## get\$1last\$1applied\$1xact\$1info
Recupera le informazioni sull’ultima transazione applicata per un nodo specificato.
**Argomenti**
+ sysid (text) – OID della timeline
+ dboid (OID)
**Tipo restituito**
Registra quanto segue:
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (timestamp con fuso orario)
+ last\$1applied\$1xact\$1at (timestamp con fuso orario)
**Note per l'utilizzo**
Utilizza questa funzione per recuperare le informazioni sull’ultima transazione applicata per un nodo specificato.
## pgactive\$1apply\$1pause
Sospende il processo di applicazione della replica.
**Argomenti**
Nessuno
**Tipo restituito**
booleano
**Note per l'utilizzo**
Chiama questa funzione per sospendere il processo di applicazione della replica.
## pgactive\$1apply\$1resume
Riprende il processo di applicazione della replica.
**Argomenti**
Nessuno
**Tipo restituito**
void
**Note per l'utilizzo**
Chiama questa funzione per riprendere il processo di applicazione della replica.
## pgactive\$1is\$1apply\$1paused
Verifica se l’applicazione della replica è attualmente sospesa.
**Argomenti**
Nessuno
**Tipo restituito**
booleano
**Note per l'utilizzo**
Utilizza questa funzione per verificare se l’applicazione della replica è attualmente sospesa.
## pgactive\$1create\$1group
Crea un gruppo pgactive convertendo un database autonomo nel nodo iniziale.
**Argomenti**
+ node\$1name (text)
+ node\$1dsn (text)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**Tipo restituito**
void
**Note per l'utilizzo**
Crea un gruppo pgactive convertendo un database autonomo nel nodo iniziale. La funzione esegue controlli di integrità prima di trasformare il nodo in un nodo pgactive. Prima di utilizzare questa funzione, assicurati che il cluster PostgreSQL abbia una quantità di `max_worker_processes` sufficiente per supportare i processi worker in background.
## pgactive\$1detach\$1nodes
Rimuove i nodi specificati dal gruppo pgactive.
**Argomenti**
+ p\$1nodes (text[])
**Tipo restituito**
void
**Note per l'utilizzo**
Utilizza questa funzione per rimuovere i nodi specificati dal gruppo pgactive.
## pgactive\$1exclude\$1table\$1replication\$1set
Esclude una tabella specifica dalla replica.
**Argomenti**
+ p\$1relation (regclass)
**Tipo restituito**
void
**Note per l'utilizzo**
Utilizza questa funzione per escludere una tabella specifica dalla replica.
## pgactive\$1get\$1replication\$1lag\$1info
Recupera informazioni dettagliate sul ritardo di replica, inclusi i dettagli dei nodi, lo stato WAL e i valori LSN.
**Argomenti**
Nessuno
**Tipo restituito**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Dimensione approssimativa di WAL in byte da decodificare sul nodo mittente - pending\$1wal\$1to\$1apply bigint - Dimensione approssimativa di WAL in byte da applicare sul nodo ricevente - 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
**Note per l'utilizzo**
Chiama questa funzione per recuperare le informazioni sul ritardo di replica, inclusi i dettagli dei nodi, lo stato WAL e i valori LSN.
## pgactive\$1get\$1stats
Recupera le statistiche di replica pgactive.
**Argomenti**
Nessuno
**Tipo restituito**
SETOF record - rep\$1node\$1id id - 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
**Note per l'utilizzo**
Utilizza questa funzione per recuperare le statistiche di replica pgactive.
## pgactive\$1get\$1table\$1replication\$1sets
Ottiene la configurazione del set di replica per una relazione specifica.
**Argomenti**
+ relation (regclass)
**Tipo restituito**
Record SETOF
**Note per l'utilizzo**
Chiama questa funzione per ottenere la configurazione del set di replica per una relazione specifica.
## pgactive\$1include\$1table\$1replication\$1set
Include una tabella specifica nella replica.
**Argomenti**
+ p\$1relation (regclass)
**Tipo restituito**
void
**Note per l'utilizzo**
Utilizza questa funzione per includere una tabella specifica nella replica.
## pgactive\$1join\$1group
Aggiunge un nodo a un gruppo pgactive esistente.
**Argomenti**
+ node\$1name (text)
+ node\$1dsn (text)
+ join\$1using\$1dsn (text)
+ apply\$1delay (integer, opzionale)
+ replication\$1sets (text[], valore predefinito: ['default'])
+ bypass\$1collation\$1check (boolean, valore predefinito: false)
+ bypass\$1node\$1identifier\$1creation (boolean, valore predefinito: false)
+ bypass\$1user\$1tables\$1check (boolean, valore predefinito: false)
**Tipo restituito**
void
**Note per l'utilizzo**
Chiama questa funzione per aggiungere un nodo a un gruppo pgactive esistente. Assicurati che il cluster PostgreSQL abbia max\$1worker\$1processes sufficienti per i processi worker in background pgactive.
## pgactive\$1remove
Rimuove tutti i componenti pgactive dal nodo locale.
**Argomenti**
+ force (boolean, valore predefinito: false)
**Tipo restituito**
void
**Note per l'utilizzo**
Chiama questa funzione per rimuovere tutti i componenti pgactive dal nodo locale.
## pgactive\$1snowflake\$1id\$1nextval
Genera valori di sequenza univoci specifici del nodo.
**Argomenti**
+ regclass
**Tipo restituito**
bigint
**Note per l'utilizzo**
Utilizza questa funzione per generare valori di sequenza univoci specifici del nodo.
## pgactive\$1update\$1node\$1conninfo
Aggiorna le informazioni di connessione per un nodo pgactive.
**Argomenti**
+ node\$1name\$1to\$1update (text)
+ node\$1dsn\$1to\$1update (text)
**Tipo restituito**
void
**Note per l'utilizzo**
Utilizza questa funzione per aggiornare le informazioni di connessione per un nodo pgactive.
## pgactive\$1wait\$1for\$1node\$1ready
Monitora lo stato di avanzamento delle operazioni di creazione o unione dei gruppi.
**Argomenti**
+ timeout (integer, valore predefinito: 0)
+ progress\$1interval (integer, valore predefinito: 60)
**Tipo restituito**
void
**Note per l'utilizzo**
Chiama questa funzione per monitorare l’avanzamento delle operazioni di creazione o unione dei gruppi.
# Gestione dei conflitti nella replica active-active
L'estensione `pgactive` funziona per database e non per cluster. Ogni istanza database che utilizza `pgactive` è un'istanza indipendente e può accettare modifiche ai dati da qualsiasi origine. Quando viene inviata una modifica a un'istanza database, PostgreSQL la esegue localmente e quindi utilizza `pgactive` per replicare la modifica in modo asincrono su altre istanze database. Quando due istanze database PostgreSQL aggiornano lo stesso record quasi contemporaneamente, può verificarsi un conflitto.
L'estensione `pgactive` fornisce meccanismi per il rilevamento dei conflitti e la risoluzione automatica. Tiene traccia del timestamp in cui è stata effettuata la transazione su entrambe le istanze database e applica automaticamente la modifica con il timestamp più recente. L'estensione `pgactive` registra anche quando si verifica un conflitto nella tabella `pgactive.pgactive_conflict_history`.
`pgactive.pgactive_conflict_history` continuerà a crescere. Potresti voler definire una policy di eliminazione. A tal fine, puoi cancellare alcuni record su base regolare o definire uno schema di partizionamento per questa relazione (e successivamente scollegare, rimuovere e troncare le partizioni di interesse). Per implementare la policy di eliminazione su base regolare, un’opzione è utilizzare l’estensione `pg_cron`. Consulta le seguenti informazioni di un esempio per la tabella della cronologia `pg_cron`, [Pianificazione della manutenzione con l’estensione PostgreSQL pg\$1cron](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html).
# Gestione delle sequenze nella replica active-active
Un'istanza database RDS per PostgreSQL con l'estensione `pgactive` utilizza due diversi meccanismi di sequenza per generare valori univoci.
**Sequenze globali**
Per utilizzare una sequenza globale, crea una sequenza locale con l'istruzione `CREATE SEQUENCE`. Utilizza `pgactive.pgactive_snowflake_id_nextval(seqname)` invece di `usingnextval(seqname)` per ottenere il valore univoco successivo della sequenza.
L'esempio seguente crea una sequenza globale:
```
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');
```
**Sequenze partizionate**
Nelle sequenze suddivise o partizionate, viene utilizzata una normale sequenza PostgreSQL su ciascun nodo. Ogni sequenza incrementa della stessa quantità e inizia con offset diversi. Ad esempio, con il passaggio 100, il nodo 1 genera una sequenza come 101, 201, 301 e così via e il nodo 2 genera una sequenza come 102, 202, 302 e così via. Questo schema funziona bene anche se i nodi non possono comunicare per periodi prolungati, ma richiede che il progettista specifichi un numero massimo di nodi al momento di stabilire lo schema e richiede una configurazione per nodo. Gli errori possono facilmente portare alla sovrapposizione di sequenze.
È relativamente semplice configurare questo approccio con `pgactive` creando la sequenza desiderata su un nodo nel modo seguente:
```
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');
```
Quindi richiama `setval` su ogni nodo per assegnare un valore iniziale di offset diverso nel modo seguente.
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```