Moving AWS RDS from Single AZ To Multi AZ

Overview

Amazon Relational Database Service (RDS) is a fully managed database service that makes it easy to set up, operate, and scale relational databases in the cloud. Each Amazon RDS instance runs on a DB instance backed by an Amazon Elastic Block Store (Amazon EBS) volume for storage.
RDS supports seven different database engine that includes; Amazon Aurora with MySQL compatibility, Amazon Aurora with PostgreSQL compatibility, MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server.
For Production workload, it is very important to bake in high availability in database planning, to avoid single point of failure in the event of an availability zone failure and also to reduce latency for high write or read applications, by using read replicas in the high availability setup.
To ensure high availability, AWS RDS supports two different methods;

• RDS Multi-AZ deployments for MySQL, MariaDB, PostgreSQL,
  Oracle, and SQL Server engines.

• For Amazon Aurora engines, data can be replicated six ways
  in three different availability zones.
  In this article our focus will be on RDS Multi-AZ deployment (Postgres Engine)

Types of RDS setup

• Single-AZ Setup: In a Single-AZ setup, one RDS DB instance and one or more EBS storage volumes are deployed in one Availability Zone across data centre.

• Multi-AZ setup: In a Multi-AZ configuration, RDS DB instances and EBS storage volumes are deployed across multiple Availability Zones. A multi-AZ deployment has a Master database in one AZ and a Standby (or Secondary) database in another AZ. Only the Master database serves traffic. If the Master fails, then the Secondary takes over.

• Multi-AZ DB Cluster: A Multi-AZ DB cluster deployment is a high-availability deployment mode of Amazon RDS with two readable standby DB instances. A Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate Availability Zones in the same AWS Region. Multi-AZ DB clusters provide high availability, increased capacity for reading workloads, and lower write latency when compared to Multi-AZ DB instance deployments.

Benefits

Single-AZ database deployment;

• It is cost-efficient as you only pay for the database being used without bothering about the standby database

• It can function optimally and serve applications if there is no fault. It allows automatic backup as specified in the schedule.

• It is Ideal for the development environment as it helps save the cost of Development.

Multi-AZ database deployment;

• Amazon RDS maintains a redundant and consistent standby copy of your data using synchronous storage replication.
  Amazon RDS detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible without administrative 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.

• Having separate Availability Zones greatly reduces the likelihood that copies of database are concurrently affected by most types of disturbances and provides a highly available database architecture.

• There is Lower Latency with Multi-AZ deployment.

Multi-AZ Cluster database deployment;

• With a Multi-AZ DB cluster, Amazon RDS replicates data from the writer DB instance to both of the reader DB instances using the DB engine's native replication capabilities.
• Reader DB instances act as automatic failover targets and also serve read traffic to increase application read throughput. If an outage occurs on your writer DB instance, RDS manages failover to one of the reader DB instances.
• Multi-AZ DB clusters have lower write latency when compared to Multi-AZ DB instance deployments.

Sample Multi-AZ setup

Risks
For projects running single AZ production RDS databases, and want to consider migrating to Multi-AZ Database deployments after reading this article, some things to keep in mind and account for before carrying out your migration are listed in the multi-AZ sessions below.
Single-AZ DB
It is not highly available. When there is a failure in the AZ the database is inaccessible for that period of time.

Multi-AZ DB

• Cost of operation increases because the database has double the resources and infrastructure handling the Database. Depending on the number of availability zones, the cost for two availability zones is double the cost for a single AZ.

• Though this does not occur all the time, there could be a latency issue during migration.
  When Migrating RDS from a single-AZ to Multi-AZ, latency can sometimes occurs because when converting a DB instance from Single-AZ to Multi-AZ, Amazon RDS creates a snapshot of the database volumes and restores these to new volumes in a different Availability Zone. Although the newly restored volumes are available almost immediately, they don’t reach their specified performance until the underlying storage blocks are copied from the snapshot.
  Therefore, during the conversion from Single-AZ to Multi-AZ, you can experience elevated latency and performance impacts. This impact is a function of volume type, workload, instance, and volume size, and can be significant and may impact large write-intensive DB instances during the peak hours of operations.
  This latency hardly occurs because for multi-az deployment the primary database will still be operating optimally. Except there is a case of capacity overload on the primary database before the migration.

Multi-AZ Cluster
There may be an Initial Replica Lag in a multi-AZ cluster deployment. Replica lag is the difference in time between the latest transaction on the writer DB instance and the latest applied transaction on a reader DB instance.
You can create a Multi-AZ DB cluster only with MySQL version 8.0.28 and higher 8.0 versions, and PostgreSQL version 13.4.
You can create Multi-AZ DB clusters only in the following AWS Regions: US East (Ohio) US East (N. Virginia) US West (Oregon) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) Europe (Ireland) Europe (Frankfurt) Europe (Stockholm) as at the time of writing this.
Multi-AZ DB clusters only support Provisioned IOPS storage.
You can't change a single-AZ DB instance deployment or Multi-AZ DB instance deployment into a Multi-AZ DB cluster. As an alternative, you can restore a snapshot of a single-AZ DB instance deployment or a Multi-AZ DB instance deployment to a Multi-AZ DB cluster.
You can't restore a Multi-AZ DB cluster snapshot to a Multi-AZ DB instance deployment or single-AZ deployment.
Multi-AZ DB clusters don't support modifications at the DB instance level because all modifications are done at the DB cluster level.

Recommendation

Multi-Az deployment of a database is always the best practice to combat faults and failure and have a secure architecture in times of disaster. The production environment should always have multi-AZ in mind when deploying resources, especially databases. This would not only make it possible to still operate optimally when a region's data center goes down, but It will also enhance database accessibilities by applications as there are enough IOPS to serve the workload. Multi-AZ should be carried out, In the case where cost is a challenge, then resources can be right-sized to have two copies at a fair price.