I did some reading to figure out the differences between Multi-Availability Zone deployments and Read Replicas of AWS's Relational Database Service, and here are some of my notes.
Multi-AZ Deployment
It is possible to set up secondary RDS instances in multiple availability zones within an AWS Region. The primary purpose of these secondary instances is to provide high availability. If the primary RDS instance fails, AWS will automatically promote one of the secondary instances to primary.
Last year, a recent announcement made it possible to set up an AZ secondary RDS in a Read-only mode. This provides additional read capacity and consistent transactional latency.
Setup
DB Discovery
A Multi-AZ deployment provides a single DNS name for the database. Upon promotion of the standby database, the DNS is automatically modified to point to the new primary. Therefore an application does not need to be reconfigured during failover, unless it caches the IP address that is resolved from the DNS Name.
Maintenance Lifecycle
OS Updates
As mentioned earlier, Multi-AZ RDS is highly available, which is also reflected when OS maintenance is required. The Standby DB is first updated and then promoted to the Primary DB during an OS update. The Primary DB is then updated and demoted to Standby DB.
DB Engine Updates
The exception to High Availability is when the underlying DB Engine needs to be updated. Here downtime is unavoidable, and both Primary and Standby instances need to be updated simultaneously.
Failover Reasons
There are multiple reasons why failover occurs -
- DB Instance Server Type Change
- OS Patching
- Manual Reboot with failover
- An outage in the primary's availability zone
- Primary DB Failure
Failover Tech
AWS RDS is an umbrella service for multiple DB types, and there are two distinct underlying technologies providing failover- AWS Failover tech
- MariaDB, MySql, Postgres, Oracle
- SQL Server DB Mirroring / Always on Availability Groups
- MS SQL Server
Replicas
Unlike Multi-AZ deployments, the primary goal of Read-Replicas is to provide scalability. Applications that only require read access can utilize the replicas.
A read replica can be manually promoted to a read/write if the read/write DB becomes unavailable. This however may require manually -
- Reconfiguring the write applications to point to the newly promoted DB, or
- Updating a DNS entry to point to the freshly promoted DB instance
Setup
A Read-Replica can be set up via the AWS Console or CLI. This does require a brief I/O Suspension, so it is recommended to stop all writes to the database. A snapshot of the DB is used to set up the Replica. Once the DB is started, data is replicated asynchronously to the Read Replicas.
Note - An encrypted DB's replicas will be encrypted too
A DB can have up to 5 Read Replicas
The Replicas can exist cross-region or in the same region as long as they belong to the same VPC.
