Amazon RDS Multi-AZ deployment with Read Replica

24 Nov 2014 Amazon RDS Multi-AZ deployment with Read Replica

Introducing Amazon RDS

Amazon Relational Database service, or as it’s known RDS, is a pre-packaged version of MySQL on Amazon services. Unlike it may seem, it’s not just an EC2 instance with MySQL installed on it. The difference between RDS and EC2 with MySQL is that, for RDS, no configurations or optimizations are required, upgrades and failovers are automatic, and high availability is guaranteed.

Multi-AZ

The high availability of RDS comes from enabling the Multi-AZ feature, where the master-slave model is used. On the deployment of Multi-AZ, a main DB instance – the master- is created and synced with a standby instance – the slave- in an adjacent availability zone. In case of Master’s failure, RDS automatically failover to the Slave, promoting it to be the new Master. In this case, the same DNS name used for the master is remapped to point to the salve, so that database operations can be resumed with no need for manual administration. Of course there will be some down time until failover is complete, therefore the database availability is limited to this down time.

However, there are certain cases when RDS performs automatic failover, which are – as mentioned in AWS documentation – :

• Loss of availability in primary Availability Zone.

• Loss of network connectivity to primary.

• Compute unit failure on primary.

• Storage failure on primary.

More advantages for Multi-AZ deployment appear in case of planned maintenance and backups. Since RDS synchronously replicate the master to the slave keeping it up-to-date. So the backup is taken from the slave before the failover process is performed.

The same happens in case of system upgrades and Database scaling – up or down – where operations are applied first to the slave, that is promoted to be the master by the failover process, so that no down-time occurs.

Read Replica

The read replica (RR) is a DB instance that accepts read-only connections, used to scale out a DB instance in case of read-intensive workload. It is asynchronously kept up-to-date, causing some lag. Note that, there can be more than one read replica for the same DB instance.

Amazon RDS allows the selected database engine to use its read replica feature. The RDS takes a snapshot of the pre-determined source DB instance to create the read replica.

Although the Multi-AZ deployment performs synchronous replication with the slave achieving high availability, the read replica feature can be used not as a replacement, but side-by-side with the Multi-AZ to enhance the availability and durability. The read replica can be created in one of the availability zones of the master, or one of the slaves, or even another availability zone to increase the redundancy. It can become a stand-alone instance, or even be promoted manually to be master in case of failover.

Sum Up

Amazon RDS Multi-AZ deployment with Read Replica guarantees high availability and durability, making the database suitable and ready for the production operations. Using this model instead of EC2 instances, saves a lot of time and effort; no configurations, no worry about replications and availability, and no administration overhead at all. This explains the huge difference in pricing.

However, like anything in the world, Amazon RDS has some drawbacks. But the main drawback is not having control over the DB instances; no direct access to those instances. This can be annoying to some, but this is it: a trade-off.