Read Replica per scalare le letture

Le Read Replica sono copie dell'istanza primaria RDS che ricevono gli aggiornamenti tramite replica asincrona. A differenza dello standby Multi-AZ, le Read Replica sono accessibili per le query SELECT, consentendo di distribuire il traffico di lettura e ridurre il carico sul database primario.

Le Read Replica sono supportate da MySQL, PostgreSQL, MariaDB, Oracle (con Active Data Guard) e tutte le edizioni di Aurora. Può avere fino a 15 Read Replica per Aurora MySQL e Aurora PostgreSQL e fino a 5 per RDS MySQL/PostgreSQL standard.

Per creare una Read Replica, l'istanza di origine deve avere i backup automatici abilitati (periodo di conservazione maggiore di 0). AWS acquisisce una snapshot del primario, la ripristina in una nuova istanza DB e stabilisce la replica asincrona dal primario.

Ogni Read Replica dispone di un proprio endpoint DNS. L'applicazione deve essere aggiornata per indirizzare le letture agli endpoint delle repliche. I connection pooler o i framework applicativi con separazione tra letture e scritture possono instradare automaticamente le query SELECT alle repliche.

Poiché la replica è asincrona, le Read Replica possono essere in ritardo rispetto al primario di alcuni millisecondi o secondi, a seconda del volume di scritture. Questo fenomeno è chiamato ritardo della replica. Può monitorarlo tramite la metrica CloudWatch ReplicaLag.

Le applicazioni devono essere progettate per tollerare la consistenza eventuale durante la lettura dalle repliche. Ad esempio, dopo l'inserimento di un record, una lettura immediata da una replica potrebbe non restituire ancora la nuova riga. La consistenza read-after-write richiede di reindirizzare quella specifica lettura al primario.

RDS supporta la creazione di Read Replica in una regione AWS diversa, consentendo la scalabilità globale delle letture e il disaster recovery. La replica tra regioni utilizza Internet pubblico o AWS Global Accelerator e il ritardo della replica è maggiore rispetto a quello all'interno di una regione a causa della latenza di rete.

Le repliche tra regioni sono utili quando: desidera gestire le letture più vicino agli utenti di un'altra area geografica, ha bisogno di una copia DR pronta per essere promossa in un'altra regione oppure desidera spostare le query analitiche lontano dall'ambiente di produzione.

La promozione di una Read Replica interrompe il collegamento di replica e la trasforma in un'istanza DB primaria indipendente e scrivibile. Questa procedura viene utilizzata negli scenari di disaster recovery quando il primario originale non è disponibile oppure quando si desidera aggiornare la replica a una versione diversa del motore e utilizzarla come nuovo primario.

La promozione è irreversibile: una volta promossa, l'istanza non può più essere una replica. Prima della promozione, si assicuri che la replica sia il più possibile aggiornata (con un ritardo minimo) per ridurre al minimo la perdita di dati. Dopo la promozione, aggiorni la stringa di connessione dell'applicazione in modo che punti al nuovo endpoint primario.

Nell'esame SAA-C03, distinguere le Read Replica da Multi-AZ è fondamentale:

• Se lo scenario richiede prestazioni di lettura migliori o scalabilità delle letture → Read Replica
• Se lo scenario richiede failover automatico o alta disponibilità → Multi-AZ
• Se lo scenario richiede entrambe le caratteristiche → Multi-AZ sul primario più Read Replica

Ricordi inoltre: gli standby Multi-AZ NON gestiscono le letture; le Read Replica NON forniscono il failover automatico (per le repliche non Aurora è necessario promuoverle manualmente).

Aurora gestisce le Read Replica in modo diverso rispetto a RDS standard. Aurora utilizza un livello di storage distribuito condiviso, quindi le repliche accedono alle stesse pagine di dati sottostanti del primario. Di conseguenza, le repliche Aurora presentano un ritardo di replica minimo (in genere inferiore a 100 ms) e possono gestire ciascuna il traffico di lettura.

Aurora fornisce un Reader Endpoint che distribuisce il carico delle connessioni tra tutte le istanze replica disponibili. L'applicazione si connette al Reader Endpoint e Aurora distribuisce automaticamente le letture. Se una replica si guasta, viene rimossa dal pool dei reader senza influire sull'endpoint.

In Aurora, se l'istanza primaria (writer) si guasta, Aurora promuove automaticamente una delle Read Replica a primaria in circa 30 secondi, molto più rapidamente del failover Multi-AZ di RDS standard. La replica promossa inizia immediatamente ad accettare scritture tramite il Cluster Writer Endpoint.

Aurora supporta livelli di priorità per il failover (0–15), consentendo di controllare quale replica venga promossa per prima. Assegni una priorità maggiore (tier 0) alle repliche che utilizzano classi di istanza più grandi o che si trovano nelle AZ preferite.

Un'architettura tipica per la scalabilità delle letture instrada il traffico tramite un Application Load Balancer o tramite la logica dell'applicazione:

• Tutte le operazioni di scrittura (INSERT, UPDATE, DELETE) → endpoint DB primario
• Tutte le operazioni di lettura (SELECT) → endpoint delle Read Replica o Aurora Reader Endpoint
• Cache di sessione e cache dei risultati → ElastiCache (riduce ulteriormente le letture dalle repliche)

Per query analitiche estremamente pesanti, valuti la promozione di una replica o l'utilizzo della funzionalità parallel query di Aurora, che sposta l'elaborazione al livello di storage evitando impatti sul cluster di produzione.

Tra le metriche CloudWatch principali per le Read Replica figurano:

• ReplicaLag — secondi di ritardo rispetto al primario; generi un allarme se il valore aumenta in modo imprevisto
• ReadIOPS — verifica che lo storage della replica riesca a gestire il carico delle query
• DatabaseConnections — verifica che la replica non abbia esaurito le connessioni
• CPUUtilization — un valore elevato sulla replica indica la necessità di ottimizzare le query

RDS Performance Insights è disponibile sulle Read Replica e mostra le istruzioni SQL principali che consumano più tempo del database, aiutando a identificare e ottimizzare le query di lettura costose.

Casi d'uso comuni delle Read Replica RDS nell'esame SAA-C03:

• Reportistica e analisi: eseguire query SELECT pesanti su una replica per evitare di rallentare le scritture in produzione
• Distribuzione geografica: le repliche tra regioni servono gli utenti di altri continenti con una latenza inferiore
• Disaster recovery: una replica tra regioni può essere promossa se la regione primaria si guasta
• Sviluppo e test: promuovere una replica per creare un ambiente di test con una copia aggiornata dei dati di produzione

Le Read Replica non sostituiscono i backup: mantenga sempre separatamente backup automatici e snapshot manuali.

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

In questa lezione ha imparato che le Read Replica utilizzano la replica asincrona per distribuire il traffico di lettura, il ritardo della replica indica che le repliche possono essere leggermente indietro rispetto al primario e le repliche Aurora presentano un ritardo minimo e supportano la promozione automatica. Le repliche tra regioni offrono sia la scalabilità globale delle letture sia un'opzione DR. Ora esamineremo la sicurezza di RDS con la crittografia e i gruppi di parametri.