Una empresa ejecuta una aplicación on-premises respaldada por una base de datos MySQL. La empresa está migrando la aplicación a AWS para mejorar la elasticidad y la disponibilidad. La base de datos de producción experimenta una gran actividad de lectura durante el funcionamiento normal. Cada 4 horas, el equipo de desarrollo extrae una exportación completa de la base de datos de producción para poblar una base de datos de staging; durante esta exportación, los usuarios experimentan una latencia inaceptable y el equipo de desarrollo no puede usar staging hasta que finalice la exportación. Un arquitecto de soluciones debe recomendar una arquitectura de reemplazo que elimine la latencia de la aplicación y permita al equipo de desarrollo usar el entorno de staging sin demora. ¿Qué solución cumple con estos requisitos?

La opción correcta es utilizar Amazon Aurora MySQL con Aurora Replicas Multi-AZ para producción y clonación de bases de datos para staging. Aurora Replicas Multi-AZ proporciona alta disponibilidad y escalabilidad de lectura, manejando la alta actividad de lectura sin afectar la instancia principal. La clonación de bases de datos de Aurora permite crear una copia de la base de datos de producción (o de una réplica) en segundos, sin impacto en el rendimiento de producción y sin necesidad de exportaciones largas. Esto elimina la latencia durante la creación del entorno de staging y permite al equipo de desarrollo acceder a los datos de inmediato. Las opciones incorrectas que usan mysqldump para staging son problemáticas porque mysqldump es un proceso que consume muchos recursos y puede causar la latencia inaceptable que se busca evitar. La opción de usar Amazon RDS for MySQL con una instancia en espera para staging no es viable, ya que la instancia en espera es una réplica síncrona para recuperación ante desastres y no está diseñada para ser utilizada como un entorno de staging independiente.