Une entreprise exécute une application sur site adossée à une base de données MySQL. L'entreprise migre l'application vers AWS pour améliorer l'élasticité et la disponibilité. La base de données de production connaît une forte activité de lecture pendant le fonctionnement normal. Toutes les 4 heures, l'équipe de développement extrait une exportation complète de la base de données de production pour alimenter une base de données de staging ; pendant cette exportation, les utilisateurs subissent une latence inacceptable et l'équipe de développement ne peut pas utiliser le staging tant que l'exportation n'est pas terminée. Un architecte de solutions doit recommander une architecture de remplacement qui élimine la latence de l'application et permet à l'équipe de développement d'utiliser l'environnement de staging sans délai. Quelle solution répond à ces exigences ?

La bonne réponse est d'utiliser Amazon Aurora MySQL avec des répliques Aurora Multi-AZ pour la production et le clonage de base de données pour le staging. Aurora offre une haute disponibilité et des performances supérieures. Le clonage de base de données Aurora permet de créer une copie de la base de données de production en quelques minutes, sans impacter les performances de la production ni nécessiter un processus de sauvegarde/restauration long, répondant ainsi aux exigences de latence et de disponibilité du staging. Les autres options sont incorrectes car : Utiliser mysqldump pour le staging est lent et impacte la production, ce qui est le problème actuel. Utiliser l'instance de secours RDS Multi-AZ pour le staging n'est pas une bonne pratique, car l'instance de secours est destinée à la reprise après sinistre et non à des charges de travail de développement/test. De plus, elle ne résout pas le problème de la création rapide et non-bloquante de l'environnement de staging.