Global Database manual nature of the failover not mentionned

[CharlesPopacere]

Hello,
Don’t know if this is the correct place but I have a slight issue with this question :
“A company is running its main web service in a fleet of Amazon EC2
instances in the us-east-1 AWS Region. The EC2 instances are launched by
an Auto Scaling group behind an Application Load Balancer (ALB). The
EC2 instances are spread across multiple Availability Zones. The MySQL
database is hosted on an Amazon EC2 instance in a private subnet. To
improve the resiliency of the web service in case of a disaster, the
Solutions Architect must design a data recovery strategy in another
region using the available AWS services to lessen the operational
overhead. The target RPO is less than a minute and the target RTO is
less than 5 minutes. The Solutions Architect has started to provision
the ALB and the Auto Scaling group on the us-west-2 region”

Neither the explanation or the accepted answer mentions that there is, as of today, no automated way of promoting a db with Aurora Global Databases.

Hence the accepted answer, while not being wrong, is missing the bit explaining that you would need someone to do the promotion manually. Or maybe some kind of healthcheck could trigger an Event that triggers a Lambda that would actually do it.

Without it, the current solution would not respect the specified RTO because the writes couldn’t happen.

Or keep the answer as is, but in the explanation part, emphasize that the solution still requires a mechanism (automated or manual) to promote the secondary database to primary in case of failover, right now it is not very explicit.

Also, and slightly unrelated, td would really benefit from being able to do those feedback directly from the question. If we can I didn’t find how to do so.

[Neil-TutorialsDojo]

Hello CharlesPopacere,

Good day!

Thank you for your insightful feedback.

As of now, Aurora Global Databases support managed failover in regional outages or other unplanned events, but this feature requires proper configuration to work effectively. Configuring the Aurora Global Database to manage failover is essential, as it can seamlessly promote a secondary region to a primary, minimizing downtime (RTO) and data loss (RPO). However, you may need to perform a manual failover in some scenarios. For instance, if your primary and secondary regions are running incompatible engine versions or automatic failover isn’t an option, manual intervention will be necessary to promote the secondary database to the primary.
I do understand that the explanation could have been more explicit. We will review this item and make the necessary adjustments.
Thank you again for helping improve the accuracy and completeness of this explanation.

Regards,
Neil @ Tutorials Dojo

[CharlesPopacere]

Hello Neil !

Thank you for your kind answer and detailed explanation.

Just to be sure I got this right for my upcoming exam, when you mention a supported managed way, are you talking about “Switchover – This operation was previously called “managed
planned failover” from https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html ?

Regards,
Charles

[Neil-TutorialsDojo]

Hello Charles,

Good day!

Thank you for your question. To clarify, Switchover is used in controlled scenarios, such as operational maintenance or planned procedures, where all Aurora clusters and the services they interact with are in a healthy state.

However, I was referring to the section in the documentation about managed unplanned failover, which is designed for disaster recovery scenarios. You can find more details here:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover.managed-unplanned

Best regards,
Neil @ Tutorials Dojo

[CharlesPopacere]

Hello !

I see the misunderstanding now.

When I was talking about “managed” or “automatic” failover, I was talking about it not needing any intervention to detect that it needs to switch, rather than the steps of said failover being managed for you, which is what the current “managed failover” is.

Per the doc you sent, it is indeed not the case. You still need some kind of mechanism to trigger the “managed” failover in case of regional failure, which can be done through the console, CLI or RDS API.

So it’s a good thing to keep in mind, it won’t self-heal like some other systems.

Thanks !

[Neil-TutorialsDojo]

Hello CharlesPopacere,

Thank you for sharing your thoughts. You’re correct that the “managed failover” for Aurora Global Databases requires an external mechanism to detect failures and initiate the failover process using the console, CLI, or RDS API.

Your feedback is invaluable and helps us refine explanations to ensure they are as accurate and comprehensive as possible. As mentioned, we’ll review this item and make the necessary adjustments.

Best regards,
Neil @ Tutorials Dojo