InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Amazon RDS: MySQL Database as a Cloud Service

Posted by Carlos Armas on Dec 17, 2009

Sections
Architecture & Design,
Operations & Infrastructure
Topics
Operations ,
Architecture ,
Cloud Computing ,
Maintenance
Tags
Amazon RDS ,
Database Replication ,
MySQL ,
Amazon Web Services ,
Amazon SimpleDB

Amazon recently added a new MySQL database offering to their Amazon Web Services (AWS) platform named Amazon Relational Database Service (RDS), which works just like a traditional MySQL installation. Prior to RDS, customers had a couple of choices for database services within AWS:

SimpleDB is a simple data storage that lacks the sophistication of a full-fledged Relational Database Management System (RDBMS), while providing scalable key-value storage. A customer-provided database service in AWS is not too different from the traditional data center environment. The customer staff is in charge of managing the database application from configuration, to performance tuning, capacity management, version updates, patching, and data backup. It is possible to interact with the database using the same tools used to interact with traditional MySQL database setups.

Amazon RDS offloads from the customer's staff a number of routine MySQL maintenance operation tasks. It begins with hands-off database computing resources scalability, and performance monitoring. In addition, the database software is regularly patched by the provider, as well as data backups, which retention periods are defined by the customer. Scalability comes in with what AWS calls "instance classes", 5 of them total. It begins with a modest 1 virtual CPU core and 1.7 Gigabytes of memory, termed "Small DB Instance", all the way to a "Quadruple Extra Large DB Instance" with 68GB of memory and 8 virtual CPU cores. Backup storage comes free up to 100% of the space occupied by the active database data. Additional backup storage is provided for a fee, and the data is stored on a different availability zone than the instance is hosted at. This is equivalent to the familiar off-site data protection concept in traditional data safety models.

The service benefits come at a cost in flexibility. There is a weekly four-hour maintenance window defined by AWS. The maintenance window is used for application software patching, as well as data backups. Customers cannot opt-out of the patching process. However customers can specify when the maintenance window can occur within the week. The database instance is taken offline for certain period of time within the maintenance window. Amazon states "patching should seldom require more than a fraction of your maintenance window, occurs infrequently, and is used only for patches that are security or durability related".

This means that the customer should expect and plan for a weekly event of instance offline for such tasks. Although the provider states the four-hour window is not likely to be used in its entirety a customer should expect the worst-case scenario, a weekly four-hour instance downtime. For customers who can afford a relatively short term of database instance unavailability, scheduling downtimes at the time of week with the possible lowest impact could be an acceptable compromise. Some customers do not have the above freedom of choice. They need to guarantee service availability 24x7, even during weekly maintenance windows. In traditional database deployments database replication techniques are commonly used to achieve high availability. Can replication techniques be used within RDS, given customers can specify different maintenance windows for different database instances? For example, would it be possible to run:

  • Two or more instances in master-slave mode?
  • Two instances in master-master mode?
  • Two or more instances in cluster mode?

There are no clear answers at this moment. In the "New features coming soon" section of the RDS service details page Amazon anticipates the availability of data replication choices:

High Availability Offering — For developers and business who want additional resilience beyond the automated backups provided by Amazon RDS at no additional charge. With the high availability offer, developers and business can easily and cost-effectively provision synchronously replicated DB Instances in multiple availability zones (AZ’s), to protect against failure within a single location.

Which seems it would addresses availability via multiple availability zones, at a cost, in the coming future. But traditional techniques to address availability such as master-slave and master-master models are not available at this point to help.

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.