Amazon RDS Multi-AZ with one standby

Amazon RDS Multi-AZ with one standby

Automatic fail over	Protect database performance	Enhance durability	Increase availability
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.

How it works

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.

Amazon RDS Multi-AZ with two readable standbys

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.

How it works

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.

Introduction to Amazon RDS Multi-AZ

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.

Comparison Table

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