What's the impact of modifying my Single-AZ Amazon RDS instance to a Multi-AZ instance and vice versa?

Last updated: 2022-05-19

I want to know the impact of changing my Single-AZ Amazon Relational Database Service (Amazon RDS) DB instance to a Multi-AZ instance.

-or-

I want to know the impact of changing my Multi-AZ Amazon RDS DB instance to a Single-AZ instance.

Short description

In a Single-AZ setup, one Amazon RDS DB instance and one or more Amazon Elastic Block Store (Amazon EBS) storage volumes are deployed in one Availability Zones. In a Multi-AZ configuration, the DB instances and EBS storage volumes are deployed across two Availability Zones.

When you enable Multi-AZ on your instance, Amazon RDS maintains a redundant and consistent standby copy of your data using synchronous storage replication. Amazon RDS detects and then automatically recovers from the most common infrastructure failure scenarios for Multi-AZ deployments. This detection and recovery occurs so that you can resume database operations as quickly as possible. For more information, see High availability (Multi-AZ) for Amazon RDS.

To change a DB instance from Single-AZ deployment to a Multi-AZ deployment and vice versa, see Modifying an Amazon RDS instance.

Resolution

Impact of changing a Single-AZ instance to a Multi-AZ instance

When you change your Single-AZ instance to Multi-AZ, you don't experience any downtime on the instance. During the modification, Amazon RDS creates a snapshot of the instance's volumes. Then, this snapshot is used to create new volumes in another Availability Zone. Although these new volumes are immediately available for use, you might experience a performance impact. This impact occurs because the new volume's data is still loading from Amazon Simple Storage Service (Amazon S3). Meanwhile, the DB instance continues to load data in the background. This process, called lazy loading, might lead to elevated write latency and a performance impact during and after the modification process.

The amount of performance impact is a function of your volume type, workload, instance, and volume size. The impact might be significant for large write-intensive DB instances during the peak hours of operations. As a result, it's a best practice to test the impact on a test instance before running this modification in production. It's also a best practice to complete this modification in a maintenance or low-throughput window.

Reduce the duration of loading

To proactively reduce the duration and impact of the loading, do the following:

  1. Change the DB instance’s storage type to Provisioned IOPS. Be sure to provision an amount of IOPS that is substantially higher than your workload requires.
    Note: This step can cause a brief period of downtime if the instance uses a custom parameter group.
  2. Change the instance to Multi-AZ.
  3. Initiate a failover on your instance to be sure that the new AZ is the primary AZ.
  4. Run a full dump of the data on your instance. Or, run full table scan queries on the most active tables to expedite loading the data into the volumes.
  5. Confirm that the write latency has returned to normal levels by reviewing the WriteLatency metric in Amazon CloudWatch.
  6. Change the instance's storage type or IOPS back to your previous configuration.
    Note: This step doesn't require downtime.

Reduce latency if your instance is already Multi-AZ

To reduce the latency if you already modified the instance to Multi-AZ, do the following:

  1. Initiate a failover on your instance to be sure that the new AZ is the primary AZ.
  2. Change the DB instance’s storage type to Provisioned IOPS. Be sure to provision an amount of IOPS that is substantially higher than your workload requires.
    Note: This step doesn't require downtime.
  3. Run a full dump of the data on your instance. Or, run full table scan queries on the most active tables to expedite loading the data into the volumes.

  4. Confirm that the write latency has returned to normal levels by reviewing the WriteLatency metric in Amazon CloudWatch.

  5. Change the instance's storage type or IOPS back to your previous configuration.
    Note: This step doesn't require downtime.

If you change a DB instance from Single-AZ to Multi-AZ, then a standby instance is created with the same configuration in another Availability Zone. This leads to additional costs. Also, because Multi-AZ uses synchronous replication, writes are slightly slower than those in Single-AZ.

Impact of changing a Multi-AZ instance to a Single-AZ instance

When you change your instance from Multi-AZ to Single-AZ, you don't experience downtime on the instance. During the modification, Amazon RDS deletes only the secondary instance and volumes, and the primary instance isn't affected.

Here are a few things to consider before changing your instance from Multi-AZ to Single-AZ deployment:

  • With the Multi-AZ deployment, Amazon RDS automatically switches to the standby copy in another Availability Zone during a planned or unplanned outage of your DB instance. But, in a Single-AZ instance, you might have to initiate a point-in-time-restore operation. This operation might take several hours to complete. Any data updates that occurred after the latest restorable time aren't available. So, you might experience an additional downtime on a Single-AZ instance in case of a failure.
  • In a Multi-AZ instance, automated backups are created from the secondary instance during the automatic backup window. For Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle, and Amazon RDS for PostgreSQL, I/O activity isn't suspended on your primary instance during backup for Multi-AZ deployments because the backup is taken from the secondary. For Amazon RDS for SQL Server, I/O activity is suspended briefly during backup for Multi-AZ deployments. The backup process on a Single-AZ DB instance results in a brief I/O suspension that can last from a few seconds to a few minutes. The amount of time depends on the size and class of your DB instance.
  • In Multi-AZ deployments, operating system maintenance is applied to the secondary instance first. The secondary instance is promoted to primary, and then maintenance is performed on the old primary, which is the new standby. So, the downtime during certain OS patches in a Multi-AZ instance is minimal.
  • If you're scaling your Multi-AZ instance, then the downtime is minimal. This is because the secondary instance is modified first. The secondary instance is promoted to primary. Then, the old primary, now secondary instance, is modified. A Single-AZ instance becomes unavailable during the scaling operation.

Did this article help?


Do you need billing or technical support?