Exam AWS Certified Solutions Architect - Professional topic 1 question 928 discussion

A, First a read replica has to be created and that could be promoted to a cluster. second forward writes

Technically, none of these solutions meet the requirement. Aurora Global Databases still have the issue of lag and stale data depending on the configuration. There is only one writer that replicates the data to the read replica in the second region. See the following in the documentation to understand write forwarding latency: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding-ams.html#aurora-global-database-write-forwarding-isolation-ams Option C comes the closest. They may mean Group Replication. You can have each instance perform their own read and write operations. But there isn't a concept of write forwarding. However, there are a lot of limitations for doing this. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-active-active-clusters.html

https://aws.amazon.com/getting-started/hands-on/migrate-rdsmysql-to-auroramysql/#:~:text=2.1%20%2D%20Open%20the%20Amazon%20RDS,choose%20Create%20Aurora%20read%20replica. First a read replica has to be created and that could be promoted to a cluster ..

hesitated between A and D but sence A it saying pause the write so ...

The solution that meets these requirements is to convert the RDS for MySQL DB instance to an Amazon Aurora MySQL DB cluster and adding eu-west-1 as a secondary Region to the DB cluster, this will enable write forwarding on the DB cluster which will allow the customers in Europe and the customers in the US to have access to the same data and write to the database and see updates from the other group in real time. Also, deploying the application in eu-west-1 and configuring the application to use the Aurora MySQL endpoint in eu-west-1, will ensure that customers in Europe will have low latency and not stale data. Aurora uses a native replication feature to propagate writes to all Aurora replicas, regardless of their location and this makes it the best option for this use case.

"A" is the one.

D seems to be wrong - To "convert" the RDS instance to Aurora, you'll need to restore from a snapshot - OR, deploy a read replica as per question A. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.html

Only 'A' will work

I think A https://aws.amazon.com/blogs/database/best-practices-for-migrating-rds-for-mysql-databases-to-amazon-aurora/

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html

Very good answer

I am confuse if answer is A.. coz .. Create an Amazon Aurora MySQL replica of the RDS for MySQL DB instance (At this stage, Aurora should be empty since no migration yet) . Pause application writes to the RDS DB instance. Promote the Aurora Replica to a standalone DB cluster. Reconfigure the application to use the Aurora database and resume writes. ...... What happen to the existing data in RDS? No need to migrate?? Cannot be B and C.... D. wise.. you can convert RDSD to mySQLDB direcly.. but here it didn't mentioned direct conversion.. if they mentioned migrate RDS to AuroraDB... then the whole statement would be wrong. Again.. badlly worded option here.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html

A You cannot convert RDS to Aurora, you need to create an Aurora Replica first and promote to a standalone DB cluster

It's D: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html