DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Because the DevOps movement has redefined engineering responsibilities, SREs now have to become stewards of observability strategy.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Related

  • Finding the Right Database Solution: A Comprehensive Comparison of AWS RDS MySQL and Aurora MySQL
  • Useful System Table Queries in Relational Databases
  • PostgreSQL 12 End of Life: What to Know and How to Prepare
  • How to Repair Corrupt MySQL Database Tables Step-by-Step

Trending

  • Intro to RAG: Foundations of Retrieval Augmented Generation, Part 2
  • Security by Design: Building Full-Stack Applications With DevSecOps
  • Web Crawling for RAG With Crawl4AI
  • MySQL Formatter: How to Make Beautiful Code and Why You Need It
  1. DZone
  2. Data Engineering
  3. Databases
  4. AWS Multi-Region Resiliency Aurora MySQL Global DB With Headless Clusters

AWS Multi-Region Resiliency Aurora MySQL Global DB With Headless Clusters

In this article, the reader will learn how to perform a failover with a headless Aurora Global Database and its outcomes.

By 
Shiva Jayam user avatar
Shiva Jayam
·
May. 18, 23 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
5.4K Views

Join the DZone community and get the full member experience.

Join For Free

A headless cluster in Amazon Aurora global database refers to a cluster that has no database instance attached to it. In other words, the cluster only includes the database storage and is used as a backup in case of a failure of the primary cluster. The primary cluster is the one that has a database instance attached to it and is serving the application's read and write requests. The headless secondary cluster is used for disaster recovery and to provide high availability for the database. The data in the primary cluster is automatically replicated to the headless secondary cluster, so in case of a failure, the secondary cluster can take over as the primary cluster and provide a seamless transition with minimal disruption.  

DB Cluster

In this article, we will see how to perform a failover with a headless Aurora Global Database and its outcomes. 

Steps To Create Aurora Global Database

I’ve created an RDS database (named "testaurocluster") and created a global cluster using the AWS CLI using the following commands: 

Create a Global Cluster

 
aws rds create-global-cluster --region us-east-1 \ 

--global-cluster-identifier global-cluster \ 

--source-db-cluster-identifier arn:aws:rds:us-east-1:<AWSAccountId>:cluster:testaurocluster


Create a Headless Secondary Cluster

Textile
 
aws rds create-db-cluster \ 

--region us-west-1 \ 

--source-region us-east-1 \ 

--db-cluster-identifier testaurocluster\ 

--global-cluster-identifier global-cluster \ 

--engine aurora-mysql \ 

--engine-version 5.7.mysql_aurora.2.10.2 \ 

--kms-key-id <key value>  


KMS Key

Make sure you used the correct KMS key before running the above command. (The KMS key should belong to the region where you are going to create the secondary cluster, i.e., us-west-1). 

Cloud Watch Metric Health Check

Create a CloudWatch metric for health checks: 

  • Log in to the Amazon Web Services (AWS) Management Console. 
  • Navigate to the RDS service.
  • Select the RDS cluster you want to monitor. 
  • Click on the "Metrics" tab. 
  • Click on the "Create Alarm" button. 
  • Select the "RDS" namespace and the "DBInstanceIdentifier" dimension. 
  • Choose the metric (e.g., CPUUtilization). 
  • Set the alarm threshold (e.g., greater than or equal to 75%). 
  • Choose the desired alarm actions (e.g., sending an SNS notification). 
  • Give the alarm a name and description (optional). 
  • Click the "Create Alarm" button.  

Your CloudWatch metric for CPU utilization of the RDS cluster is now set up. The alarm will trigger the specified actions if the CPU utilization exceeds the threshold. 

Health Check Using Route 53

  • Log in to the Amazon Route 53 console. 
  • Choose "Health checks" from the navigation panel. 
  • Choose "Create health check." 
  • Give your health check a name and choose "CloudWatch Alarm" as the type. 
  • Choose the appropriate alarm from the list. The alarm should reflect the health of your RDS cluster. 
  • Choose "Create." 
  • Once the health check has been created, you can use it in a Route 53 record set to route traffic to your RDS cluster.

This will allow Route 53 to monitor the state of the CloudWatch alarm and redirect traffic to a healthy endpoint if one of your instances becomes unavailable. The state of the CloudWatch alarm should reflect the health of your RDS cluster, so you will need to set up the alarm appropriately in CloudWatch.  

Route53 Hosted Zone

Create a Route53 Hosted Zone: 

  • Open the Route 53 management console in the AWS Management Console. 
  • In the navigation pane, choose "Hosted zones." 
  • Choose "Create Hosted Zone." 
  • In the "Create Hosted Zone" dialog box, enter a domain name for the hosted zone. 
  • Choose "Create" 

