Amazon RDS Multi-AZ with one standby
Last updated
Last updated
Support high availability for your application with automatic database failover that completes as quickly as 60 seconds with zero data loss and no manual intervention.
Avoid suspending I/O activity on your primary during backup by backing up from your standby instance.
Use Amazon RDS Multi-AZ synchronous replication technologies to keep data on your standby database instance up to date with the primary.
Enhance availability by deploying a standby instance in a second AZ, and achieve fault tolerance in the event of an AZ or database instance failure.
In an Amazon RDS Multi-AZ deployment, Amazon RDS automatically creates a primary database (DB) instance and synchronously replicates the data to an instance in a different AZ. When it detects a failure, Amazon RDS automatically fails over to a standby instance without manual intervention.
Automatically fail over in typically under 35 seconds
Use separate endpoints for reads and writes
Gain up to 2x faster transaction commit latency
Increase read capacity
Automatically failover in typically under 35 seconds with zero data loss and with no manual intervention.
Route queries to write servers and appropriate read replica standby instances to maximize performance and scalability.
Achieve up to 2x improved write latency compared to Multi-AZ with one standby.
Gain read scalability by distributing traffic across two readable standby instances.
Deploy highly available, durable MySQL or PostgreSQL databases in three AZs using Amazon RDS Multi-AZ with two readable standbys. Gain automatic failovers in typically under 35 seconds, up to 2x faster transaction commit latency compared to Amazon RDS Multi-AZ with one standby, additional read capacity, and a choice of AWS Graviton2– or Intel–based instances for compute.
Amazon RDS Multi-AZ deployments provide enhanced availability and durability for your Amazon RDS database (DB) instances, making them a natural fit for production database workloads. With two different deployment options, you can customize your workloads for the availability they need.
Amazon RDS Single-AZ or Amazon RDS Multi-AZ with one standby or Amazon RDS Multi-AZ with two readable standbys
Feature
Single-AZ
Multi-AZ with one standby
Multi-AZ with two readable standbys
Available engines
Amazon RDS for MariaDB
Amazon RDS for MySQL
Amazon RDS for PostgreSQL
Amazon RDS for Oracle
Amazon RDS for SQL Server
Amazon RDS for MariaDB
Amazon RDS for MySQL
Amazon RDS for PostgreSQL
Amazon RDS for Oracle
Amazon RDS for SQL Server
Amazon RDS for PostgreSQL
Amazon RDS for MySQL
Additional Read capacity
None: the read capacity is limited to your primary
None: Your standby DB instance is only a passive failover target for high availability
Two standby DB instances act as failover targets and serve read traffic
Read capacity is determined by the overhead of write transactions from the primary
·
Lower latency (higher throughput) for transaction commits
Up to 2x faster transaction commits compared to Amazon RDS Multi-AZ with one standby
Automatic failover duration
Not available: a user, a user-initiated point-in-time-restore operation will be required.
This operation can take several hours to complete
Any data updates that occurred after the latest restorable time (typically within the last 5 minutes) will not be available
A new primary is available to serve your new workload in as quickly as 60 seconds
Failover time is independent of write throughput
A new primary is available to serve your new workload in typically under 35 seconds
Failover time depends on length of replica lag
Higher resiliency to AZ outage
None: in the event of an AZ failure, your risk data loss and hours of failover time
In the event of an AZ failure, your workload will automatically failover to the up-to-date standby
In the event of a failure, one of the two remaining standbys will takeover and serve the workload (writes) from the primary
Lower jitter for transaction commits
No optimization for jitter
Sensitive to impairments on the write path
Uses the 2-of-3 write quorum: insensitive to up to one impaired write path
