Amazon RDS - Multi-AZ Deployments For Enhanced Availability & Reliability

Amazon RDS simplifies many of the common tasks associated with the deployment, operation, and scaling of a relational database. You don't have to worry about acquiring and installing hardware, loading an operating system, installing and configuring MySQL, or managing backups. In addition, scaling the processing power or storage space available to your database is as simple as an API call.

When we rolled out Amazon RDS last October, we also announced plans to have a "High Availability" option in the future. That option is now ready for you to use, and it's called "Multi-AZ Deployments." AZ is short for "Availability Zone"; each of the four AWS Regions is comprised or two or more such zones, each with independent power, cooling, and network connectivity.

The availability and reliability characteristics of Multi-AZ deployments make them well suited for critical production environments.  I'd like to tell you about this new feature and how it works; here's a diagram to get you started:

It is really easy to benefit from the enhanced availability and data durability provided by a DB Instance deployment that spans multiple Availability Zones. All you need to do is supply one additional parameter to the CreateDBInstance function and Amazon RDS will take care of the rest.

To be more specific, when you launch a DB Instance with the “Multi-AZ” parameter set to true, Amazon RDS will create a primary in one Availability Zone, and a hot standby in a second Availability Zone in the same Region. Data written to the primary will be synchronously replicated to the standby. If the primary fails, the standby becomes the primary and a new standby is created automatically. Amazon RDS automatically detects failure and takes care of all of this for you. The entire failover process takes approximately about three minutes. In addition, existing standard DB Instance deployments can be converted to Multi-AZ deployments by changing the Multi-AZ parameter to true with the ModifyDBInstance function (a hot standby will be created for your current primary).

When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your MySQL client library should be able to close and reopen the connection in the event of a failover. If your application needs to know that a failover has occurred, you can use the function to check for the appropriate event.

If you have set up an Amazon RDS DB Instance as a Multi-AZ deployment, automated backups are taken from the standby to enhance DB Instance availability (by avoiding I/O suspension on the primary). The standby also plays an important role in patching and DB Instance scaling. In order to minimize downtime during planned maintenance, patches are installed on the standby and then an automatic failover makes the standby into the new primary. Similarly, scaling to a larger DB Instance type takes place on the standby, followed by an automatic failover.

Multi-AZ deployments also offer enhanced data protection and reliability in unlikely failure modes. For example, in the unlikely event a storage volume backing a Multi-AZ DB Instance fails, you are not required to initiate a Point-in-Time restore to the LatestRestorableTime (typically five minutes prior the failure). Instead, Amazon RDS will simply detect that failure and promote the hot standby where all database updates are intact.

Putting it all together, this new feature means that your AWS-powered application can remain running in the face of a disk, DB Instance, or Availability Zone failure. Once again, you can focus on your application and let AWS handle the "dirty work" for you.

While you cannot use the synchronous standby in a Multi-AZ deployment to serve read traffic, we are also working on a Read Replica feature.  This feature will make it easier to take advantage of MySQL’s built-in asynchronous replication functionality if you need to scale your read traffic beyond the capacity of a single DB Instance. You'll be able to provision multiple "Read Replicas" for a given source DB Instance.

-- Jeff;

Comments

[Josh]

Jay Finally! Pricing? Reserved Instances? :-)

[Josh]

Now there are just two more "missing links" to build massively scalable webapps with minimal setup and maintenance effort.

we need:
a) the read replica feature (already announced in this blog post)
b) CDN-like hosting of dynamic content

let me explain b) a bit:
you offer a very scalable hosting for static content via S3, which is even more scalable via your CDN features.

what i am dreaming of is a "S3 like offer" for dynamic content.
so instead of launching and configuring a EC2 instance, we'd love to fire up a "php-S3" or a "python-S3" or whatever language it may be.

This would be in line with RDS (offer on "application level" instead of "server level" and take away the ugly server setup and administration from developers and startups).

"php5-fpm via nginx on S3" would be cool! ;-)

[Cloudcontroller]

Jay- this sounds like MySQL Multi-Master - if so good choice!

[Josh]

Unfortunately Amazon still completely fails to use this blog as a two way street and instead just posts press releases which are "styled" as blog posts. :-/

Cool companies REPLY to blog comments!

[Jeff Barr]

Hi Josh -- I reply to about 90% of the comments offline, and usually within an hour or two. Leave me an email address and I will get back to you ASAP.

[Josh]

Jeff,
thanks for replying in here and pointing out that you usually reply to comments offline. Thats good, but I don't really get the rationale behind it. This is a blog after all... The idea of a blog is to do these things in public, so that other readers benefit from this discussion.

Either you have something to say which would be useful for other users, too (and which i'd post here or elsewhere anyway) or your only answer would be "We don't comment on future features and have no release date yet" in which case it wouldn't be worth the effort to answer offline.

[Jeff Barr]

Josh, point taken and I'll try to do a better job of conducting a discussion within the comments.

There are two other types of replies that I can't post in public:

"That's a great idea, we're giving it some thought, can I introduce you to the product team so that they can learn more about your needs?"

"That's a great idea, we have something in private beta now, let me see if I can get you NDA'ed so that we can tell you more!"

[Josh]

Jeff,

oh snap! I missed those two possibilities - my fault!
Glad to see that Amazon really takes this user feedback serious!
Even these comments are moderated, they were posted anyway.
Guess we'll send you an email in the next couple of days.

Thanks again!

[Helen]

Hi Josh,

AWS is having a seminar on July 20th, Sofitel Los Angeles,8555 Beverly Blvd., Los Angeles, CA 90048

Agenda:
1:00pm – 1:30pm: Doors Open + Partner & Solutions Expo
1:30pm – 2:20pm: AWS Overview-Dr. Werner Vogels, Amazon CTO
2:20pm – 3:20pm: Customer Presentations & Q&A
10 minute break
3:30pm – 4:00pm: Architecting Enterprise Applications in the Cloud
4:00pm – 4:30pm: Security in the AWS Cloud
4:30pm – 5:00pm: Amazon IT Deployment in the AWS Cloud
5:00pm – 7:00pm: Networking/Cocktail Reception

Hopefully your in the Los Angeles area and can be there for any of your questions to be answered. My husband and I will be there. Come and say "HI"

[Dave]

I know I am a bit late to this posting, but we are currently thinking of migrating to a hybrid MySQL Cluster approach in a HA scenario. I have read elsewhere that there is a 1TB limit for storage per instance - given various scaling options is there a limit on transaction throughput we still need to worry about (we are running at 1K/sec range right now - but always expanding)?