Create a DNS Record for the DB Cluster:

  • In the Route 53 management console, select the hosted zone that you created in Step 2. 
  • Choose "Create Record. " Add the record’s name. 
  • In the "Create Record " dialog box, set the type of record to "A" or "CNAME," depending on your use case. 
  • Check the alias button and fill in the option as required. Choose the endpoint and enter the endpoint of the cluster in the field. 
  • Select failover as a route policy and choose failover record type as primary. Add the health check ID that was created in the previous step. Give a name to record the ID.  
  • Click on add record button and add one more record for a secondary cluster. 
  • Choose "Create"  

Pre-Failover Step

Before proceeding with failover, you must add a DB instance to an existing headless cluster in the secondary region. After a failover, the headless secondary cluster becomes the primary cluster and takes over the role of serving the read and write requests from the application. 

It needs to configure the new database instance with the necessary settings, such as the database engine type, storage type, and instance size, and then connect it to your application. 

It is important to have a well-defined disaster recovery plan in place to ensure that you can quickly and effectively respond to a failover event.  

Using the AWS CLI command to add a DB instance to an existing headless cluster in the secondary region: 

Textile
 
aws rds create-db-instance \ 

--db-instance-identifier testaurocluster-instance-1 \ 

--db-cluster-identifier testaurocluster\ 

--db-instance-class db.r5.large \ 

--engine aurora-mysql \ 

--region us-west-1


CloudWatch Dashboard

Create a CloudWatch dashboard to check the metrics over time and quickly see any changes or trends in performance after deleting the read instance. 

  1. Log in to the AWS Management Console. 
  2. Navigate to the CloudWatch service. 
  3. Click on "Dashboards" in the left navigation panel. 
  4. Click on the "Create dashboard" button. 
  5. Give the dashboard a name and choose a preferred layout. 
  6. Click on the "Add widget" button to add the relevant metrics to the dashboard. 
  7. Select the metrics you want to add and set the desired time range for them. 
  8. Customize the appearance of the widget if desired, such as adding a title, axis labels, and legend. 
  9. Click on the "Save dashboard" button to save the dashboard.  

Failover Process Steps

  1. Navigate to the RDS Console and select the target global database for which you want to perform a failover. 
  2. Initiate a failover. You will be prompted to select a target instance to which to perform the failover. 
  3. After the failover is initiated, you can verify that it has been completed by checking the status of the target instance in the RDS Console. The target instance should now be in the "available" state, and the original primary instance should now be in the "failover" state. 
  4. Monitor the failover: After the failover is complete, it is important to monitor the performance of the new primary instance to ensure that it is serving traffic as expected. This can be done through Amazon CloudWatch, or by monitoring the performance of your application.  

Failover Time

It took a few minutes to complete the failover process (time can be tracked using RDS event logs). However, the failover of a global Amazon Aurora cluster can take anywhere from a few minutes to several hours, depending on the following factors.  

  1. Network latency (the time it takes to redirect traffic from the primary cluster to the secondary cluster will depend on the network latency between the two clusters). 
  2. Size of the database (larger databases will take longer to failover than smaller databases). 
  3. Performance of the secondary cluster (performance of the secondary cluster, as a slower secondary cluster will take longer to start serving traffic than a faster secondary cluster). 
  4. Application requirements (specific requirements of your application, such as the amount of data that needs to be recovered or the number of updates that need to be made to your DNS records). 

In the secondary (previously headless) Amazon Aurora database cluster, there is only one instance. When the secondary cluster becomes the primary cluster after a failover, this single instance acts as both the reader and writer instances. It serves to read requests from the application and updates the database, making it the new primary writer instance. 

It's important to note that in Amazon Aurora, the reader and writer instances are separate and can be managed independently, even in the same cluster. However, in the case of a headless secondary cluster, there is only one instance that acts as both the reader and writer. This single instance is designed to provide a cost-effective solution for disaster recovery, as it eliminates the need for a separate reader instance in the secondary cluster. 

Conclusion

In conclusion, performing a failover with a headless Aurora Global Database can provide significant benefits for achieving cost-effective multi-region resiliency. 

Amazon Aurora Database MySQL cluster

Opinions expressed by DZone contributors are their own.

Related

  • Finding the Right Database Solution: A Comprehensive Comparison of AWS RDS MySQL and Aurora MySQL
  • Useful System Table Queries in Relational Databases
  • PostgreSQL 12 End of Life: What to Know and How to Prepare
  • How to Repair Corrupt MySQL Database Tables Step-by-Step

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!