Aurora Global Database vs cross-Region read replicas

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. A company rotates the Region that serves its writes once a quarter as a resilience exercise. Its Aurora global database is healthy at the time of each rotation, engine versions match across clusters, and the exercise must complete without losing committed transactions. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: B is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Use a cross-Region failover, which is the managed operation for moving the primary cluster between Regions on a schedule.Failover is the mechanism "to recover your Aurora Global Database after an outage in the primary Region", which is not a planned rotation.The answerB.Use an Aurora Global Database switchover, which relocates the primary cluster of a healthy global database to a secondary Region with no data loss.The documentation splits these two operations by whether the database is healthy. "For planned operational procedures such as Regional rotation, use the switchover mechanism (previously called 'managed planned failover'). With this feature, you can relocate the primary cluster of a healthy Aurora Global Database to one of its secondary Regions with no data loss." The other mechanism is named for the other case: "To recover your Aurora Global Database after an outage in the primary Region, use the failover mechanism." The exercise here is the first case exactly - planned, healthy, and no data loss - and the stem's matching engine versions satisfy the condition that managed switchovers require.Your answerC.Restore the primary cluster from a snapshot into the target Region and repoint the application at the restored cluster.A snapshot restore loses everything written after the snapshot, which the requirement rules out.Your answerD.Detach the secondary cluster and promote it to a standalone cluster, and then rebuild the whole global database around that new primary cluster afterwards.Discards the global database to move its primary, and the rebuild is the expensive part of a quarterly exercise.

   Written from docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

2. A company runs an Amazon Aurora PostgreSQL global database with a primary DB cluster in one AWS Region and one secondary DB cluster in a second Region. A regulator requires that a failover never loses more than 60 seconds of committed transactions, and the company accepts that writes can pause to hold that limit. After a failover, the new primary must accept writes at once, and the application must reach it without a connection string change. Which combination of steps should a solutions architect take to meet these requirements? (Select TWO.)

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: A,E is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Set rds.global_db_rpo to 60 in a custom DB cluster parameter group, and apply that parameter group to the primary cluster.Your answerB.Set rds.global_db_rpo to 60 in custom DB cluster parameter groups on both the primary and the secondary cluster so the limit also holds after a failover.Sets the limit where it backfires. With only two Regions, AWS recommends keeping the default value in the secondary Region's parameter group, because after a failover the promoted cluster has no secondary within the limit and pauses transactions.Your answerC.Create a CloudWatch alarm that notifies operators when global database replication lag passes 60 seconds.Watches the lag instead of bounding it. An alarm reports that the limit was passed and does nothing to stop transactions committing beyond it.Your answerD.Turn on write forwarding for the secondary cluster so that every write is applied in both Regions before it commits on the primary.Misreads write forwarding. It sends writes from a secondary cluster to the primary's writer and does not make commits wait for another Region.Your answerE.Connect the application through the Aurora Global Database writer endpoint, which Aurora updates to follow the primary cluster.

   Show the full explanation and doc quotes

   The disaster recovery page says that with an Aurora PostgreSQL-based global database "you can manage the recovery point objective (RPO) for your Aurora global database by using the rds.global_db_rpo parameter." Where the parameter goes is the deciding behaviour. The same page warns: "In a global database with only two AWS Regions, we recommend keeping the rds.global_db_rpo parameter's default value in the secondary Region's parameter group. Otherwise, performing a failover due to a loss of the primary AWS Region could cause Aurora to pause transactions." That rules out B for a company whose new primary must accept writes at once. For E, the connection page says the global writer endpoint is "automatically updated by Aurora to route requests to the current writer instance of the primary DB cluster."

   Written from docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html

3. An Aurora global database has its primary cluster in one Region and a secondary in another. A team deploys its application to the secondary Region for local reads, and a small part of that application must also insert rows. The primary must stay where it is, and the team does not want a second database to reconcile. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design Resilient Architectures building.

   Not that one: A is right. In the game your Design Resilient Architectures building would lose a little Renown, and this question would come back later.

   The answerA.Turn on write forwarding for the secondary cluster, so that the writes it receives are sent to the primary cluster.The secondary cannot be made writable, and the feature that makes it look writable exists. "Only the primary cluster performs write operations. Clients that perform write operations connect to the Aurora Global Database writer endpoint, which always points to the writer DB instance of the primary cluster", and for this case the documentation offers write forwarding: "By using the write forwarding feature, you can also configure your global database so that secondary clusters send write requests to the primary." The instinct to add a writer instance runs into the read-only property of the secondary, which the page states while explaining why a secondary supports one more reader than a standalone cluster.Your answerB.Perform a switchover to the secondary Region, which relocates the primary cluster with no data loss.Moves the problem to the other Region and the requirement says the primary stays.Your answerC.Add a writer DB instance to the secondary cluster, so the application in that Region can insert rows locally.A secondary cluster is read-only. "The secondary cluster is read-only, so it can support up to 16 read-only DB instances rather than the usual limit of 15" - there is no writer to add.Your answerD.Point the inserting component at the Aurora Global Database writer endpoint across Regions and accept the latency.Works, and makes the application manage two endpoints and their cross-Region latency by hand, which is the work write forwarding does for it.

   Written from docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html