Amazon Aurora cluster endpoint

0

Hi AWS, I need to confirm answer for this question:

A company is using an Amazon Aurora cluster as the data store for its application. The Aurora cluster is configured with a single DB instance. The application performs read and write operations on the database by using the cluster's instance endpoint. The company has scheduled an update to be applied to the cluster during an upcoming maintenance window. The cluster must remain available with the least possible interruption during the maintenance window. What should a DevOps engineer do to meet these requirements?

  1. Add a reader instance to the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster's reader endpoint for reads.
  2. Add a reader instance to the Aurora cluster. Create a custom ANY endpoint for the cluster. Update the application to use the Aurora cluster's custom ANY endpoint for read and write operations.
  3. Turn on the Multi-AZ option on the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster’s reader endpoint for reads.
  4. Turn on the Multi-AZ option on the Aurora cluster. Create a custom ANY endpoint for the cluster. Update the application to use the Aurora cluster's custom ANY endpoint for read and write operation.

According to me it should be option (A), as Amazon'sMulti-AZ option must be set when the DB instance is created, and in case you want to make an existing Aurora cluster into Multi-AZ cluster you need to a new reader instance and specifying a different AZ. Also Aurora cluster provides cluster read and write endpoints but doesn't support creating custom ANY endpoints.

As per the votes, option (C) is also marked by as answer by many.

Can you please confirm.

  • please accept the answer if it was useful

  • You can't turn on Multi-AZ on an existing Aurara Cluster, which rules out answers 3 and 4. I've never heard of "ANY endpoint", so the only plausible answer is 1.

2 Risposte
1

Your reasoning is correct. Option A is the most appropriate and aligns with best practices for minimizing downtime and ensuring availability during maintenance. The votes for Option C might stem from a misunderstanding of how Multi-AZ works or the specific configuration steps involved.

If you follow Option A, you ensure that your application can handle read and write operations efficiently during the maintenance window with minimal interruption.

profile picture
ESPERTO
con risposta 4 mesi fa
profile picture
ESPERTO
verificato 4 mesi fa
0

Hi... I wanted to add some clarity around your specific question related to minimizing downtime for maintenance activities. Generally, this will depend on the type of maintenance (e.g., database upgrade, OS upgrade, etc.).

Aurora's shared storage architecture has many benefits but one of its challenges is that database engine upgrades must occur across all db-instances at the same time. This is not too bad for backward-compatible minor versions and database engine patches because we have invested a lot into the low-downtime patching and faster restarts using a technique we call "zero downtime patching" (ZDP). While we don't quite live up to the name yet, we are able to maintain most app connections across the upgrade and get it all done in "low double-digit" seconds once the upgrade begins. For more info on ZDP, please see the docs at the link [1] below.

Major version upgrades and some Aurora MySQL minor version upgrades are not guaranteed by the respective open source community to be backward compatible so we have built a "managed blue/green" approach to reduce downtime. In Aurora database engines, we use storage clones to create the "green" deployment while your existing workload continues to operate as normal against the original and now known as the "blue" deployment. We instantiate and start a native replication technique that queues committed transactions in the blue deployment such that they can be replicated to the newly upgraded green deployment in advance of the cutover. For more info on Blue/Green Deployments, please see the docs at the link [2] below.

Operating system updates are performed at an instance level so it is possible to perform "rolling upgrades" through all the instances in the cluster one at a time. As long as your application uses the "cluster endpoint" for connecting to the writer and the "reader endpoint" for connecting to a read-only instance, we handle all the DNS manipulation behind the scenes so connections are routed to the proper instance. Typically you would perform the OS upgrade on all the read-only instances first and then when you need to do the writer, you would "failover" the writer role to one of the read-only instances. The old writer then becomes a read-only instance which you can then perform the OS upgrade on it with minimal impact to your running workload.

Hope this is all helpful...

Links:

[1] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ZDP.html ;

[2] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html ;

[3] - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#OS_Updates ;

AWS
con risposta 4 mesi fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande