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:
- A customer-provided database service running within an Amazon Machine Image (AMI)
- Amazon Web Services own SimpleDB service
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.