Amazon RDS is a managed relational database service that makes it easier to set up, operate, and scale a relational database in the cloud. One of the common questions that we get is “What is Multi-AZ and how it’s different from Read Replica, do I need both?”. I have tried to answer this question in this blog post and it depends on your application needs. Are you looking for High Availability (HA), read scalability … or both?
Before we go to into detail, let me explain two common terms used with Amazon AWS.
Region – an AWS region is a separate geographical area like US East (N. Virginia), Asia Pacific (Mumbai), EU (London) etc. Each AWS Region has multiple, isolated locations known as Availability Zones.
Availability Zone (AZ) – AZ is simply one or more data centers, each with redundant power, networking and connectivity, housed in separate facilities. Data centers are geographically isolated within the same region.
What is Multi-AZ?
Amazon RDS provides high availability and failover support for DB instances using Multi-AZ deployments.
In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica of the master DB in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to the standby replica to provide data redundancy, failover support and to minimize latency during system backups. In the event of planned database maintenance, DB instance failure, or an AZ failure of your primary DB instance, Amazon RDS automatically performs a failover to the standby so that database operations can resume quickly without administrative intervention.
You can check in the AWS management console if a database instance is configured as Multi-AZ. Select the RDS service, click on the DB instance and review the details section.
This screenshot from AWS management console (above) shows that the database is hosted as Multi-AZ deployment and the standby replica is deployed in us-east-1a AZ.
Benefits of Multi-AZ deployment:
- Replication to a standby replica is synchronous which is highly durable.
- When a problem is detected on the primary instance, it will automatically failover to the standby in the following conditions:
- The primary DB instance fails
- An Availability Zone outage
- The DB instance server type is changed
- The operating system of the DB instance is undergoing software patching.
- A manual failover of the DB instance was initiated using Reboot with failover.
- The endpoint of the DB instance remains the same after a failover, the application can resume database operations without manual intervention.
- If a failure occurs, your availability impact is limited to the time that the automatic failover takes to complete. This helps to achieve increased availability.
- It reduces the impact of maintenance. RDS performs maintenance on the standby first, promotes the standby to primary master, and then performs maintenance on the old master which is now a standby replica.
- To prevent any negative impact of the backup process on performance, Amazon RDS creates a backup from the standby replica.
Amazon RDS does not failover automatically in response to database operations such as long-running queries, deadlocks or database corruption errors. Also, the Multi-AZ deployments are limited to a single region only, cross-region Multi-AZ is not currently supported.
Can I use an RDS standby replica for read scaling?
The Multi-AZ deployments are not a read scaling solution, you cannot use a standby replica to serve read traffic. Multi-AZ maintains a standby replica for HA/failover. It is available for use only when RDS promotes the standby instance as the primary. To service read-only traffic, you should use a Read Replica instead.
What is Read Replica?
Read replicas allow you to have a read-only copy of your database.
When you create a Read Replica, you first specify an existing DB instance as the source. Then Amazon RDS takes a snapshot of the source instance and creates a read-only instance from the snapshot. You can use MySQL native asynchronous replication to keep Read Replica up-to-date with the changes. The source DB must have automatic backups enabled for setting up read replica.
Benefits of Read Replica
- Read Replica helps in decreasing load on the primary DB by serving read-only traffic.
- A Read Replica can be manually promoted as a standalone database instance.
- You can create Read Replicas within AZ, Cross-AZ or Cross-Region.
- You can have up to five Read Replicas per master, each with own DNS endpoint. Unlike a Multi-AZ standby replica, you can connect to each Read Replica and use them for read scaling.
- You can have Read Replicas of Read Replicas.
- Read Replicas can be Multi-AZ enabled.
- You can use Read Replicas to take logical backups (mysqldump/mydumper) if you want to store the backups externally to RDS.
- Read Replica helps to maintain a copy of databases in a different region for disaster recovery.
At AWS re:Invent 2017, AWS announced the preview for Amazon Aurora Multi-Master, this will allow users to create multiple Aurora writer nodes and helps in scaling reads/writes across multiple AZs. You can sign up for preview here.
Conclusion
While both (Multi-AZ and Read replica) maintain a copy of database but they are different in nature. Use Multi-AZ deployments for High Availability and Read Replica for read scalability. You can further set up a cross-region read replica for disaster recovery.
You May Also Like
ProxySQL provides a very good alternative to standard cluster access. It’s also equipped with more controls, options and close-to-application caching. ProxySQL 2.0 even supports AWS Aurora. Click here to learn how to implement the proxy with the relational database. Click here to see how you can leverage ProxySQL with Aurora to achieve better results compared to using the database’s default cluster endpoint.
If your business is looking to scale in the cloud, download our solution brief to see how setting up MySQL Amazon RDS instances can help your business address its growing needs and avoid unnecessary growing pains.