Configurazione della replica ritardata con RDS per PostgreSQL - Amazon Relational Database Service
Panoramica e vantaggiAbilitazione e configurazioneGestione del ripristino della replica ritardataConsiderazioni sulla pianificazioneInformazioni sulle limitazioni

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.

  2. 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

  3. Applica il gruppo di parametri all’istanza della replica di lettura che desideri configurare per la replica ritardata.

  4. 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 richiedere il riavvio. Se tuttavia si applica un nuovo gruppo di parametri all’istanza, il riavvio è necessario 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_superuser.

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 e la documentazione sul disaster recovery di RDS per PostgreSQL.

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. Dopo che l’istanza di origine ha completato l’aggiornamento, è 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