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 delle repliche di lettura per Amazon RDS per PostgreSQL
È possibile scalare le letture per le istanze database Amazon RDS per PostgreSQL aggiungendo repliche di lettura alle istanze. Come per altri motori di database Amazon RDS, RDS per PostgreSQL utilizza i meccanismi di replica nativi di PostgreSQL per mantenere aggiornate le repliche di lettura con le modifiche apportate al database di origine. Per informazioni generali sulle repliche di lettura e Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md).
Questa sezione contiene informazioni specifiche sull'utilizzo delle repliche di lettura con RDS per PostgreSQL.
## Limitazioni per le repliche di lettura con PostgreSQL
Di seguito sono elencate le limitazioni per le repliche di lettura PostgreSQL:
+ Le repliche di lettura PostgreSQL sono di sola lettura. Sebbene una replica di lettura non sia un'istanza database scrivibile, è possibile promuoverla a un'istanza database RDS per PostgreSQL autonoma. Tuttavia, il processo non è reversibile.
+ Non è possibile creare una replica di lettura da un'altra replica di lettura se l'istanza database RDS per PostgreSQL esegue una versione di PostgreSQL precedente alla 14.1. RDS per PostgreSQL supporta solo le repliche di lettura a cascata su RDS per PostgreSQL versione 14.1 e versioni successive. Per ulteriori informazioni, consulta [Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Se promuovi una replica di lettura PostgreSQL, questa diventa un'istanza database scrivibile. Smette di ricevere i file WAL (write-ahead log) da un'istanza database di origine e non è più un'istanza di sola lettura. È possibile creare nuove repliche di lettura dall'istanza database promossa come avviene per qualsiasi istanza database RDS per PostgreSQL. Per ulteriori informazioni, consulta [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md).
+ Se si promuove una replica di lettura PostgreSQL dall’interno di una catena di repliche (una serie di repliche di lettura a cascata), tutte le repliche di lettura a valle esistenti continuano a ricevere automaticamente i file WAL dall’istanza promossa. Per ulteriori informazioni, consulta [Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md).
+ Se sull'istanza database di origine non sono in esecuzione transazioni utente, la replica di lettura PostgreSQL associata è caratterizzata da un ritardo di replica fino a cinque minuti. Il ritardo di replica viene calcolato come `currentTime - lastCommitedTransactionTimestamp`, il che significa che quando non viene elaborata alcuna transazione, il valore del ritardo di replica aumenta per un periodo di tempo fino a quando il segmento WAL (write-ahead log) cambia. Per impostazione predefinita, RDS per PostgreSQL cambia il segmento WAL ogni 5 minuti, il che comporta un record di transazione e una riduzione del ritardo segnalato.
+ Non è possibile attivare i backup automatici per le repliche di lettura PostgreSQL per le versioni precedenti alla 14.1 di RDS per PostgreSQL. I backup automatici per le repliche di lettura sono supportati solo per RDS per PostgreSQL 14.1 e versioni successive. Per RDS per PostgreSQL 13 e versioni precedenti, crea uno snapshot da una replica di lettura se si desidera creare un backup da tale snapshot.
+ Point-in-time il ripristino (PITR) non è supportato per le repliche di lettura. È possibile utilizzare ripristino point-in-time (PITR) solo con un'istanza primaria (istanza di scrittura), non con una replica di lettura. Per ulteriori informazioni, consulta [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md).
+ Le repliche di lettura per PostgreSQL versioni 12 e precedenti si riavviano automaticamente durante la finestra di manutenzione di 60-90 giorni per applicare la rotazione delle password. Se la replica perde la connessione all’origine prima del riavvio pianificato, si riavvia comunque per riprendere la replica. Per PostgreSQL versioni 13 e successive, le repliche di lettura potrebbero subire brevi disconnessioni e riconnessioni durante il processo di rotazione delle password.
# Configurazione delle repliche di lettura con PostgreSQL
RDS per PostgreSQL utilizza la replica di streaming nativa PostgreSQL per creare una copia di sola lettura di un'istanza database di origine. Questa istanza database di replica di lettura è una replica fisica creata in modo asincrono dell'istanza database di origine. Viene creata da una speciale connessione che trasmette i dati Write Ahead Log (WAL) dall'istanza database di origine alla replica di lettura. Per ulteriori informazioni, consulta la sezione relativa alla [replica in streaming](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION) nella documentazione di PostgreSQL.
PostgreSQL trasmette in streaming in modo asincrono le modifiche al database a questa connessione sicura man mano che vengono effettuate sull'istanza database di origine. È possibile crittografare le comunicazioni dalle applicazioni client all'istanza database di origine o a qualsiasi replica di lettura impostando il parametro `ssl` su `1`. Per ulteriori informazioni, consulta [Utilizzo del protocollo SSL con un'istanza database PostgreSQL](PostgreSQL.Concepts.General.SSL.md).
PostgreSQL utilizza un ruolo di *replica* per eseguire la replica in streaming. Il ruolo presenta dei privilegi ma non può essere utilizzato per modificare i dati. PostgreSQL utilizza un unico processo per la gestione della replica.
È possibile creare una replica di lettura PostgreSQL senza alcun impatto sulle operazioni o sugli utenti dell'istanza database di origine. Amazon RDS imposta i parametri e le autorizzazioni necessari per l'istanza database di origine e la replica di lettura senza ripercussioni sul servizio. Viene acquisito uno snapshot dell'istanza database di origine e tale snapshot viene utilizzato per creare la replica di lettura. Se si elimina la replica di lettura in un secondo momento, non si verificherà alcuna interruzione.
È possibile creare fino a 15 repliche di lettura da un'istanza database di origine nella stessa regione. A partire da RDS per PostgreSQL 14.1, è anche possibile creare fino a tre livelli di replica di lettura in una catena (cascata) da un'istanza database di origine. Per ulteriori informazioni, consulta [Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md). In ogni caso, l'istanza database di origine deve disporre di backup automatici configurati. A questo scopo, imposta il periodo di conservazione del backup sull'istanza database su un valore diverso da zero. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](USER_ReadRepl.Create.md).
È possibile creare repliche di lettura per l'istanza database RDS per PostgreSQL nella stessa Regione AWS dell'istanza database di origine. Questo processo è noto come replica *nella regione*. È inoltre possibile creare repliche di lettura in un'istanza DB Regioni AWS diversa dall'istanza database di origine. Questo processo è noto come replica *tra regioni*. Per informazioni sull'impostazione delle repliche di lettura tra regioni, consulta [Creazione di una replica di lettura in un altro Regione AWS](USER_ReadRepl.XRgn.md). I vari meccanismi che supportano il processo di replica "in regione" e "tra regioni" variano leggermente a seconda della versione di RDS per PostgreSQL, come spiegato in [Funzionamento della replica in streaming per diverse versioni di RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md).
Per un efficace funzionamento della replica, ciascuna replica di lettura dovrebbe avere la stessa quantità di risorse di calcolo e storage dell'istanza database di origine. Se si dimensiona l'istanza database di origine, verifica di dimensionare anche le repliche di lettura.
Amazon RDS sostituisce qualsiasi parametro incompatibile in una replica di lettura che impedisca l'avvio della replica di lettura. Ad esempio, supponiamo che il valore del parametro `max_connections` sull'istanza database di origine sia superiore a quello sulla replica di lettura. In questo caso, Amazon RDS aggiorna il parametro sulla replica di lettura in modo che il valore coincida con quello sull'istanza database di origine.
Le repliche di lettura RDS per PostgreSQL hanno accesso a database esterni disponibili tramite data FDWs wrapper esterni () sull'istanza DB di origine. Ad esempio, supponiamo che l'istanza database RDS per PostgreSQL stia utilizzando il wrapper `mysql_fdw` per accedere ai dati da RDS per MySQL. In questo caso, anche le repliche di lettura possono accedere a tali dati. Altre opzioni supportate includono, e. FDWs `oracle_fdw` `postgres_fdw` `tds_fdw` Per ulteriori informazioni, consulta [Utilizzo dei wrapper di dati esterni supportati per Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md).
## Utilizzo di repliche di lettura di RDS per PostgreSQL con configurazioni Multi-AZ
È possibile creare una replica di lettura da un’istanza database Single-AZ o Multi-AZ. Puoi usare implementazioni Multi-AZ per migliorare la durabilità e la disponibilità di dati critici con una replica in standby. Una *replica in standby* è una replica di lettura dedicata che può assumere il carico di lavoro se si verifica il failover del database di origine. Non è possibile utilizzare una replica in standby per gestire il traffico di lettura. Puoi tuttavia creare repliche di lettura da istanze database Multi-AZ con traffico elevato per l'offload di query di sola lettura. Per ulteriori informazioni sulle implementazioni Multi-AZ, consultare [Implementazioni di istanze database Multi-AZ per Amazon RDS](Concepts.MultiAZSingleStandby.md).
Se viene eseguito il failover dell'istanza database di origine di un'implementazione Multi-AZ sull'istanza in standby, tutte le repliche di lettura associate passeranno a usare l'istanza in standby (ora primaria) come origine della replica. Potrebbe essere necessario riavviare le repliche di lettura, a seconda della versione RDS per PostgreSQL, come segue:
+ **PostgreSQL 13 e versioni successive**: il riavvio non è obbligatorio. Le repliche di lettura vengono automaticamente sincronizzate con il nuovo database primario. Tuttavia, in alcuni casi l'applicazione client potrebbe memorizzare nella cache i dettagli DNS (Domain Name Service) per le repliche di lettura. In tal caso, imposta il valore time-to-live (TTL) su un valore inferiore a 30 secondi. In questo modo si impedisce alla replica di lettura di mantenere un indirizzo IP obsoleto e pertanto si impedisce la sincronizzazione con il nuovo database primario. Per ulteriori informazioni su questa e altre best practice, consulta [Linee guida operative di base per Amazon RDS](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance).
+ **PostgreSQL 12 e tutte le versioni precedenti**: le repliche di lettura si riavviano automaticamente dopo un failover della replica in standby perché la replica in standby (ora principale) ha un indirizzo IP e un nome di istanza diversi. Il riavvio sincronizza la replica di lettura con il nuovo database primario.
Per ulteriori informazioni sul failover, consulta [Failover per un’istanza database Multi-AZ per Amazon RDS](Concepts.MultiAZ.Failover.md). Per ulteriori informazioni su come le repliche di lettura funzionano in una implementazione Multi-AZ, consultare [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md).
Per garantire il supporto del failover per una replica di lettura, puoi creare una replica di lettura come un'istanza database Multi-AZ. Amazon RDS crea una replica in standby della replica in un'altra zona di disponibilità (AZ). La creazione della replica di lettura come un'istanza database Multi-AZ non dipende dal fatto che il database di origine sia un'istanza database Multi-AZ.
# Decodifica logica su una replica di lettura
RDS per PostgreSQL supporta la replica logica dalle istanze in standby con PostgreSQL 16.1. Questo approccio consente di creare una decodifica logica da un’istanza in standby di sola lettura che riduce il carico sull’istanza database primaria. È possibile ottenere una maggiore disponibilità per le applicazioni che devono sincronizzare i dati su più sistemi. Questa funzionalità migliora le prestazioni del data warehouse e dell’analisi dei dati.
Inoltre, gli slot di replica su una determinata istanza in standby mantengono la promozione dell’istanza in standby all’istanza primaria. Ciò significa che, in caso di failover di un’istanza database primaria o di promozione di un’istanza in standby come nuova istanza primaria, gli slot di replica persisteranno e i precedenti abbonati dell’istanza in standby non saranno interessati.
**Per creare una decodifica logica su una replica di lettura**
1. **Attivare la replica logica**: per creare la decodifica logica su un’istanza in standby, è necessario attivare la replica logica sull’istanza database di origine e sulla relativa replica fisica. Per ulteriori informazioni, consulta [Configurazione delle repliche di lettura con PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md).
+ **Per attivare la replica logica per un’istanza database RDS per PostgreSQL appena creata**: creare un nuovo gruppo di parametri database personalizzato e impostare il parametro statico `rds.logical_replication` su `1`. Quindi, associare questo gruppo di parametri database all’istanza database di origine e alla relativa replica di lettura fisica. Per ulteriori informazioni, consulta [Associazione di un gruppo di parametri database a un’istanza database in Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
+ **Per attivare la replica logica per un’istanza database RDS per PostgreSQL esistente**: modificare il gruppo di parametri personalizzato dell’istanza database di origine e la relativa replica di lettura fisica per impostare il parametro statico `rds.logical_replication` su `1`. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Nota**
È necessario riavviare l’istanza database per applicare queste modifiche ai parametri.
È possibile utilizzare la seguente query per verificare i valori per `wal_level` e `rds.logical_replication` sull’istanza database di origine e sulla relativa replica di lettura fisica.
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **Creare una tabella nel database di origine**: eseguire la connessione al database nell’istanza database di origine. Per ulteriori informazioni, consulta [Connessione a un'istanza database che esegua il motore di database di PostgreSQL](USER_ConnectToPostgreSQLInstance.md).
Utilizzare le seguenti query per creare una tabella nel database di origine e inserire i valori:
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **Creare una pubblicazione per la tabella di origine**: utilizzare la seguente query per creare una pubblicazione per la tabella sull’istanza database di origine.
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
Utilizzare una query SELECT per verificare i dettagli della pubblicazione creata sia sull’istanza database di origine sia sull’istanza di replica di lettura fisica.
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **Creare una sottoscrizione da un’istanza di replica logica**: creare un’altra istanza database RDS per PostgreSQL come istanza di replica logica. Assicurarsi che il VPC sia configurato correttamente per garantire che questa istanza di replica logica possa accedere all’istanza di replica di lettura fisica. Per ulteriori informazioni, consulta [Amazon VPC e Amazon RDS](USER_VPC.md). Se l’istanza database di origine è inattiva, potrebbero verificarsi problemi di connettività e l’istanza primaria potrebbe non inviare i dati all’istanza in standby.
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
Utilizzare una query SELECT per verificare i dettagli dell’abbonamento sull’istanza di replica logica.
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **Controllare lo stato dello slot di replica logica**: è possibile vedere solo lo slot di replica fisica sull’istanza database di origine.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
Tuttavia, sull’istanza di replica di lettura, è possibile vedere lo slot di replica logica e il valore `confirmed_flush_lsn` che cambia man mano che l’applicazione utilizza attivamente le modifiche logiche.
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# Utilizzo di repliche di lettura a cascata con RDS per PostgreSQL
A partire dalla versione 14.1, RDS per PostgreSQL supporta le repliche di lettura a cascata. Con le *repliche di lettura a cascata*, puoi dimensionare le letture senza aggiungere sovraccarico all'istanza database RDS per PostgreSQL di origine. Gli aggiornamenti del registro WAL non vengono inviati dall'istanza database di origine a ciascuna replica di lettura. Invece, ogni replica di lettura in una serie a cascata invia gli aggiornamenti del registro WAL alla successiva replica di lettura della serie. Questo riduce il carico sull'istanza database di origine.
Con le repliche di lettura a cascata, l'istanza database RDS per PostgreSQL invia i dati WAL alla prima replica di lettura della catena. La replica di lettura invia quindi i dati WAL alla seconda replica della catena e così via. Il risultato finale è che tutte le repliche di lettura nella catena includono le modifiche dall'istanza database RDS per PostgreSQL, ma senza sovraccaricare esclusivamente l'istanza database di origine.
È possibile creare una serie di fino a tre repliche di lettura in una catena da un'istanza database RDS per PostgreSQL di origine. Ad esempio, supponiamo di avere un'istanza database RDS per PostgreSQL 14.1, `rpg-db-main`. È possibile effettuare le seguenti operazioni:
+ A partire da `rpg-db-main`, crea la prima replica di lettura nella catena, `read-replica-1`.
+ Da `read-replica-1`, crea quindi la successiva replica di lettura nella catena, `read-replica-2`.
+ Da `read-replica-2`, crea infine la terza replica di lettura nella catena, `read-replica-3`.
Non è possibile creare un'altra replica di lettura oltre la terza replica di lettura a cascata nella serie per `rpg-db-main`. Una serie completa di istanze da un'istanza database RDS per PostgreSQL di origine fino alla fine di una serie di repliche di lettura a cascata può essere composta al massimo da quattro istanze database.
Affinché le repliche di lettura a cascata funzionino, attiva i backup automatici su RDS per PostgreSQL. Crea prima la replica di lettura e quindi attiva i backup automatici sull'istanza database RDS per PostgreSQL. Il processo è lo stesso valido per gli altri motori di database Amazon RDS. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](USER_ReadRepl.Create.md).
Come per qualsiasi replica di lettura, puoi promuovere una replica di lettura appartenente a una cascata. La promozione di una replica di lettura all'interno di una catena di repliche di lettura rimuove la replica dalla catena. Ad esempio, supponiamo che tu voglia spostare parte del carico di lavoro fuori dall'istanza database `rpg-db-main` in una nuova istanza usata solo dal reparto contabile. Facendo riferimento alla catena di tre repliche di lettura dell'esempio, decidi di promuovere `read-replica-2`. La catena verrà modificata come segue:
+ La promozione `read-replica-2` rimuove l'istanza dalla catena di replica.
+ Ora è un'istanza read/write DB completa.
+ Continua a replicare su `read-replica-3`, proprio come prima della promozione.
+ L'istanza `rpg-db-main` continua a venire replicata su `read-replica-1`.
Per ulteriori informazioni sulla promozione delle repliche di lettura, consulta [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md).
**Nota**
RDS per PostgreSQL non supporta gli aggiornamenti della versione principale per le repliche a cascata. Prima di eseguire un aggiornamento della versione principale, rimuovere le repliche a cascata. È possibile ricrearle dopo aver completato l’aggiornamento dell’istanza database di origine e delle repliche di primo livello.
Per le repliche di lettura a cascata, RDS per PostgreSQL supporta 15 repliche di lettura per ogni istanza database di origine al primo livello di replica e 5 repliche di lettura per ogni istanza database di origine al secondo e al terzo livello di replica.
# Creazione di repliche di lettura a cascata tra Regioni con RDS per PostgreSQL
RDS per PostgreSQL supporta le repliche di lettura a cascata tra Regioni. È possibile creare una replica tra Regioni dall’istanza database di origine e quindi creare repliche nella stessa Regione da essa. È inoltre possibile creare una replica nella stessa Regione dall’istanza database di origine e quindi creare repliche tra Regioni da essa.
**Creazione di una replica tra Regioni e creazione delle repliche nella stessa Regione**
È possibile utilizzare un’istanza database RDS per PostgreSQL versione 14.1 o successiva, `rpg-db-main`, per effettuare quanto segue:
1. Iniziare con `rpg-db-main` (US-EAST-1), creare la prima replica di lettura tra Regioni della catena, `read-replica-1` (US-WEST-2).
1. Utilizzando la prima replica tra Regioni `read-replica-1` (US-WEST-2), creare la seconda replica di lettura nella catena, `read-replica-2` (US-WEST-2).
1. Utilizzando `read-replica-2`, creare la terza replica di lettura nella catena, `read-replica-3` (US-WEST-2).
**Creazione di una replica nella stessa Regione e creazione delle repliche tra Regioni**
È possibile utilizzare un’istanza database RDS per PostgreSQL versione 14.1 o successiva, `rpg-db-main`, per effettuare quanto segue:
1. Iniziando con `rpg-db-main` (US-EAST-1), creare la prima replica di lettura della catena, `read-replica-1` (US-EAST-1).
1. Utilizzando `read-replica-1` (US-EAST-1), creare la prima replica di lettura tra Regioni della catena, `read-replica-2` (US-WEST-2).
1. Utilizzando `read-replica-2` (US-WEST-2), creare la terza replica di lettura della catena, `read-replica-3` (US-WEST-2).
**Limitazioni nella creazione di repliche di lettura tra Regioni**
+ Una catena di repliche di database a cascata tra Regioni può estendersi su un massimo di due Regioni, con un massimo di quattro livelli. I quattro livelli includono l’origine del database e tre repliche di lettura.
**Vantaggi dell’utilizzo delle repliche di lettura a cascata**
+ Migliore scalabilità di lettura: distribuendo le query di lettura su più repliche, la replica a cascata aiuta a bilanciare il carico. Ciò migliora le prestazioni, specialmente nelle applicazioni con numerose letture, riducendo il carico sul database di scrittura.
+ Distribuzione geografica: le repliche a cascata possono essere posizionate in diverse località geografiche. Ciò riduce la latenza per gli utenti che si trovano lontano dal database primario e fornisce una replica di lettura locale, migliorando le prestazioni e l’esperienza utente.
+ Alta disponibilità e disaster recovery: in caso di guasto del server principale, le repliche possono essere promosse a primarie, garantendo la continuità. La replica a cascata migliora ulteriormente questa disponibilità fornendo più livelli di opzioni di failover e migliorando la resilienza complessiva del sistema.
+ Flessibilità e crescita modulare: man mano che il sistema cresce, è possibile aggiungere nuove repliche a diversi livelli senza eseguire una riconfigurazione importante del database primario. Questo approccio modulare consente una crescita scalabile e gestibile della configurazione della replica.
**Best practice per l’utilizzo di repliche di lettura tra Regioni**
+ Prima di promuovere una replica, si creano repliche aggiuntive. Questo approccio consentirà di risparmiare tempo e di gestire in modo efficiente il carico di lavoro.
# Funzionamento della replica in streaming per diverse versioni di RDS per PostgreSQL
Come illustrato in [Configurazione delle repliche di lettura con PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md), RDS per PostgreSQL utilizza il protocollo di replica in streaming nativo di PostgreSQL per inviare dati WAL dall'istanza database di origine. Invia i dati WAL di origine per leggere le repliche sia per le repliche di lettura nella regione che tra regioni. Con la versione 9.4, PostgreSQL ha introdotto gli slot di replica fisica come meccanismo di supporto per il processo di replica.
Uno *slot di replica fisica* impedisce a un'istanza database di origine di rimuovere i dati WAL prima che vengano consumati da tutte le repliche di lettura. Ogni replica di lettura ha un proprio slot fisico sull'istanza database di origine. Lo slot tiene traccia dei dati WAL più vecchi (per numero di sequenza logica, LSN) che potrebbero essere necessari per la replica. Dopo che tutti gli slot e le connessioni di database sono progrediti oltre un determinato WAL (LSN), il numero di sequenza logica (LSN) diventa un candidato per la rimozione al checkpoint successivo.
Amazon RDS utilizza Amazon S3 per archiviare i dati WAL. Per le repliche di lettura nella regione, è possibile utilizzare questi dati archiviati per recuperare la replica di lettura quando necessario. Un esempio di quando è possibile farlo è se la connessione tra database di origine e replica di lettura viene interrotta per qualsiasi motivo.
Nella tabella seguente è possibile trovare un riepilogo delle differenze tra le versioni di PostgreSQL e i meccanismi di supporto per la replica nella regione e tra regioni utilizzata da RDS per PostgreSQL.
| Versione | Nella regione | Tra regioni |
| --- | --- | --- |
| PostgreSQL 14.1 e versioni successive | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 e versioni precedenti | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
Per ulteriori informazioni, consulta [Monitoraggio e ottimizzazione del processo di replica](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md).
## Informazioni sui parametri di controllo della replica PostgreSQL
I seguenti parametri influenzano il processo di replica e determinano il modo in cui le repliche di lettura restano aggiornate con l'istanza database di origine:
**max\$1wal\$1senders**
Il parametro `max_wal_senders` specifica il numero massimo di connessioni che l'istanza database di origine può supportare contemporaneamente sul protocollo di replica in streaming.
Il valore predefinito varia in base alla versione RDS per PostgreSQL:
+ Per le versioni 13, 14 e 15, il valore predefinito è 20.
+ Per le versioni 16 e successive, il valore predefinito è 35.
Questo parametro deve essere impostato su un valore leggermente più alto del numero effettivo di repliche di lettura. Se questo parametro è impostato su un valore troppo basso per il numero di repliche di lettura, la replica viene interrotta.
Per ulteriori informazioni, consulta la sezione relativa al parametro [max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS) nella documentazione di PostgreSQL.
`max_wal_senders` è un parametro statico che richiede il riavvio dell’istanza database per rendere effettive le modifiche.
**wal\$1keep\$1segments**
Il parametro `wal_keep_segments` specifica il numero di file WAL (write-ahead log) conservati dall'istanza database di origine nella directory `pg_wal`. L'impostazione predefinita è 32.
Se il parametro `wal_keep_segments` non è impostato su un valore abbastanza grande per l'implementazione, una replica di lettura può avere un ritardo tale che la replica di streaming si arresta. In questo caso, Amazon RDS genera un errore di replica e inizia il ripristino sulla replica di lettura. A tale scopo, riproduce i dati WAL archiviati dell'istanza database di origine da Amazon S3. Il processo di ripristino continua finché la replica di lettura non avrà recuperato abbastanza per continuare la replica di streaming. È possibile vedere questo processo in esecuzione come viene acquisito dal registro PostgreSQL in [Esempio: come ripristinare una replica di lettura dalle interruzioni della replicaEsempio: ripristino di una replica di lettura dalle interruzioni della replica](#USER_PostgreSQL.Replication.example-how-it-works).
In PostgreSQL versione 13, il parametro `wal_keep_segments` è denominato `wal_keep_size`. Ha lo stesso scopo di `wal_keep_segments`, ma il suo valore predefinito è espresso in megabyte (MB) (2048 MB) anziché in numero di file. Per ulteriori informazioni, consulta la sezione relativa ai parametri [wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS) e [wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE) nella documentazione di PostgreSQL.
**max\$1slot\$1wal\$1keep\$1size**
Il parametro `max_slot_wal_keep_size` controlla la quantità di dati WAL che l'istanza database RDS per PostgreSQL conserva nella directory `pg_wal` per servire gli slot. Questo parametro viene utilizzato per le configurazioni che utilizzano gli slot di replica. Il valore predefinito per questo parametro è `-1`, ovvero non esiste alcun limite per la quantità di dati WAL conservati nell'istanza database di origine. Per informazioni sul monitoraggio degli slot di replica, consulta [Monitoraggio degli slot di replica per l'istanza database RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots).
Per ulteriori informazioni su questo parametro, consulta la sezione [max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE) nella documentazione di PostgreSQL.
Se si interrompe il flusso WAL che fornisce i dati a una replica di lettura, PostgreSQL passa alla modalità di ripristino. Ripristina la replica di lettura utilizzando i dati WAL archiviati da Amazon S3 o i dati WAL associati allo slot di replica. Al termine di questo processo, PostgreSQL tenta di ristabilire la replica in streaming.
### Esempio: come ripristinare una replica di lettura dalle interruzioni della replica
Nell'esempio seguente sono disponibili i dettagli del registro che dimostrano il processo di ripristino per una replica di lettura. L'esempio proviene da un'istanza DB RDS per PostgreSQL che esegue PostgreSQL versione 12.9 nello Regione AWS stesso database di origine, quindi non vengono utilizzati slot di replica. Il processo di ripristino è lo stesso valido per le altre istanze database RDS per PostgreSQL che eseguono la versione precedente alla 14.1 di PostgreSQL con repliche di lettura nella regione.
Quando la replica di lettura perde il contatto con l'istanza database di origine, Amazon RDS registra il problema nel registro sotto forma di messaggio `FATAL: could not receive data from WAL stream`, assieme a `ERROR: requested WAL segment ... has already been removed`. Come evidenziato nella riga in grassetto, Amazon RDS recupera la replica riproducendo un file WAL archiviato.
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Quando Amazon RDS riproduce abbastanza file WAL archiviati sulla replica da recuperare, viene ripreso lo streaming nella replica di lettura. Quando riprende lo streaming, Amazon RDS scrive una voce nel file di registro, simile alla seguente.
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## Impostazioni dei parametri di controllo della memoria condivisa
I parametri impostati determinano la dimensione della memoria condivisa per il monitoraggio delle transazioni, dei blocchi e delle transazioni preparate. IDs **La struttura della memoria condivisa di un'istanza in standby deve essere uguale o superiore a quella di un'istanza primaria.** Ciò garantisce che la prima non esaurisca la memoria condivisa durante il ripristino. Se i valori dei parametri sulla replica sono inferiori ai valori dei parametri sulla replica primaria, Amazon RDS regolerà automaticamente i parametri della replica e riavvierà il motore.
I parametri interessati sono:
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
Per evitare che RDS riavvii le repliche a causa della memoria insufficiente, si consiglia di applicare le modifiche ai parametri come riavvio in sequenza a ciascuna replica. È necessario applicare le seguenti regole quando si impostano i parametri:
+ **Aumento dei valori dei parametri:**
+ È sempre necessario aumentare prima i valori dei parametri di tutte le repliche di lettura ed eseguire un riavvio in sequenza di tutte le repliche. Quindi, applica le modifiche ai parametri sull'istanza primaria ed esegui un riavvio.
+ **Riduzione dei valori dei parametri:**
+ È innanzitutto necessario ridurre i valori dei parametri dell'istanza primaria ed eseguire un riavvio. Quindi, applica le modifiche ai parametri a tutte le repliche di lettura associate ed esegui un riavvio in sequenza.
# Monitoraggio e ottimizzazione del processo di replica
Si consiglia vivamente di monitorare regolarmente l'istanza database RDS per PostgreSQL e le repliche di lettura. È necessario assicurarsi che le repliche di lettura siano aggiornate in base alle modifiche dell'istanza database di origine. Amazon RDS recupera in modo trasparente le repliche di lettura quando si verificano interruzioni del processo di replica. Tuttavia, è meglio evitare il ripristino. Il ripristino tramite slot di replica è più rapido rispetto all'utilizzo dell'archivio Amazon S3, ma qualsiasi processo di ripristino può influire sulle prestazioni di lettura.
Per determinare la qualità dell'aggiornamento delle repliche di lettura in base all'istanza database di origine, è possibile effettuare le seguenti operazioni:
+ **Verifica valore di `ReplicaLag` tra istanza database di origine e repliche.** Il valore del *ritardo di replica* si riferisce al tempo di ritardo di una replica di lettura, in secondi, rispetto all'istanza database di origine. Questo parametro indica il risultato della query seguente.
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
Il ritardo di replica è un'indicazione della velocità con cui una replica di lettura rimane al passo con l'istanza database di origine. È il valore della latenza tra l'istanza database di origine e un'istanza di lettura specifica. Un valore elevato del ritardo di replica può indicare una mancata corrispondenza tra le classi di istanza database o i tipi di archiviazione (o entrambi) utilizzati dall'istanza database di origine e le relative repliche di lettura. La classe di istanza database, i tipi di archiviazione per l'istanza database di origine e tutte le repliche di lettura devono essere uguali.
Il ritardo della replica può anche essere il risultato di problemi di connessione non stabile. Puoi monitorare il ritardo di replica in Amazon CloudWatch visualizzando la metrica Amazon `ReplicaLag` RDS. Per ulteriori informazioni su `ReplicaLag` e altri parametri per Amazon RDS, consulta [CloudWatch Parametri Amazon per Amazon RDS](rds-metrics.md).
+ **Controlla il registro PostgreSQL per informazioni che puoi usare per regolare le impostazioni.** In ogni checkpoint, il registro PostgreSQL acquisisce il numero di file di registro delle transazioni riciclati, come illustrato nell'esempio seguente.
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
Puoi utilizzare queste informazioni per capire quanti file di transazione verranno riciclati in un determinato periodo di tempo. Puoi modificare l'impostazione del parametro `wal_keep_segments`, se necessario. Supponiamo, ad esempio, che il registro di PostgreSQL in `checkpoint complete` mostri `35 recycled` per un intervallo di 5 minuti. In questo caso, il valore predefinito 32 del parametro `wal_keep_segments` non è sufficiente per tenere il passo con l'attività di streaming e pertanto è consigliabile aumentare il valore di questo parametro.
+ **Usa Amazon CloudWatch per monitorare i parametri in grado di prevedere i problemi di replica.** Invece di analizzare direttamente il log di PostgreSQL, puoi utilizzare CloudWatch Amazon per controllare i parametri raccolti. Ad esempio, è possibile monitorare il valore del parametro `TransactionLogsGeneration` per vedere quanti dati WAL vengono generati dall'istanza database di origine. In alcuni casi, il carico di lavoro sull'istanza database potrebbe generare una grande quantità di dati WAL. In questo caso, potrebbe essere necessario modificare la classe di istanza database per l'istanza database di origine e delle repliche di lettura. L'utilizzo di una classe di istanza con prestazioni di rete elevate (10 Gb/s) può ridurre il ritardo delle repliche.
## Monitoraggio degli slot di replica per l'istanza database RDS per PostgreSQL
Tutte le versioni di RDS per PostgreSQL utilizzano gli slot di replica per le repliche di lettura tra regioni. RDS per PostgreSQL 14.1 e versioni successive utilizzano gli slot di replica per le repliche di lettura a livello di regione. Le repliche di lettura a livello di regione utilizzano anche Amazon S3 per archiviare i dati WAL. In altre parole, se l'istanza database e le repliche di lettura eseguono PostgreSQL 14.1 o versioni successive, gli slot di replica e gli archivi Amazon S3 sono entrambi disponibili per il ripristino della replica in lettura. Il ripristino di una replica di lettura utilizzando lo slot di replica è più veloce del ripristino dall'archivio Amazon S3. Pertanto, ti consigliamo di monitorare gli slot di replica e i relativi parametri.
È possibile visualizzare gli slot di replica sulle istanze database RDS per PostgreSQL eseguendo una query sulla vista `pg_replication_slots`, come segue.
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
Il parametro `wal_status` con valore `reserved` significa che la quantità di dati WAL conservati dallo slot rientra nei limiti del parametro `max_wal_size`. In altre parole, lo slot di replica è dimensionato correttamente. I valori di stato possibili sono i seguenti:
+ `extended`: lo slot supera l'impostazione del parametro `max_wal_size`, ma i dati WAL vengono conservati.
+ `unreserved`: lo slot non include più tutti i dati WAL richiesti. Alcuni di essi verranno rimossi al prossimo checkpoint.
+ `lost`: alcuni dati WAL obbligatori sono stati rimossi. Lo slot non è più utilizzabile.
Gli stati `unreserved` e `lost` di `wal_status` sono visibili solo quando `max_slot_wal_keep_size` non è negativo.
La vista `pg_replication_slots` mostra lo stato corrente degli slot di replica. Per valutare le prestazioni dei tuoi slot di replica, puoi utilizzare Amazon CloudWatch e monitorare i seguenti parametri:
+ **`OldestReplicationSlotLag`** - Mostra la quantità di dati WAL (Write-Ahead Log) sull’origine che non è stata utilizzata dalla replica con maggior ritardo.
+ **`TransactionLogsDiskUsage`** - Mostra la quantità di archiviazione utilizzata per i dati WAL. Quando una replica di lettura è in ritardo significativo, il valore di questo parametro può aumentare notevolmente.
Per ulteriori informazioni sull'utilizzo di Amazon CloudWatch e dei relativi parametri per RDS per PostgreSQL, consulta. [Monitoraggio dei parametri di Amazon RDS Aurora con Amazon CloudWatch](monitoring-cloudwatch.md) Per ulteriori informazioni sul monitoraggio della replica in streaming sulle istanze database RDS per PostgreSQL, consulta la sezione relativa alle [best practice per la replica Amazon RDS PostgreSQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/) sul *blog dei database AWS *.
# Configurazione della replica ritardata con RDS per PostgreSQL
## Panoramica e vantaggi
La funzionalità di replica ritardata in RDS per PostgreSQL consente di ritardare intenzionalmente la replica delle modifiche apportate ai dati dal database primario a uno o più server (di replica di lettura) in standby. Offre così una protezione preziosa contro il danneggiamento dei dati, la loro perdita accidentale e le transazioni errate che altrimenti potrebbero essere immediatamente propagate in tutte le repliche.
La replica ritardata è supportata nelle seguenti versioni di RDS per PostgreSQL:
+ 14.19 e versioni successive alla 14
+ 15.14 e versioni successive alla 15
+ 16.10 e versioni successive alla 16
+ 17.6 e versioni successive alla 17
Introducendo un ritardo nel processo di replica, è possibile usufruire di un opportuno intervallo di tempo per rilevare gli incidenti relativi ai dati e intervenire prima che si ripercuotano sull’intero cluster di database. I principali vantaggi della replica ritardata includono quanto segue:
+ Consente di eseguire il ripristino in seguito a eliminazioni accidentali, aggiornamenti o altri errori logici.
+ Funge da buffer contro la diffusione di dati danneggiati nel cluster di database.
+ Offre un’opzione di punto di ripristino aggiuntiva a integrazione delle tradizionali strategie di backup.
+ Consente di configurare il periodo di ritardo in base alle esigenze specifiche e alla tolleranza al rischio dell’organizzazione.
## Abilitazione e configurazione della replica ritardata
Per abilitare la replica ritardata su una replica di lettura RDS per PostgreSQL, procedi nel modo seguente:
**Nota**
Per le repliche di lettura a cascata, utilizza lo stesso parametro `recovery_min_apply_delay` e gli stessi passaggi descritti di seguito.
**Per abilitare la replica ritardata**
1. Crea un nuovo gruppo di parametri personalizzato o modificane uno esistente. Per ulteriori informazioni, consulta [Gruppi di parametri database per istanze database Amazon RDS](USER_WorkingWithDBInstanceParamGroups.md).
1. Nel gruppo di parametri, configura il parametro `recovery_min_apply_delay`:
+ Imposta il valore del ritardo desiderato, espresso in millisecondi. Ad esempio, 3.600.000 per un ritardo di 1 ora.
+ Intervallo consentito: da 0 a 86.400.000 ms (da 0 a 24 ore)
+ Impostazione predefinita: 0
1. Applica il gruppo di parametri all’istanza della replica di lettura che desideri configurare per la replica ritardata.
1. Riavvia l’istanza della replica di lettura per rendere effettive le modifiche.
**Nota**
Il parametro `recovery_min_apply_delay` è dinamico. Se si modifica un gruppo di parametri esistente che è già collegato all’istanza, le modifiche hanno effetto immediato senza necessità di riavvio. Se, tuttavia, si applica un nuovo gruppo di parametri all’istanza, è necessario il riavvio per rendere effettive le modifiche.
## Gestione del ripristino della replica ritardata
La replica ritardata è particolarmente utile negli scenari in cui i metodi di point-in-time ripristino tradizionali possono essere insufficienti o richiedere troppo tempo.
Durante il periodo di replica ritardata, per gestire il processo di ripristino è possibile utilizzare le seguenti funzioni di PostgreSQL:
+ `pg_wal_replay_pause()`: richiede la sospensione del processo di ripristino della replica ritardata.
+ `pg_wal_replay_resume()`: riavvia il processo di ripristino se in precedenza è stato sospeso.
+ `pg_is_wal_replay_paused()`: controlla se il processo di ripristino è attualmente sospeso.
+ `pg_get_wal_replay_pause_state()`: visualizza lo stato corrente del processo di ripristino (non sospeso, sospensione richiesta o sospeso).
Gli utenti con il ruolo `rds_superuser` dispongono dei privilegi EXECUTE su `pg_wal_replay_pause()` e `pg_wal_replay_resume()`. Se altri utenti del database devono accedere a queste funzioni, è necessario concedere loro il ruolo `rds_superuser`. Per ulteriori informazioni sul ruolo `rds_superuser`, consulta [Comprendere il ruolo rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md).
Per l’accesso ad altre funzioni, quali `pg_is_wal_replay_paused()` e `pg_get_wal_replay_pause_state()`, il ruolo `rds_superuser` non è necessario.
Per controllare con precisione il momento in cui viene ripristinata la replica ritardata è possibile utilizzare i seguenti parametri relativi alla destinazione di ripristino. Questi parametri sono statici e richiedono il riavvio del database per l’applicazione delle modifiche:
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**Importante**
È possibile specificare un solo parametro di destinazione di ripristino alla volta. Se si impostano più parametri di questo tipo nel file di configurazione, viene generato un errore.
## Considerazioni sulla pianificazione
Informazioni da prendere in considerazione durante la pianificazione della replica ritardata con RDS per PostgreSQL:
+ Durante la rotazione automatica delle credenziali di `rdsrepladmin`, che si verifica ogni 90 giorni, le repliche a lettura ritardata possono assumere temporaneamente lo stato `REPLICATION_ERROR`. Se la replica ritardata ha un numero sufficiente di log WAL per gestire il ritardo configurato, potrebbe sospendere il processo del ricevitore WAL, causando un accumulo di WAL sull’origine. È necessario monitorare lo stato di replica sulla replica e il consumo di archiviazione sull’origine per evitare di raggiungere la soglia di esaurimento.
+ Quando le repliche a lettura ritardata riscontrano eventi di sistema, come il riavvio, assumono lo stato `REPLICATION_ERROR`, in cui il processo del ricevitore WAL rimane inattivo fino alla scadenza del periodo di ritardo configurato. Questo comportamento può causare l’accumulo di WAL sull’istanza di origine, con conseguente potenziale esaurimento dell’archiviazione. Di seguito sono elencate le misure preventive da prendere in considerazione:
+ Configura gli CloudWatch allarmi per monitorare l'utilizzo dello storage sulle istanze di origine.
+ Abilitare il dimensionamento automatico dell’archiviazione per gestire una crescita di WAL inaspettata.
+ Impostare il parametro `max_slot_wal_keep_size` sull’istanza di origine per limitare la conservazione di WAL in base agli slot di replica.
+ Monitorare regolarmente il ritardo di replica e lo stato degli slot.
+ I ritardi più lunghi aumentano i log WAL sulle repliche, utilizzando più archiviazione. Monitora lo spazio di archiviazione utilizzando CloudWatch allarmi, abilita l'auto-scaling o catch up repliche quando necessario.
+ Quando si promuove una replica a lettura ritardata, il parametro `recovery_min_apply_delay` non viene rispettato e tutti i record WAL in sospeso vengono applicati immediatamente.
+ Il parametro `recovery_min_apply_delay` è indipendente da ogni livello di una configurazione di replica a cascata. L’impostazione di un ritardo su una replica non aumenta il ritardo delle repliche a cascata.
Per ulteriori informazioni, consulta la [documentazione sulle repliche di lettura di RDS per PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) e la [documentazione sul disaster recovery di RDS per PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html).
## Informazioni sulle limitazioni
La funzionalità di replica ritardata di Amazon RDS per PostgreSQL presenta le seguenti limitazioni:
+ Durante la configurazione della replica ritardata, le implementazioni blu/verdi hanno le seguenti limitazioni:
+ **Istanza di origine verde**: `recovery_min_apply_delay parameter` viene ignorato, anche se configurato nel gruppo di parametri. Le eventuali impostazioni di ritardo sull’istanza di origine verde non hanno effetto.
+ **Istanza di replica verde**: `recovery_min_apply_delay parameter` è completamente supportato e applicato al file di configurazione PostgreSQL. Le impostazioni di ritardo funzionano come previsto durante il flusso di lavoro di switchover.
+ Implementazioni RDS per gli aggiornamenti delle versioni principali Blue/Green
+ Durante gli aggiornamenti delle versioni principali, tutte le repliche di lettura ritardate vengono automaticamente terminate per consentire all’istanza di origine di proseguire il processo di aggiornamento e garantire così un tempo di inattività minimo. Una volta completato l'aggiornamento dell’istanza di origine, è necessario creare di nuovo manualmente le repliche ritardate.
+ La replica ritardata non è compatibile con le seguenti funzionalità.
+ Replica logica di RDS per PostgreSQL
+ Cluster Multi-AZ di RDS per PostgreSQL (inclusa replica in entrata e in uscita)
+ Aurora PostgreSQL
# Risoluzione dei problemi per la replica di lettura RDS per PostgreSQL
Di seguito sono riportati suggerimenti per la risoluzione di alcuni problemi comuni relativi alle repliche di lettura RDS per PostgreSQL.
**Terminare la query che causa il ritardo della replica di lettura**
Le transazioni con stato di transazione attiva o inattiva che sono in esecuzione da molto tempo nel database potrebbero interferire con il processo di replica WAL, aumentando così il ritardo della replica. Pertanto, è necessario monitorare il runtime di queste transazioni con la vista PostgreSQL `pg_stat_activity`.
Eseguire una query sull’istanza primaria simile alla seguente per trovare l’ID di processo (PID) della query in esecuzione da molto tempo:
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
Dopo aver identificato il PID della query, è possibile scegliere di terminare la query.
Eseguire una query sull’istanza primaria simile alla seguente per terminare la query in esecuzione da molto tempo:
```
SELECT pg_terminate_backend(PID);
```