Amazon Aurora goes Multi-AZ

Index

• TL;DR
• Objective
• Benefits
• Problem
• Solution

TL;DR

In order to create a db cluster in front of your multi-az db instances, I found the best way to do that using Route53 Dns records to point to the cluster and hit the dns from my component.

Objective

Amazon RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ).

Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention.

Benefits

Following some benefits of using multi-az databases from database and components perspectives:

• Enhanced durability: if a storage volume on your primary fails in a Multi-AZ deployment, Amazon RDS automatically initiates a failover to the up-to-date standby. Compare this to a Single-AZ deployment where in case of failure, a user restore operation will be required (can take several hours to complete and any data updates that occurred after the latest restorable time will not be available).
• Increased availability: if an Availability Zone failure or DB Instance failure occurs, your availability impact is limited to the time automatic failover takes to complete: typically under one minute for Amazon Aurora and one to two minutes for other database engines. The availability benefits of Multi-AZ deployments also extend to planned maintenance and backups. In the case of system upgrades like OS patching or DB Instance scaling, these operations are applied first on the standby, prior to the automatic failover. As a result, your availability impact is, again, only the time required for automatic failover to complete.
• No administrative intervention: DB Instance failover is fully automatic and requires no administrative intervention. Amazon RDS monitors the health of your primary and standbys, and initiates a failover automatically in response to a variety of failure conditions.
• Simplify your component: Because you will hit a dns record, there’s no need to use the AWS SDK to discover db clusters/instances anymore. You will end up with cleaner code and no dependency to the Amazon API.

Problem

We start from an app running with a single db and we move to a single cluster pointing to several db instances in different availability zones.

The main problem we had when setting up the Aurora Db Cluster was the lack of support when dealing with clusters from both cloudformation and the app perspective:

• From the app:
• On one hand, after spin up the cluster, it was difficult for us to find the endpoint using the AWS SDK. Apparently AWS crops the cluster identifier to something equal or less to 64 characters so you don’t know how it will look like.
• On the other hand, the aws sdk client does not support filtering and provides results with pagination which makes things more complicated.
• From cloudformation:
• Cluster identifiers cannot be defined from the CF templates.

Solution

We came up with a very straight-forward solution after the discovery process which is basically set up a DNS record in front of the db cluster. This way we can have our app pointing to the dns and no needs to worry about finding the cluster through the sdk.

Please see here a couple of code snippets to enable multi-AZ in you environment:

• To create the db replica and point the cluster to you main instance

• To create the dns record pointing to the cluster