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à.
# 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 tradizionali metodi di ripristino point-in-time 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\_superuser](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\_target
+ recovery\_target\_lsn
+ recovery\_target\_name
+ recovery\_target\_time
+ recovery\_target\_xid
+ recovery\_target\_inclusive
**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:
+ Blue/Green le implementazioni presentano le seguenti limitazioni durante la configurazione della replica ritardata:
+ **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 Blue/Green gli aggiornamenti delle versioni principali
+ 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 RDS per Multi-AZ PostgreSQL (inclusa la replica in entrata e in uscita)
+ Aurora PostgreSQL