Multi-AZ e backup automatici

Multi-AZ e una funzionalita di alta disponibilita di RDS che effettua automaticamente il provisioning di una replica standby sincrona in una zona di disponibilita diversa nella stessa regione. AWS gestisce la replica in modo trasparente: si connette tramite un singolo endpoint DNS e RDS instrada il traffico verso il database primario.

Se l'istanza primaria si guasta per problemi hardware, di rete o del sistema operativo, RDS esegue un failover automatico verso lo standby in circa 60–120 secondi. L'applicazione si riconnette utilizzando lo stesso endpoint DNS, che ora viene risolto nell'indirizzo IP dello standby.

Puo abilitare Multi-AZ durante la creazione di un'istanza RDS oppure modificandone una esistente. Quando lo abilita su un'istanza in esecuzione, AWS crea uno snapshot del database primario, lo ripristina in una seconda AZ, quindi sincronizza usando la replica nativa del motore. Questo processo puo causare una breve sospensione dell'I/O sul database primario, quindi lo pianifichi in una finestra a basso traffico oppure accetti la tempistica della finestra di manutenzione.

Multi-AZ e supportato da tutti i motori RDS, inclusi MySQL, PostgreSQL, MariaDB, Oracle e SQL Server, e non richiede modifiche a livello di applicazione.

Quando si verifica un failover, RDS aggiorna il CNAME DNS dell'endpoint DB affinche punti allo standby entro circa 60 secondi. L'applicazione deve riconnettersi dopo aver rilevato l'interruzione di una connessione TCP. Per ridurre al minimo i ritardi di riconnessione:

• Usi un TTL DNS breve (in genere gia impostato da RDS a 5 secondi)
• Implementi un backoff esponenziale con retry nella logica di connessione
• Usi strumenti di connection pooling come RDS Proxy, che si riconnettono automaticamente

Il failover viene attivato anche manualmente per la manutenzione o le modifiche alla classe di istanza, consentendo aggiornamenti con downtime quasi nullo quando Multi-AZ e abilitato.

Una frequente fonte di confusione negli esami riguarda la differenza tra Multi-AZ (per la disponibilita) e le Read Replica (per la scalabilita). Differenze principali:

• Standby Multi-AZ: replica sincrona, non serve traffico di lettura, failover automatico, stessa regione
• Read Replica: replica asincrona, serve traffico di lettura, nessun failover automatico, puo essere cross-region

Multi-AZ non migliora le prestazioni in lettura: lo standby non e accessibile per le query. Per migliorare sia la disponibilita SIA la scalabilita in lettura, usi Multi-AZ sul database primario e aggiunga separatamente le Read Replica.

RDS crea automaticamente snapshot completi giornalieri del database e acquisisce i log delle transazioni ogni 5 minuti. Insieme, consentono il ripristino point-in-time (PITR) a qualsiasi secondo all'interno del periodo di conservazione dei backup. Puo ripristinare il database allo stato in cui si trovava in qualsiasi momento di tale intervallo.

I backup automatici sono abilitati per impostazione predefinita e possono essere conservati da 1 a 35 giorni. Impostando la conservazione su 0 si disabilitano i backup automatici (e PITR). La finestra di backup e un periodo di 30 minuti che puo specificare oppure lasciare scegliere ad AWS nelle ore di minor traffico.

La finestra di backup è il periodo in cui vengono acquisite le snapshot giornaliere. Durante questa finestra, l'I/O dello storage può interrompersi brevemente nelle distribuzioni Single-AZ. Nelle distribuzioni Multi-AZ, la snapshot viene acquisita dallo standby, eliminando l'impatto sull'I/O del primario.

La finestra di manutenzione è un periodo settimanale separato durante il quale AWS applica patch al sistema operativo, aggiornamenti minori del motore e modifiche all'istanza. La best practice consiste nell'impostare entrambe le finestre in periodi di basso traffico e assicurarsi che non si sovrappongano.

Per eseguire il ripristino a un determinato momento, RDS ripristina prima la snapshot giornaliera più recente, quindi riproduce i log delle transazioni fino al timestamp richiesto. Il risultato è una nuova istanza DB: PITR non sovrascrive mai l'istanza di origine, offrendo un percorso di ripristino sicuro che non interrompe la produzione.

Quando l'istanza ripristinata è disponibile, aggiorni la stringa di connessione dell'applicazione per indirizzarla al nuovo endpoint, verifichi l'integrità dei dati e quindi elimini l'originale se il ripristino era intenzionale. Il tempo di ripristino tipico è proporzionale alle dimensioni del database e al volume dei log dall'ultima snapshot.

Oltre ai backup automatici, può acquisire snapshot manuali in qualsiasi momento. A differenza dei backup automatici, le snapshot manuali non sono soggette al periodo di conservazione: rimangono disponibili finché non le elimina esplicitamente.

Le snapshot manuali sono ideali per acquisire lo stato del sistema prima di una migrazione importante dello schema, di un aggiornamento dell'applicazione o al termine di un ciclo di fatturazione per l'archiviazione ai fini della conformità. Può anche condividere le snapshot manuali con altri account AWS o copiarle tra le regioni per il disaster recovery.

Può copiare snapshot automatiche o manuali in un'altra regione AWS per il disaster recovery. La copia è una snapshot completa archiviata nell'infrastruttura S3 della regione di destinazione. Una volta copiata, può ripristinare una nuova istanza RDS in quella regione se la regione primaria diventa indisponibile.

Le copie delle snapshot possono essere crittografate nella destinazione anche se l'origine non è crittografata, e viceversa. Le copie tra regioni comportano costi di trasferimento dati. Utilizzi AWS Backup o una funzione Lambda attivata da EventBridge per automatizzare le copie periodiche delle snapshot tra regioni.

Amazon RDS Proxy si interpone tra l'applicazione e RDS e gestisce un pool di connessioni al database. È particolarmente utile per le funzioni Lambda, che possono aprire migliaia di connessioni di breve durata ed esaurire il limite di connessioni del database. RDS Proxy multiplexa le connessioni, così il database vede un numero molto inferiore di connessioni attive.

Durante un failover Multi-AZ, RDS Proxy mantiene le connessioni dell'applicazione e ristabilisce la connessione al database con il nuovo primario, riducendo il tempo di riconnessione dell'applicazione da minuti a pochi secondi. RDS Proxy si integra inoltre con Secrets Manager per ruotare le credenziali senza downtime dell'applicazione.

RDS offre ora due opzioni Multi-AZ: Multi-AZ DB Instance (classica, con un solo standby) e Multi-AZ DB Cluster (con due istanze standby leggibili in AZ diverse). La modalità cluster utilizza la replica semisincrona e consente di gestire il traffico di lettura sugli standby, offrendo maggiore disponibilità e scalabilità delle letture senza Read Replica separate.

Per l'esame SAA-C03, la classica Multi-AZ DB Instance è quella verificata più frequentemente. Ricordi: Multi-AZ Cluster è l'opzione più recente, in cui gli standby possono gestire le letture, mentre lo standby classico non può farlo.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: Multi-AZ fornisce la replica sincrona su uno standby con failover automatico in 60–120 secondi, i backup automatici consentono il PITR a qualsiasi secondo all'interno della finestra di conservazione (1–35 giorni) e le snapshot manuali rimangono disponibili indefinitamente e possono essere copiate tra regioni per il DR. Ora esamineremo le Read Replica per distribuire il traffico di lettura e migliorare il throughput delle letture.