Un'azienda esegue un'applicazione on-premises supportata da un database MySQL. L'azienda sta migrando l'applicazione ad AWS per migliorare l'elasticità e la disponibilità. Il database di produzione subisce un'intensa attività di lettura durante il normale funzionamento. Ogni 4 ore il team di sviluppo estrae un'esportazione completa del database di produzione per popolare un database di staging; durante questa esportazione gli utenti riscontrano una latenza inaccettabile e il team di sviluppo non può utilizzare lo staging finché l'esportazione non è terminata. Un architetto di soluzioni deve raccomandare un'architettura sostitutiva che elimini la latenza dell'applicazione e consenta al team di sviluppo di utilizzare l'ambiente di staging senza ritardi. Quale soluzione soddisfa questi requisiti?

L'opzione corretta è Amazon Aurora MySQL con Aurora Replicas Multi-AZ per la produzione e la clonazione del database per lo staging. Aurora MySQL offre alta disponibilità e scalabilità in lettura tramite Aurora Replicas, che possono essere distribuite su più zone di disponibilità (Multi-AZ). La clonazione del database di Aurora permette di creare una copia fisica del database in pochi minuti, senza influire sulle prestazioni del database di origine e senza costi aggiuntivi di archiviazione per i dati clonati, poiché condivide i blocchi di dati sottostanti. Questo elimina la latenza durante la creazione dello staging e consente al team di sviluppo di lavorare immediatamente. Le altre opzioni sono meno efficienti: L'utilizzo di mysqldump per popolare lo staging causerebbe ancora latenza sul database di produzione e ritarderebbe la disponibilità dello staging. L'utilizzo di un'istanza di standby di RDS per lo staging non è una pratica consigliata in quanto l'istanza di standby è destinata al failover e non è accessibile per operazioni di lettura o scrittura dirette.