Which solution meets these requirements?
Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Populate the staging database by implementing a backup and restore process that uses the mysqldump utility.
Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Use database cloning to create the staging database on-demand.
Use Amazon RDS for MySQL with a Multi-AZ deployment and read replicas for production. Use the standby instance for the staging database.
Use Amazon RDS for MySQL with a Multi-AZ deployment and read replicas for production. Populate the staging database by implementing a backup and restore process that uses the mysqldump utility.
Explanations:
While using Amazon Aurora MySQL with Multi-AZ replicas provides high availability and scalability, the backup and restore process using mysqldump will still cause application latency during the export. This doesn’t solve the issue of users experiencing delays while the staging database is populated.
Amazon Aurora MySQL supports on-demand database cloning, which allows the development team to create a staging database without impacting the production environment. This approach alleviates application latency issues, as it does not require a full export that blocks users.
Using Amazon RDS for MySQL with Multi-AZ and read replicas does improve availability, but relying on the standby instance for the staging database is not a standard practice. It can lead to performance issues, and any maintenance on the standby could affect the staging environment.
Similar to Option A, using Amazon RDS for MySQL with a backup and restore process using mysqldump would cause application latency during the staging population process. This option does not provide a solution to the latency issue users experience.
I map out that the answer is:
Use Amazon Aurora MySQL with Multi-AZ Aurora Replicas for production. Use database cloning to create the staging database on-demand.