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à.
# Replica con Amazon Aurora PostgreSQL
Di seguito sono riportate le informazioni sulla replica con Amazon Aurora PostgreSQL, incluso il monitoraggio e l’uso della replica logica.
**Topics**
+ [Utilizzo delle repliche di Aurora](#AuroraPostgreSQL.Replication.Replicas)
+ [Miglioramento della disponibilità di lettura delle repliche Aurora](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Monitoraggio della replica Aurora PostgreSQL.](#AuroraPostgreSQL.Replication.Monitoring)
+ [Panoramica della replica logica di PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Configurazione della replica logica per il cluster database Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Disattivazione della replica logica](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Monitoraggio della cache di scrittura e degli slot logici per la replica logica di Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Esempio: Utilizzo della replica logica di PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Esempio: replica logica con Aurora PostgreSQL e AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configurazione dell'autenticazione IAM per le connessioni di replica logica](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Utilizzo delle repliche di Aurora
Le *repliche Aurora* sono endpoint indipendenti in un cluster database Aurora, utilizzati specialmente per operazioni di dimensionamento della lettura e maggiore disponibilità. Un cluster Aurora DB può includere fino a 15 repliche Aurora situate nelle zone di disponibilità della regione del cluster Aurora DB. AWS
Il volume del cluster DB si compone di più copie dei dati per il cluster DB. Tuttavia, i dati nel volume del cluster sono rappresentati come singolo volume logico all'istanza primaria di scrittura e alle repliche di Aurora nel cluster di database. Per ulteriori informazioni sulle repliche di Aurora, consulta [Repliche di Aurora](Aurora.Replication.md#Aurora.Replication.Replicas).
Le repliche di Aurora funzionano bene per il dimensionamento della lettura perché sono dedicate completamente a operazioni di lettura nel volume del cluster. L’istanza database di scrittura gestisce le operazioni di scrittura. Il volume del cluster è condiviso tra tutte le istanze del cluster di database Aurora PostgreSQL. Di conseguenza, non occorre fare altro per replicare una copia dei dati per ciascuna replica Aurora.
Con Aurora PostgreSQL, quando una replica Aurora viene eliminata, l'endpoint dell'istanza viene rimosso immediatamente e la replica Aurora viene rimossa dall'endpoint di lettura. Se vi sono istruzioni in esecuzione nella replica Aurora da eliminare, si ha un periodo di tolleranza di tre minuti. Le istruzioni esistenti possono finire correttamente durante un periodo di tolleranza. Quando finisce il periodo di tolleranza, la replica Aurora viene chiusa ed eliminata.
I cluster Aurora PostgreSQL DB supportano le repliche Aurora in diverse regioni, utilizzando il database globale Aurora. AWS Per ulteriori informazioni, consulta [Utilizzo di Database globale Amazon Aurora](aurora-global-database.md).
**Nota**
Se si utilizza la funzionalità della disponibilità di lettura e si desidera riavviare le repliche Aurora nel cluster di database, è necessario eseguire questa operazione manualmente. Per i cluster database creati prima di questa funzionalità, il riavvio dell'istanza database di scrittura comporta il riavvio automatico delle repliche Aurora. Il riavvio automatico ristabilisce un punto di ingresso che garantisce la coerenza all'interno del cluster DB. read/write
## Miglioramento della disponibilità di lettura delle repliche Aurora
Aurora PostgreSQL migliora la disponibilità di lettura nel cluster database soddisfacendo continuamente le richieste di lettura quando l'istanza database di scrittura si riavvia o quando la replica Aurora non è in grado di gestire il traffico di scrittura.
La funzionalità della disponibilità di lettura è disponibile per impostazione predefinita nelle seguenti versioni di Aurora PostgreSQL:
+ 16.1 e tutte le versioni successive
+ 15.2 o versioni successive alla 15
+ 14.7 o versioni successive alla 14
+ 13.10 o versioni successive alla 13
+ 12.14 e versioni successive alla 12
La funzionalità della disponibilità di lettura è supportata dal database globale Aurora nelle seguenti versioni:
+ 16.1 e tutte le versioni successive
+ 15.4 e versioni successive alla 15
+ 14.9 e versioni successive alla 14
+ 13.12 o versioni successive alla 13
+ 12.16 e versioni successive alla 12
Per utilizzare la funzionalità della disponibilità di lettura per un cluster database creato in una di queste versioni prima del lancio, riavviare l'istanza di scrittura del cluster database.
Quando vengono modificati i parametri statici del cluster database Aurora PostgreSQL, è necessario riavviare l'istanza di scrittura per rendere effettive le modifiche apportate ai parametri. Ad esempio, è necessario riavviare l'istanza di scrittura quando si imposta il valore di `shared_buffers`. Con la funzionalità della disponibilità di lettura delle repliche Aurora, il cluster di database mantiene la disponibilità migliorata, il che riduce l’impatto al riavvio dell’istanza di scrittura. Le istanze di lettura non si riavviano e continuano a rispondere alle richieste di lettura. Per applicare modifiche statiche ai parametri, riavviare ogni singola istanza di lettura.
Una replica Aurora di un cluster database Aurora PostgreSQL è in grado di ripristinare gli errori di replica, come riavvii dell'istanza di scrittura, failover, replica lenta e problemi di rete, ripristinando rapidamente lo stato del database in memoria dopo la riconnessione all'istanza di scrittura. Questo approccio consente alle istanze delle repliche Aurora di raggiungere la coerenza con gli ultimi aggiornamenti dell'archiviazione mentre il database client è ancora disponibile.
Le transazioni in corso che sono in conflitto con il ripristino della replica potrebbero ricevere un errore, ma il client può provare a rieseguire queste transazioni, dopo che le istanze di lettura hanno raggiunto i livelli di prestazioni dell'istanza di scrittura.
### Monitoraggio delle repliche Aurora
È possibile monitorare le repliche Aurora durante il ripristino dopo una disconnessione dell'istanza di scrittura. Utilizzare le metriche riportate di seguito per verificare le informazioni più recenti sull'istanza di lettura e per tenere traccia delle transazioni di sola lettura in corso.
+ La `aurora_replica_status` funzione viene aggiornata per restituire la maggior parte delle up-to-date informazioni per l'istanza del lettore quando è ancora connessa. Il timestamp dell'ultimo aggiornamento in `aurora_replica_status` è sempre vuoto per la riga corrispondente all'istanza database su cui viene eseguita la query. Ciò indica che l'istanza di lettura include i dati più recenti.
+ Quando la replica Aurora si disconnette dall'istanza di scrittura e si riconnette, viene emesso il seguente evento del database:
`Read replica has been disconnected from the writer instance and reconnected.`
+ Quando una query di sola lettura viene annullata a causa di un conflitto di ripristino, è possibile che venga visualizzato il seguente messaggio di errore una o più volte nel log degli errori del database:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitazioni
Le seguenti limitazioni sono valide per la repliche Aurora con la funzionalità della disponibilità di lettura:
+ Le repliche Aurora del cluster di database secondario possono riavviarsi se i dati non possono essere trasmessi dall’istanza di scrittura durante il ripristino della replica.
+ Le repliche Aurora non supportano il ripristino delle repliche online se una replica è già in corso e pertanto questa verrà riavviata.
+ Le repliche Aurora verranno riavviate quando l'istanza database si avvicina al wraparound dell'ID delle transazioni. Per ulteriori informazioni sul wraparound dell'ID delle transazioni, consulta l'argomento relativo alla [risoluzione degli errori di wraparound dell'ID delle transazioni](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ È possibile che le repliche Aurora vengano riavviate quando il processo di replica viene bloccato in determinate circostanze.
## Monitoraggio della replica Aurora PostgreSQL.
Il dimensionamento di lettura e l'alta disponibilità dipendono da un periodo di ritardo minimo. Puoi monitorare il ritardo di una replica Aurora rispetto all'istanza Writer DB del tuo cluster Aurora PostgreSQL DB monitorando la metrica Amazon. CloudWatch `ReplicaLag` Poiché le repliche di Aurora eseguono la lettura dallo stesso volume del cluster dell'istanza database di scrittura, il parametro `ReplicaLag` assume un significato diverso per un cluster di database Aurora PostgreSQL. Il parametro `ReplicaLag` per una replica Aurora indica il ritardo per la cache di pagina della replica Aurora rispetto a quello dell'istanza database di scrittura.
Per ulteriori informazioni sul monitoraggio delle istanze e dei parametri RDS, consulta. CloudWatch [Monitoraggio dei parametri in un cluster di database Amazon Aurora](MonitoringAurora.md)
# Panoramica della replica logica di PostgreSQL con Aurora
Utilizzando la funzionalità di replica logica di PostgreSQL con il cluster database Aurora PostgreSQL, è possibile replicare e sincronizzare singole tabelle anziché l'intera istanza database. La replica logica utilizza un modello di pubblicazione e sottoscrizione per replicare le modifiche da un'origine in uno o più destinatari. Funziona utilizzando i record di modifica del WAL (write-ahead log) PostgreSQL. L'origine, o l'*autore*, invia i dati WAL per le tabelle specificate a uno o più destinatari (*sottoscrittore*), replicando così le modifiche e mantenendo sincronizzata la tabella di un sottoscrittore con la tabella dell'autore. L'insieme di modifiche apportate dall'editore vengono identificate mediante una *pubblicazione*. Gli abbonati ottengono le modifiche creando un *abbonamento* che definisce la connessione al database dell'autore e alle sue pubblicazioni. Uno *slot di replica* è il meccanismo utilizzato in questo schema per tenere traccia dell'avanzamento di una sottoscrizione.
Per i cluster database Aurora PostgreSQL, i record WAL vengono salvati nell'archiviazione Aurora. Il cluster database Aurora PostgreSQL che funge da autore in uno scenario di replica logica legge i dati WAL dall'archiviazione Aurora, li decodifica e li invia al sottoscrittore in modo da poter applicare le modifiche alla tabella su tale istanza. L'autore utilizza un *decodificatore logico* per decodificare i dati per l'uso da parte degli abbonati. Per impostazione predefinita, i cluster database Aurora PostgreSQL utilizzano il plug-in `pgoutput` PostgreSQL nativo per l'invio di dati. Sono disponibili altri decodificatori logici. Ad esempio, Aurora PostgreSQL supporta anche il plug-in `[wal2json](https://github.com/eulerto/wal2json)` che converte i dati WAL in JSON.
A partire dalle versioni 14.5, 13.8, 12.12 e 11.17, Aurora PostgreSQL aumenta il processo di replica logica PostgreSQL con una *cache write-through* per migliorare le prestazioni. I log delle transazioni WAL vengono memorizzati nella cache locale, in un buffer, per ridurre la quantità di I/O su disco, ovvero la lettura dell'archiviazione Aurora durante la decodifica logica. La cache di scrittura viene utilizzata per impostazione predefinita ogni volta che si usa la replica logica per il cluster database Aurora PostgreSQL. Aurora offre diverse funzioni che puoi utilizzare per gestire la cache. Per ulteriori informazioni, consulta [Monitoraggio della cache di scrittura della replica logica di Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
La replica logica è supportata da tutte le versioni di Aurora PostgreSQL attualmente disponibili. Per ulteriori informazioni, consultare [Aggiornamenti di Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) nelle *Note di rilascio di Aurora PostgreSQL*.
La replica logica è supportata da Babelfish per Aurora PostgreSQL a partire dalle seguenti versioni:
+ 15.7 e versioni successive
+ 16.3 e versioni successive
**Nota**
Oltre alla funzionalità di replica logica nativa di PostgreSQL introdotta in PostgreSQL 10, Aurora PostgreSQL supporta anche l'estensione `pglogical`. Per ulteriori informazioni, consulta [Utilizzo di pglogical per sincronizzare i dati tra le istanze](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
Per ulteriori informazioni sulla replica logica PostgreSQL, consultare le sezioni relative alla [replica logica](https://www.postgresql.org/docs/current/logical-replication.html) e ai [concetti di decodifica logica](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) nella documentazione di PostgreSQL.
**Nota**
PostgreSQL 16 ha aggiunto il supporto per la decodifica logica dalle repliche di lettura. Questa funzionalità non è supportata su Aurora PostgreSQL.
# Configurazione della replica logica per il cluster database Aurora PostgreSQL
La configurazione della replica logica richiede privilegi `rds_superuser`. Il cluster database Aurora PostgreSQL deve essere configurato per utilizzare un gruppo di parametri cluster database personalizzati in modo da poter impostare i parametri necessari come descritto nella procedura seguente. Per ulteriori informazioni, consulta [Gruppi di parametri del cluster di database per i cluster di database Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md).
**Per configurare la replica logica PostgreSQL per il cluster database Aurora PostgreSQL**
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 il cluster database Aurora PostgreSQL.
1. Apri la scheda **Configurazione**. Nei dettagli dell'istanza, cercare il collegamento **Gruppo di parametri** con l'opzione **Tipo** impostata su **Gruppo di parametri del cluster DB**.
1. Scegli il collegamento per aprire i parametri personalizzati associati al cluster database Aurora PostgreSQL.
1. Nel campo di ricerca **Parametri**, digita `rds` per trovare il parametro `rds.logical_replication`. Il valore predefinito per questo parametro è `0`, per indicare che è disattivato per impostazione predefinita.
1. Scegli **Modifica parametri** per accedere ai valori delle proprietà, quindi seleziona `1` dal selettore per attivare la funzione. A secondo dell'utilizzo previsto, potrebbe anche essere necessario modificare le impostazioni per i seguenti parametri. Tuttavia, in molti casi, i valori predefiniti sono sufficienti.
+ `max_replication_slots`: imposta questo parametro su un valore almeno uguale al numero totale pianificato di pubblicazioni e sottoscrizioni della replica logica. Se lo utilizzi AWS DMS, questo parametro deve corrispondere almeno alle attività di acquisizione dei dati di modifica pianificate dal cluster, più le pubblicazioni e gli abbonamenti relativi alla replica logica.
+ `max_wal_senders`e `max_logical_replication_workers` — Imposta questi parametri su un valore almeno uguale al numero di slot di replica logica che intendi rendere attivi o al numero di AWS DMS attività attive per l'acquisizione dei dati di modifica. Lasciando inattivo uno slot di replica logica si impedisce al vacuum di rimuovere le tuple obsolete dalle tabelle, pertanto ti consigliamo di monitorare gli slot di replica e rimuovere gli slot inattivi in base alle esigenze.
+ `max_worker_processes`: imposta questo parametro su un valore che sia almeno uguale al totale dei valori `max_logical_replication_workers`, `autovacuum_max_workers` e `max_parallel_workers`. Su classi di istanza database di piccole dimensioni, i processi dell'operatore in background potrebbero influire sui carichi di lavoro delle applicazioni, pertanto monitorare le prestazioni del database se si imposta `max_worker_processes` su un valore più elevato di quello predefinito. (Il valore predefinito è il risultato di `GREATEST(${DBInstanceVCPU*2},8}`, il che significa che, per impostazione predefinita, è 8 o il doppio dell'equivalente CPU della classe di istanza database, a seconda di quale valore è più grande).
**Nota**
È possibile modificare i valori dei parametri in un gruppo di parametri database creato dal cliente, ma non i valori dei parametri in un gruppo di parametri database predefinito.
1. Scegli **Save changes** (Salva modifiche).
1. Riavvia l'istanza di scrittura del cluster database Aurora PostgreSQL in modo da rendere effettiva le modifiche. Nella console Amazon RDS, scegli l'istanza database principale del cluster e seleziona **Riavvia** dal menu **Azioni**.
1. Quando l'istanza è disponibile, puoi verificare che la replica logica sia attivata, come riportato di seguito.
1. Utilizza `psql` per connetterti all'istanza di scrittura del cluster database Aurora PostgreSQL.
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Verifica che la replica logica sia stata abilitata utilizzando il seguente comando.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. Verifica che `wal_level` sia impostato su `logical`.
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
Per un esempio di utilizzo della replica logica per mantenere una tabella di database sincronizzata con le modifiche di un cluster database Aurora PostgreSQL di origine, consultare [Esempio: Utilizzo della replica logica di PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# Disattivazione della replica logica
Dopo aver completato le attività di replica, è necessario interrompere il processo di replica, eliminare gli slot di replica e disattivare la replica logica. Prima di eliminare gli slot, assicurati che non siano più necessari. Gli slot di replica attivi non possono essere eliminati.
**Disattivazione della replica logica**
1. Abbandonare tutti gli slot di replica.
Per abbandonare tutti gli slot di replica, esegui la connessione all'editore ed esegui il seguente comando SQL
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
Gli slot di replica non possono essere attivi quando si esegue questo comando.
1. Modifica il gruppo di parametri cluster database personalizzato associato all'editore come descritto in [Configurazione della replica logica per il cluster database Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md), ma imposta il parametro `rds.logical_replication` su 0
Per ulteriori informazioni sui gruppi di parametri, consulta [Modifica dei parametri in un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Riavvia il cluster database Aurora PostgreSQL per rendere effettivo il parametro `rds.logical_replication`.
# Monitoraggio della cache di scrittura e degli slot logici per la replica logica di Aurora PostgreSQL
Il monitoraggio della cache di scrittura della replica logica e la gestione degli slot logici migliorano le prestazioni del cluster di database Aurora PostgreSQL. Di seguito, sono riportate ulteriori informazioni sulla cache di scrittura e sugli slot logici.
**Topics**
+ [Monitoraggio della cache di scrittura della replica logica di Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Gestione degli slot logici per Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Monitoraggio della cache di scrittura della replica logica di Aurora PostgreSQL
Per impostazione predefinita, le versioni 14.5, 13.8, 12.12 e 11.17 e successive di Aurora PostgreSQL utilizzano una cache write-through per migliorare le prestazioni per la replica logica. Senza la cache write-through, Aurora PostgreSQL utilizza il livello di archiviazione Aurora nell'implementazione del processo di replica logica nativa di PostgreSQL. Lo fa scrivendo i dati WAL nell'archivio e quindi leggendo i dati dall'archivio per decodificarli e inviarli (replicare) alle destinazioni (sottoscrittori). Questo comportamento può causare rallentamenti durante la replica logica per i cluster database Aurora PostgreSQL.
La cache di scrittura riduce al minimo la dipendenza dal livello di archiviazione Aurora. Invece di scrivere e leggere in modo coerente da questo livello, Aurora PostgreSQL utilizza un buffer per memorizzare nella cache il flusso logico WAL da utilizzare durante il processo di replica, riducendo la necessità di accedere al disco. Questo buffer è la cache nativa di PostgreSQL utilizzata dalla replica logica, identificata nei parametri del cluster di database Aurora PostgreSQL come `rds.logical_wal_cache`.
Quando usi la replica logica con il cluster database Aurora PostgreSQL per le versioni che supportano la cache write-through, puoi monitorare la percentuale di riscontri della cache per vedere se funziona per il tuo caso d'uso. Per farlo, connettiti all'istanza di scrittura del cluster database Aurora PostgreSQL utilizzando `psql` e quindi usa la funzione Aurora `aurora_stat_logical_wal_cache`, come mostrato nell'esempio seguente.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
La funzione restituisce un output come il seguente:
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
I valori `last_reset_timestamp` sono stati abbreviati per garantire la leggibilità. Per ulteriori informazioni su questa funzione, consulta [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL fornisce le seguenti due funzioni per il monitoraggio della cache write-through.
+ La funzione `aurora_stat_logical_wal_cache`: per la documentazione di riferimento, consulta [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ La funzione `aurora_stat_reset_wal_cache`: per la documentazione di riferimento, consulta [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
Se si ritiene che la dimensione della cache WAL regolata automaticamente non sia sufficiente per i carichi di lavoro, è possibile modificare il valore di `rds.logical_wal_cache` manualmente. Considera i seguenti aspetti:
+ Quando il parametro `rds.logical_replication` è disabilitato, `rds.logical_wal_cache` è impostato su zero (0).
+ Quando il parametro `rds.logical_replication` è abilitato, `rds.logical_wal_cache` ha il valore predefinito 16 MB.
+ Il parametro `rds.logical_wal_cache` è statico e richiede il riavvio dell’istanza database per rendere effettive le modifiche. Questo parametro è definito in termini di blocchi da 8 KB. Qualsiasi valore positivo inferiore a 32 KB viene considerato come 32 KB. Per ulteriori informazioni su `wal_buffers`, consultare [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) nella documentazione PostgreSQL.
## Gestione degli slot logici per Aurora PostgreSQL
L'attività di streaming viene acquisita nella vista `pg_replication_origin_status`. Per visualizzare il contenuto di questa vista, è possibile utilizzare la funzione `pg_show_replication_origin_status()`, come illustrato di seguito:
```
SELECT * FROM pg_show_replication_origin_status();
```
Puoi ottenere un elenco degli slot logici utilizzando la seguente query SQL.
```
SELECT * FROM pg_replication_slots;
```
Per eliminare uno slot logico, utilizza `pg_drop_replication_slot` con il nome dello slot, come illustrato nel seguente comando.
```
SELECT pg_drop_replication_slot('test_slot');
```
# Esempio: Utilizzo della replica logica di PostgreSQL con Aurora
La seguente procedura mostra come avviare la replica logica tra due cluster database Aurora PostgreSQL. Sia l'editore che il sottoscrittore devono essere configurati per la replica logica, come descritto in [Configurazione della replica logica per il cluster database Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Il cluster database Aurora PostgreSQL, che è l'editore designato, deve inoltre consentire l'accesso allo slot di replica. Per farlo, occorre modificare il gruppo di sicurezza associato al cloud privato virtuale (VPC) del cluster database Aurora PostgreSQL basato sul servizio Amazon VPC. Consentire l'accesso in entrata aggiungendo il gruppo di sicurezza associato al VPC del sottoscrittore al gruppo di sicurezza dell'editore. Per ulteriori informazioni, consultare [Controlla il traffico verso le risorse utilizzando gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon VPC*.
Una volta completati questi passaggi preliminari, puoi usare i comandi PostgreSQL `CREATE PUBLICATION` sull'editore e `CREATE SUBSCRIPTION` sul sottoscrittore, come descritto nella procedura seguente.
**Come avviare il processo di replica logica tra due cluster database Aurora PostgreSQL**
Queste fasi presuppongono che i cluster database Aurora PostgreSQL dispongano di un'istanza di scrittura con un database in cui creare le tabelle di esempio.
1. **Nel cluster database Aurora PostgreSQL dell'editore**
1. Crea una tabella utilizzando la seguente istruzione SQL.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Inserire dati nel database del publisher utilizzando la seguente istruzione SQL.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Verifica che i dati siano presenti nella tabella utilizzando la seguente istruzione SQL.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Crea una pubblicazione per questa tabella utilizzando l'istruzione `CREATE PUBLICATION`, come descritto di seguito.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **Nel cluster database Aurora PostgreSQL del sottoscrittore**
1. Nel sottoscrittore, crea la stessa tabella `LogicalReplicationTest` che hai creato nell'editore, come descritto di seguito.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Verifica che questa tabella sia vuota.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Crea una sottoscrizione per ottenere le modifiche dall'editore. È necessario utilizzare i seguenti dettagli sul cluster database Aurora PostgreSQL dell'editore.
+ **host**: l’istanza database di scrittura del cluster database Aurora PostgreSQL dell'editore.
+ **porta**: la porta di ascolto dell’istanza database di scrittura. L'impostazione predefinita per PostgreSQL è l5432.
+ **dbname**: il nome del database.
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**Nota**
Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza.
Successivamente alla creazione della sottoscrizione, dal lato del publisher viene creato uno slot di replica logica.
1. Per verificare che nell’esempio i dati iniziali vengono replicati nel sottoscrittore, utilizzare la seguente istruzione SQL nel database del sottoscrittore.
```
SELECT count(*) FROM LogicalReplicationTest;
```
Ogni successiva modifica al publisher viene replicata nel sottoscrittore.
La replica logica influisce sulle prestazioni. Ti consigliamo di disattivare la replica logica al termine delle attività di replica.
# Esempio: replica logica con Aurora PostgreSQL e AWS Database Migration Service
È possibile utilizzare AWS Database Migration Service (AWS DMS) per replicare un database o una parte di un database. AWS DMS Usalo per migrare i dati da un database Aurora PostgreSQL a un altro database open source o commerciale. [Per ulteriori informazioni in merito AWS DMS, consulta la Guida per l'utente.AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/)
L'esempio seguente mostra come impostare la replica logica da un database Aurora PostgreSQL come editore e quindi utilizzarla per la migrazione. AWS DMS L’esempio utilizza lo stesso publisher e lo stesso sottoscrittore creati in [Esempio: Utilizzo della replica logica di PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
Per configurare la replica logica con AWS DMS, hai bisogno dei dettagli sul tuo editore e abbonato da Amazon RDS. In particolare, occorrono i dettagli sull’istanza database di scrittura del publisher e sull’istanza database del sottoscrittore.
Ottenere le seguenti informazioni per l’istanza database di scrittura del publisher:
+ L’identificatore del cloud privato virtuale (virtual private cloud, VPC)
+ Il gruppo di sottoreti
+ La zona di disponibilità (Availability Zone, AZ)
+ Il gruppo di sicurezza VPC
+ L’ID dell’istanza database
Ottenere le seguenti informazioni per l’istanza database del sottoscrittore:
+ L’ID dell’istanza database
+ Il motore di origine
**Da utilizzare AWS DMS per la replica logica con Aurora PostgreSQL**
1. Preparare il database dell'editore con cui lavorare. AWS DMS
Per far ciò, i database PostgreSQL 10.x e successivi richiedono l'applicazione di funzioni wrapper AWS DMS al database del publisher. Per i dettagli su questa fase e sulle successive, consulta le istruzioni riportate in [Utilizzo di PostgreSQL versione 10.x e successive come origine per AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) nella *Guida per l’utente di AWS Database Migration Service .*
1. Accedi a Console di gestione AWS e apri la AWS DMS console all'indirizzo[https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2). In alto a destra, scegli la stessa AWS regione in cui si trovano l'editore e l'abbonato.
1. Crea un'istanza di AWS DMS replica.
Selezionare valori che siano identici a quelli dell’istanza database di scrittura del publisher. Tali valori includono le seguenti impostazioni:
+ Per **VPC**, selezionare lo stesso VPC dell’istanza database di scrittura.
+ Per **Replication Subnet Group (Gruppo di sottoreti di replica)**, selezionare lo stesso gruppo di sottoreti con gli stessi valori dell’istanza database di scrittura. Creane uno nuovo se necessario.
+ Per **Availability zone** (Zona di disponibilità), selezionare la stessa zona dell’istanza database di scrittura.
+ Per **VPC Security Group (Gruppo di sicurezza VPC)**, selezionare lo stesso gruppo dell’istanza database di scrittura.
1. Crea un AWS DMS endpoint per l'origine.
Specificare il publisher come endpoint di origine utilizzando le seguenti impostazioni:
+ Per **Endpoint type (Tipo di endpoint)**, selezionare **Source endpoint (Endpoint di origine)**.
+ Scegliere **Select RDS DB Instance (Seleziona un’istanza database RDS)**.
+ Per **RDS Instance (Istanza RDS)**, selezionare l’identificatore del database dell’istanza database di scrittura del publisher.
+ In **Source engine (Motore di origine)**, scegliere **postgres (postgres)**.
1. Crea un AWS DMS endpoint per l'obiettivo.
Specificare il publisher come endpoint di destinazione utilizzando le seguenti impostazioni:
+ Per **Endpoint type (Tipo di endpoint)**, scegliere **Target endpoint (Endpoint di destinazione)**.
+ Scegliere **Select RDS DB Instance (Seleziona un’istanza database RDS)**.
+ Per **RDS Instance (Istanza RDS)**, selezionare l’identificatore del database dell’istanza database del sottoscrittore.
+ Selezionare un valore per **Source engine (Motore di origine)**. Ad esempio, se il sottoscrittore è un database RDS PostgreSQL, selezionare **postgres (postgres)**. Se il sottoscrittore è un database Aurora PostgreSQL, scegliere **aurora-postgresql**.
1. Crea un'attività di migrazione AWS DMS del database.
Un’attività di migrazione del database serve a specificare le tabelle del database di cui effettuare la migrazione, a mappare i dati utilizzando lo schema di destinazione e a creare nuove tabelle nel database di destinazione. Utilizzare almeno le seguenti impostazioni per **Task configuration (Configurazione attività)**:
+ Per **Replication instance (Istanza di replica)**, scegliere l'istanza di replica creata in precedenza.
+ Per **Source database endpoint (Endpoint del database di origine)**, selezionare l’origine del publisher creata in precedenza.
+ Per **Target database endpoint (Endpoint del database di destinazione)**, selezionare la destinazione del sottoscrittore creata in precedenza.
I rimanenti dettagli dell'attività dipendono dal progetto di migrazione. *Per ulteriori informazioni sulla specificazione di tutti i dettagli per le attività DMS, consulta [Lavorare con le attività AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) nella Guida per l'AWS Database Migration Service utente.*
Dopo aver AWS DMS creato l'attività, inizia la migrazione dei dati dall'editore al sottoscrittore.
# Configurazione dell'autenticazione IAM per le connessioni di replica logica
A partire dalle versioni 11 e successive di Aurora PostgreSQL, puoi utilizzare l'autenticazione Identity and AWS Access Management (IAM) per le connessioni di replica. Questa funzionalità migliora la sicurezza consentendo di gestire l'accesso al database utilizzando i ruoli IAM anziché le password. Funziona a livello di cluster e segue lo stesso modello di sicurezza dell'autenticazione IAM standard.
L'autenticazione IAM per le connessioni di replica è una funzionalità opzionale. Per abilitarla, imposta il `rds.iam_auth_for_replication` parametro su `1` nel gruppo di parametri del cluster DB. Poiché si tratta di un parametro dinamico, non è necessario riavviare il cluster DB, il che consente di sfruttare l'autenticazione IAM con i carichi di lavoro esistenti senza tempi di inattività. Prima di abilitare questa funzionalità, è necessario soddisfare i requisiti elencati di seguito. [Prerequisiti](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites)
## Prerequisiti
Per utilizzare l'autenticazione IAM per le connessioni di replica, devi soddisfare tutti i seguenti requisiti:
+ Il cluster Aurora PostgreSQL DB deve avere la versione 11 o successiva.
+ Sul cluster Aurora PostgreSQL DB dell'editore:
+ Abilita l'autenticazione del database IAM.
Per ulteriori informazioni, consulta [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Abilita la replica logica impostando il `rds.logical_replication` parametro su`1`.
Per ulteriori informazioni, consulta [Configurazione della replica logica per il cluster database Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Nella replica logica, l'editore è il cluster Aurora PostgreSQL DB di origine che invia i dati ai cluster di abbonati. Per ulteriori informazioni, consulta [Panoramica della replica logica di PostgreSQL con Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**Nota**
Sia l'autenticazione IAM che la replica logica devono essere abilitate sul cluster Aurora PostgreSQL DB dell'editore. Se una delle due non è abilitata, non è possibile utilizzare l'autenticazione IAM per le connessioni di replica.
## Abilitazione dell'autenticazione IAM per le connessioni di replica
Completa i seguenti passaggi per abilitare l'autenticazione IAM per la connessione di replica.
1. Verifica che il cluster Aurora PostgreSQL DB soddisfi tutti i prerequisiti per l'autenticazione IAM con connessioni di replica. Per informazioni dettagliate, vedi [Prerequisiti](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configura il `rds.iam_auth_for_replication` parametro modificando il gruppo di parametri del cluster DB:
+ Imposta il parametro `rds.iam_auth_for_replication` su `1`. Questo parametro dinamico non richiede un riavvio.
1. Connect al database e assegna i ruoli necessari all'utente di replica:
I seguenti comandi SQL garantiscono i ruoli necessari per abilitare l'autenticazione IAM per le connessioni di replica:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Dopo aver completato questi passaggi, l'utente specificato deve utilizzare l'autenticazione IAM per le connessioni di replica.
**Importante**
Quando abiliti la funzionalità, gli utenti con entrambi i `rds_iam` `rds_replication` ruoli devono utilizzare l'autenticazione IAM per le connessioni di replica. Ciò vale sia che i ruoli vengano assegnati direttamente all'utente o ereditati da altri ruoli.
## Disabilitazione dell'autenticazione IAM per le connessioni di replica
Puoi disabilitare l'autenticazione IAM per le connessioni di replica utilizzando uno dei seguenti metodi:
+ Imposta il `rds.iam_auth_for_replication` parametro su `0` nel gruppo di parametri del cluster DB
+ In alternativa, puoi disabilitare una di queste funzionalità sul tuo cluster Aurora PostgreSQL DB:
+ Disabilita la replica logica impostando il parametro su `rds.logical_replication` `0`
+ Disabilita l'autenticazione IAM
Quando disabiliti la funzionalità, le connessioni di replica possono utilizzare le password del database per l'autenticazione, se configurate.
**Nota**
Le connessioni di replica per gli utenti senza il `rds_iam` ruolo possono utilizzare l'autenticazione tramite password anche quando la funzionalità è abilitata.
## Considerazioni e limitazioni
Le seguenti limitazioni e considerazioni si applicano all'utilizzo dell'autenticazione IAM per le connessioni di replica.
+ L'autenticazione IAM per le connessioni di replica è disponibile solo per Aurora PostgreSQL versione 11 e successive.
+ L'editore deve supportare l'autenticazione IAM per le connessioni di replica.
+ Per impostazione predefinita, il token di autenticazione IAM scade dopo 15 minuti. Potrebbe essere necessario aggiornare le connessioni di replica di lunga durata prima della scadenza del token.