Multi-AZ and Read Replicas in Amazon RDS Databases

 

Multi-AZ and Read Replicas in Amazon RDS Databases

Author: Donatien MBADI OUM, Database Solution Architect | Oracle | AWS |Azure

 

1.    Overview

Amazon RDS (Relational Database Service) is a fully managed database service that makes easy to set up, operate and scale relational database in the cloud. RDS supports seven different database engine including Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, Amazon Aurora with MySQL Compatibility and Amazon Aurora with PostgreSQL comnpatibility.

When you are planning your database in production environment, it’s important to include high availability to avoid a single point of failure in the event of an Availability Zone (AZ) failure. This is called a Multi-AZ architecture. Multi-AZ provides a high availability and helps for durability and fault tolerance and it’s not used for scaling purposes because the second instance in Multi-AZ is a standby instance and it’s not take active reads and writes. That why, to reduce latency for high read and write applications, you must use read replicas in the high availability setup. So, use Multi-AZ deployments for high availability/failover and Read Replicas for read scalability.

 

2.    How Multi-AZ works

In Multi-AZ configuration, Amazon RDS provides availability within a single region and across multiple availability zones. A Multi-AZ deployment one Master database is created in one AZ and one Standby (or Secondary) database is created in another AZ. Only the master database serves writes and reads traffic and synchronous replication is operates between the Master database and the Standby Database over low latency links.

The standby instance is running as passive instance, so it doesn’t take active reads or writes. Where there is a planned or unplanned outage of AZ 1, there is an automatic failover to the standby instance. The standby instance will become active when the master instance fails for some reasons or goes down. Both of those instance have the same DNS name, so whenever the Master RDS goes down, RDS simply points the standby instance to the DNS name; this done in 60 to 120 seconds. So you don’t have to update your database connection strings. The failover scenario can be:

• -            Patching maintenance
• -            Failure in the availability zone
• -            Host failure
• -            DB instance class gets modified
• -            Instance rebooted with failure
• -        AWS triggers an event “RDS-EVENT-0025” when the failover is done (SNS notification possible)

 

3.    Benefits of Multi-AZ database deployment

-            Amazon RDS maintains a redundant and consistent standby copy of your data using synchronous storage replication, which is highly durable.

-            In case of failure, your availability impact is limited to time that automatic failover takes to complete, so you can resume database operations as quickly as possible without administrative intervention.

-            Endpoint of database instance remains the same after a failover, the application can resume database operations without manual intervention.

-            Amazon RDS automatically performs a failover in the event of loss of availability in the primary availability zone, loss of network connectivity, compute unit failure and storage failure.

-            Multi-AZ 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 provides you the option to simulate AZ failure by rebooting the master instance and choosing Reboot with failover option.

 

4.    How Read Replicas works

Amazon RDS Read Replicas enable you to create one or more read-only copies of your database instance within the same AWS Region or in a different region to increase scalability. The application is talking with the Master instance for all reads and writes and the read replica helps you to segregate a read-heavy workload.

You can create up to 5 Read Replicas, this can be Within AZ, Cross AZ or Cross Region and replication is asynchronous, so there will be some replication lag and then reads are eventually consistent. Replica lag is the difference in time between the latest transaction on the writer database instance and the latest applied transaction on a reader database instance.

All the Read replicas only support the read operations; the read and write operations until happened on Master instance and the application must update the connection string to use the read replicas because each read replica have their own endpoint.

To create a read replica, you must enable automatic backups with at least one retention period.

5.    Benefits of Read Replica database deployment

-            Read Replicas helps in decreasing load on the primary database by serving read-only traffic

-            You can promote a Read Replica database as standalone database instance

-            Read Replica supports Multi-AZ deployments

-            You can have Read replicas of Read replicas

-            You can use Read Replica to take logical backups if you want to store the backups externally to RDS.

-            You can use Read Replica to maintain a copy of databases in a different region for disaster recovery purpose.

-            You can use Read Replica for Business reporting or Data warehousing scenarios

-            You can scale beyond the compute or I/O capacity of a single database instance for read-heavy database workloads. You can direct this excess read traffic to one or more replicas.