Amazon Relational Database Service (RDS) | Multi-AZ Deployments and Read Replicas

Question 1

How can I monitor the configuration of my Amazon RDS resources?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 1

You can use AWS Config to continuously record configurations changes to Amazon RDS DB Instances, DB Subnet Groups, DB Snapshots, DB Security Groups, and Event Subscriptions and receive notification of changes through Amazon Simple Notification Service (SNS). You can also create AWS Config Rules to evaluate whether these RDS resources have the desired configurations.

Question 2

What types of replication does Amazon RDS support and when should I use each?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 2

Amazon RDS provides two distinct replication options to serve different purposes.

If you are looking to use replication to increase database availability while protecting your latest database updates against unplanned outages, consider running your DB instance as a Multi-AZ deployment. When you create or modify your DB instance to run as a Multi-AZ deployment, Amazon RDS will automatically provision and manage a “standby” replica in a different Availability Zone (independent infrastructure in a physically separate location). In the event of planned database maintenance, DB instance failure, or an Availability Zone failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without administrative intervention. Multi-AZ deployments utilize synchronous replication, making database writes concurrently on both the primary and standby so that the standby will be up-to-date in the event a failover occurs. While our technological implementation for Multi-AZ DB Instances maximizes data durability in failure scenarios, it precludes the standby from being accessed directly or used for read operations. The fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

To help you to scale beyond the capacity constraints of a single DB Instance for read-heavy database workloads, Amazon RDS offers Read Replicas. You can create a Read Replica of a given source DB Instance using the AWS Management Console, the RDS API, or the AWS Command Line Interface. Once the Read Replica is created, database updates on the source DB instance will be propagated to the Read Replica. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them.

Read Replicas are supported by Amazon Aurora and Amazon RDS for MySQL, MariaDB and PostgreSQL. Unlike Multi-AZ deployments, Read Replicas for these engines use each’s built-in replication technology and are subject to its strengths and limitations. In particular, updates are applied to your Read Replica(s) after they occur on the source DB instance (“asynchronous” replication), and replication lag can vary significantly. This means recent database updates made to a standard (non Multi-AZ) source DB instance may not be present on associated Read Replicas in the event of an unplanned outage on the source DB instance. As such, Read Replicas do not offer the same data durability benefits as Multi-AZ deployments. While Read Replicas can provide some read availability benefits, they and are not designed to improve write availability.

You can use Multi-AZ deployments and Read Replicas in conjunction to enjoy the complementary benefits of each. You can simply specify that a given Multi-AZ deployment is the source DB instance for your Read Replica(s). That way you gain both the data durability and availability benefits of Multi-AZ deployments and the read scaling benefits of Read Replicas.

Multi-AZ Deployments

Question 3

What does it mean to run a DB instance as a Multi-AZ deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 3

When you create or modify your DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure. During certain types of planned maintenance, or in the unlikely event of DB instance failure or Availability Zone failure, Amazon RDS will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB instance remains the same, your application can resume database operation without the need for manual administrative intervention. With Multi-AZ deployments, replication is transparent: you do not interact directly with the standby, and it cannot be used to serve read traffic. More information about Multi-AZ deployments is in the Amazon RDS User Guide.

Question 4

What is an Availability Zone?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 4

Availability Zones are distinct locations within a Region that are engineered to be isolated from failures in other Availability Zones. Each Availability Zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone. Availability Zones within the same Region benefit from low-latency network connectivity.

Question 5

What do “primary” and “standby” mean in the context of a Multi-AZ deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 5

When you run a DB instance as a Multi-AZ deployment, the “primary” serves database writes and reads. In addition, Amazon RDS provisions and maintains a “standby” behind the scenes, which is an up-to-date replica of the primary. The standby is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (e.g. for read operations) at any point prior to promotion. If you are interested in scaling read traffic beyond the capacity constraints of a single DB instance, please see the FAQs on Read Replicas.

Question 6

What are the benefits of a Multi-AZ deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 6

The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone. For example, if a storage volume on your primary fails, Amazon RDS automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single AZ, where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last five minutes) would not be available.

You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. The availability benefits of Multi-AZ also extend to planned maintenance. For example, with automated backups, I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby. In the case of patching or DB instance class scaling, these operations occur first on the standby, prior to automatic fail over. As a result, your availability impact is limited to the time required for automatic failover to complete.

Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. In an Amazon RDS context, this means you are not required to monitor DB instance events and initiate manual DB instance recovery (via the RestoreDBInstanceToPointInTime or RestoreDBInstanceFromSnapshot APIs) in the event of an Availability Zone failure or DB instance failure.

Question 7

Are there any performance implications of running my DB instance as a Multi-AZ deployments?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 7

You may observe elevated latencies relative to a standard DB instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf.

Question 8

When running my DB instance as a Multi-AZ deployment, can I use the standby for read or write operations?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 8

No, the standby replica cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Our implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations. If you are interested in a read scaling solution, please see the FAQs on Read Replicas.

Question 9

How do I set up a Multi-AZ DB instance deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 9

In order to create a Multi-AZ DB instance deployment, simply click the “Yes” option for “Multi-AZ Deployment” when launching a DB Instance with the AWS Management Console. Alternatively, if you are using the Amazon RDS APIs, you would call the CreateDBInstance API and set the “Multi-AZ” parameter to the value “true.” To convert an existing standard (single AZ) DB instance to Multi-AZ, modify the DB instance in the AWS Management Console or use the ModifyDBInstance API and set the Multi-AZ parameter to true.

Question 10

What happens when I convert my RDS instance from Single-AZ to Multi-AZ?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 10

For the RDS MySQL, MariaDB, PostgreSQL and Oracle database engines, when you elect to convert your RDS instance from Single-AZ to Multi-AZ, the following happens:

A snapshot of your primary instance is taken

A new standby instance is created in a different Availability Zone, from the snapshot

Synchronous replication is configured between primary and standby instances

As such, there should be no downtime incurred when an instance is converted from Single-AZ to Multi-AZ.

Question 11

What events would cause Amazon RDS to initiate a failover to the standby replica?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 11

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 any of the following:

Loss of availability in primary Availability Zone

Loss of network connectivity to primary

Compute unit failure on primary

Storage failure on primary

Note: When operations such as DB instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.

Question 12

Will I be alerted when automatic failover occurs?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 12

Yes, Amazon RDS will emit a DB instance event to inform you that automatic failover occurred. You can click the “Events” section of the Amazon RDS Console or use the DescribeEvents API to return information about events related to your DB instance. You can also use Amazon RDS Event Notifications to be notified when specific DB events occur.

Question 13

What happens during Multi-AZ failover and how long does it take?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 13

Failover is automatically handled by Amazon RDS so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer.

Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within one to two minutes. Failover time can also be affected by whether large uncommitted transactions must be recovered; the use of adequately large instance types is recommended with Multi-AZ for best results. AWS also recommends the use of Provisioned IOPS with Multi-AZ instances, for fast, predictable, and consistent throughput performance.

Question 14

Can I initiate a “forced failover” for my Multi-AZ DB instance deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 14

Amazon RDS will automatically failover without user intervention under a variety of failure conditions. In addition, Amazon RDS provides an option to initiate a failover when rebooting your instance. You can access this feature via the AWS Management Console or when using the RebootDBInstance API call.

Question 15

How do I control/configure Multi-AZ synchronous replication?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 15

With Multi-AZ deployments, you simply set the “Multi-AZ” parameter to true. The creation of the standby, synchronous replication, and failover are all handled automatically. This means you cannot select the Availability Zone your standby is deployed in or alter the number of standbys available (Amazon RDS provisions one dedicated standby per DB instance primary). The standby also cannot be configured to accept database read activity. Learn more about Multi-AZ configurations.

Question 16

Will my standby be in the same Region as my primary?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 16

Yes. Your standby is automatically provisioned in a different Availability Zone of the same Region as your DB instance primary.

Question 17

Can I see which Availability Zone my primary is currently located in?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 17

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeDBInstances API.

Question 18

After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances). Should I be concerned about latency?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 18

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure. Multi-AZ deployments address this need for the database tier without administration on your part.

Question 19

How do DB Snapshots and automated backups work with my Multi-AZ deployment?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 19

You interact with automated backup and DB Snapshot functionality in the same way whether you are running a standard deployment in a Single-AZ or Multi-AZ deployment. If you are running a Multi-AZ deployment, automated backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary. Please note that you may experience increased I/O latency (typically lasting a few minutes) during backups for both Single-AZ and Multi-AZ deployments.

Initiating a restore operation (point-in-time restore or restore from DB Snapshot) also works the same with Multi-AZ deployments as standard, Single-AZ deployments. New DB instance deployments can be created with either the RestoreDBInstanceFromSnapshot or RestoreDBInstanceToPointInTime APIs. These new DB instance deployments can be either standard or Multi-AZ, regardless of whether the source backup was initiated on a standard or Multi-AZ deployment.

Read Replicas

Question 20

What does it mean to run a DB Instance as a Read Replica?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 20

Read Replicas make it easy to take advantage of supported engines’ built-in replication functionality to elastically scale out beyond the capacity constraints of a single DB Instance for read-heavy database workloads. You can create a Read Replica with a few clicks in the AWS Management Console or using the CreateDBInstanceReadReplica API. Once the Read Replica is created, database updates on the source DB Instance will be replicated using a supported engine’s native, asynchronous replication. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them. Since Read Replicas use supported engines’ built-in replication, they are subject to its strengths and limitations. In particular, updates are applied to your Read Replica(s) after they occur on the source DB Instance, and replication lag can vary significantly. Read Replicas can be associated with Multi-AZ deployments to gain read scaling benefits in addition to the enhanced database write availability and data durability provided by Multi-AZ deployments.

Question 21

When would I want to consider using an Amazon RDS Read Replica?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 21

There are a variety of scenarios where deploying one or more Read Replicas for a given source DB Instance may make sense. Common reasons for deploying a Read Replica include:

Scaling beyond the compute or I/O capacity of a single DB Instance for read-heavy database workloads. This excess read traffic can be directed to one or more Read Replicas.

Serving read traffic while the source DB Instance is unavailable. If your source DB Instance cannot take I/O requests (e.g. due to I/O suspension for backups or scheduled maintenance), you can direct read traffic to your Read Replica(s). For this use case, keep in mind that the data on the Read Replica may be “stale” since the source DB Instance is unavailable.

Business reporting or data warehousing scenarios; you may want business reporting queries to run against a Read Replica, rather than your primary, production DB Instance.

Question 22

Do I need to enable automatic backups on my DB Instance before I can create read replicas?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 22

Yes. Enable automatic backups on your DB Instance before adding Read Replicas, by setting the backup retention period to a value other than 0. Backups must remain enabled for Read Replicas to work.

Question 23

Which versions of database engines support Amazon RDS Read Replicas?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 23

Amazon Aurora: All DB Clusters.

Amazon RDS for MySQL: DB Instances with MySQL version 5.5 or newer support creation of Read Replicas. Automatic backups must be and remain enabled on the source DB Instance for Read Replica operations. Automatic backups on the replica are supported only for Amazon RDS Read Replicas running MySQL 5.6 and later, not 5.5.

Amazon RDS for PostgreSQL: DB Instances with PostgreSQL version 9.3.5 or newer support creation of Read Replicas. Existing PostgreSQL instances prior to version 9.3.5 need to be upgraded to PostgreSQL version 9.3.5 to take advantage of Amazon RDS Read Replicas.

Amazon RDS for MariaDB: All DB Instances support creation of Read Replicas. Automatic backups must be and remain enabled on the source DB Instance for Read Replica operations.

Question 24

How do I deploy a Read Replica for a given DB Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 24

You can create a Read Replica in minutes using the standard CreateDBInstanceReadReplica API or a few clicks on the AWS Management Console. When creating a Read Replica, you can identify it as a Read Replica by specifying a SourceDBInstanceIdentifier. The SourceDBInstanceIdentifier is the DB Instance Identifier of the “source” DB Instance from which you wish to replicate. As with a standard DB Instance, you can also specify the Availability Zone, DB Instance class, and preferred maintenance window. The engine version (e.g., PostgreSQL 9.3.5) and storage allocation of a Read Replica is inherited from the source DB Instance. When you initiate the creation of a Read Replica, Amazon RDS takes a snapshot of your source DB Instance and begins replication. As a result, you will experience a brief I/O suspension on your source DB Instance as the snapshot occurs. The I/O suspension typically lasts on the order of one minute, and is avoided if the source DB Instance is a Multi-AZ deployment (in the case of Multi-AZ deployments, snapshots are taken from the standby). Amazon RDS is also currently working on an optimization (to be released shortly) such that if you create multiple Read Replicas within a 30 minute window, all of them will use the same source snapshot to minimize I/O impact (“catch-up” replication for each Read Replica will begin after creation).

Question 25

How do I connect to my Read Replica(s)?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 25

You can connect to a Read Replica just as you would connect to a standard DB Instance, using the DescribeDBInstance API or AWS Management Console to retrieve the endpoint(s) for you Read Replica(s). If you have multiple Read Replicas, it is up to your application to determine how read traffic will be distributed amongst them.

Question 26

How many Read Replicas can I create for a given source DB Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 26

Amazon Aurora allows you to create up to 15 Read Replicas for a given DB Cluster.

Amazon RDS for MySQL, MariaDB and PostgreSQL currently allow you to create up to 5 Read Replicas for a given source DB Instance.

Question 27

Can I create a Read Replica in an AWS Region different from that of the source DB Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 27

Yes, RDS supports cross-region Read Replicas.

Question 28

Do Amazon RDS Read Replicas support synchronous replication?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 28

No. Read Replicas in Amazon RDS for MySQL, MariaDB and PostgreSQL are implemented using those engines’ native asynchronous replication. Amazon Aurora uses a different, but still asynchronous, replication mechanism.

Question 29

Can I use a Read Replica to enhance database write availability or protect the data on my source DB Instance against failure scenarios?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 29

If you are looking to use replication to increase database write availability and protect recent database updates against various failure conditions, we recommend you run your DB Instance as a Multi-AZ deployment. With Amazon RDS Read Replicas, which employ supported engines’ native, asynchronous replication, database writes occur on a Read Replica after they have already occurred on the source DB Instance, and this replication “lag” can vary significantly. In contrast, the replication used by Multi-AZ deployments is synchronous, meaning that all database writes are concurrent on the primary and standby. This protects your latest database updates, since they should be available on the standby in the event a failover is required. In addition, with Multi-AZ deployments replication is fully managed. Amazon RDS automatically monitors for DB Instance failure conditions or Availability Zone failure and initiates automatic failover to the standby (or to a read replica, in the case of Amazon Aurora) if an outage occurs.

Question 30

Can I create a Read Replica with a Multi-AZ DB Instance deployment as its source?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 30

Yes. Since Multi-AZ DB Instances address a different need than Read Replicas, it makes sense to use the two in conjunction for production deployments and to associate a Read Replica with a Multi-AZ DB Instance deployment. The “source” Multi AZ-DB Instance provides you with enhanced write availability and data durability, and the associated Read Replica would improve read traffic scalability.

Question 31

Can I make my Amazon RDS Read Replicas themselves Multi-AZ?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 31

Amazon RDS for MySQL and MariaDB allow you to enable Multi-AZ on Read Replicas to support disaster recovery and minimuze downtime from engine upgrades. Amazon RDS for PostgreSQL does not presently support this.

Question 32

If my Read Replica(s) use a Multi-AZ DB Instance deployment as a source, what happens if Multi-AZ failover occurs?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 32

In the event of a Multi-AZ failover, any associated and available Read Replicas should automatically resume replication once failover has completed (acquiring updates from the newly promoted primary).

Question 33

Can I create a Read Replica of another Read Replica?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 33

Amazon Aurora, Amazon RDS for MySQL and MariaDB: You can create a second-tier Read Replica from an existing first-tier Read Replica. By creating a second-tier Read Replica, you may be able to move some of the replication load from the master database instance to a first-tier Read Replica. Please note that a second-tier Read Replica may lag further behind the master because of additional replication latency introduced as transactions are replicated from the master to the first tier replica and then to the second-tier replica.

Amazon RDS for PostgreSQL: Read Replicas of Read Replicas are not currently supported.

Question 34

Can my Read Replicas only accept database read operations?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 34

Read Replicas are designed to serve read traffic. However, there may be use cases where advanced users wish to complete Data Definition Language (DDL) SQL statements against a Read Replica. Examples might include adding a database index to a Read Replica that is used for business reporting, without adding the same index to the corresponding source DB Instance.

Amazon RDS for MySQL can be configured to permit DDL SQL statements against a Read Replica. If you wish to enable operations other than reads for a given Read Replica, modify the active DB Parameter Group for the Read Replica, setting the “read_only” parameter to “0.”

Amazon RDS for PostgreSQL does not currently support the execution of DDL SQL statements against a Read Replica.

Question 35

Can I promote my Read Replica into a “standalone” DB Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 35

Yes. Refer to the Amazon RDS User Guide for more details.

Question 36

Will my Read Replica be kept up-to-date with its source DB Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 36

Updates to a source DB Instance will automatically be replicated to any associated Read Replicas. However, with supported engines’ asynchronous replication technology, a Read Replica can fall behind its source DB Instance for a variety of reasons. Typical reasons include:

Write I/O volume to the source DB Instance exceeds the rate at which changes can be applied to the Read Replica (this problem is particularly likely to arise if the compute capacity of a Read Replica is less than the source DB Instance)

Complex or long-running transactions to the source DB Instance hold up replication to the Read Replica

Network partitions or latency between the source DB Instance and a Read Replica

Read Replicas are subject to the strengths and weaknesses of supported engines’ native replication. If you are using Read Replicas, you should be aware of the potential for lag between a Read Replica and its source DB Instance, or “inconsistency”. Click here for guidance on what to do if your Read Replica(s) fall significantly behind its source.

Question 37

How do I see the status of my active Read Replica(s)?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 37

You can use the standard DescribeDBInstances API to return a list of all the DB Instances you have deployed (including Read Replicas), or simply click on the “DB Instances” tab of the Amazon RDS Console.

Amazon RDS allows you to gain visibility into how far a Read Replica has fallen behind its source DB Instance. The number of seconds that the Read Replica is behind the master is published as an Amazon CloudWatch metric (“Replica Lag”) available via the AWS Management Console or Amazon CloudWatch APIs. For Amazon RDS for MySQL, the source of this information is the same as that displayed by issuing a standard “Show Slave Status” MySQL command against the Read Replica. For Amazon RDS for PostgreSQL, you can use the pg_stat_replication view on the source DB Instance to explore replication metrics.

Amazon RDS monitors the replication status of your Read Replicas and updates the Replication State field in the AWS Management console to “Error” if replication stops for any reason (e.g., attempting DML queries on your replica that conflict with the updates made on the master database instance could result in a replication error). You can review the details of the associated error thrown by the MySQL engine by viewing the Replication Error field and take an appropriate action to recover from it. You can learn more about troubleshooting replication issues in the Troubleshooting a Read Replica Problem section of the User Guide for Amazon RDS for MySQL or PostgreSQL.

If a replication error is fixed, the Replication State changes to Replicating.

Question 38

My Read Replica has fallen significantly behind its source DB Instance. What should I do?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 38

As discussed in the previous questions, “inconsistency” or lag between a Read Replica and its source DB Instance is common with asynchronous replication. If an existing Read Replica has fallen too far behind to meet your requirements, you can delete it and create a new one with the same endpoint by using the same DB Instance Identifier and Source DB Instance Identifier as the deleted Read Replica. Keep in mind that the re-creation process will be counter-productive at small lag levels (e.g. under five minutes of lag), and should be used with prudence (i.e. only when the Read Replica is significantly behind its source DB Instance). Also keep in mind that replica lag may naturally grow and shrink over time, depending on your source DB Instance’s steady-state usage pattern.

Scaling the DB Instance class of a Read Replica may reduce replication lag in some cases, particularly if your source DB Instance class is larger than your Read Replica DB Instance class. However, Read Replicas are not guaranteed to work in all cases. There may be scenarios and usage patterns where a Read Replica can never catch up with its source after initial creation, or otherwise remains too far behind its source to meet your use case requirements.

Question 39

I scaled the compute and/or storage capacity of my source DB Instance. Should I scale the resources for associated Read Replica(s) as well?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 39

For replication to work effectively, we recommend that Read Replicas have as much or more compute and storage resources as their respective source DB Instances. Otherwise replication lag is likely to increase or your Read Replica may run out of space to store replicated updates.

Question 40

Can DB Snapshots or automated backups be taken of Read Replicas?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 40

No. If you are looking to increase database write availability by taking backups from your Read Replica instead of its source DB Instance, you can accomplish the same objective by running your DB Instance as a Multi-AZ deployment. Backups will then be initiated from the Multi-AZ standby to minimize availability impact.

Question 41

How do I delete a Read Replica? Will it be deleted automatically if its source DB Instance is deleted?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 41

You can easily delete a Read Replica with a few clicks of the AWS Management Console or by passing its DB Instance identifier to the DeleteDBInstance API.

An Amazon Aurora (MySQL) Read Replica will stay active and continue accepting read traffic even after its corresponding source DB Instance has been deleted. One of the Read Replicas in the cluster will automatically be promoted as the new master, and will start accepting write traffic.

An Amazon RDS for MySQL or MariaDB Read Replica will stay active and continue accepting read traffic even after its corresponding source DB Instance has been deleted. If you desire to delete the Read Replica in addition to the source DB Instance, you must explicitly do so using the DeleteDBInstance API or AWS Management Console.

If you delete an Amazon RDS for PostgreSQL DB Instance that has Read Replicas, all Read Replicas will be promoted to standalone DB Instances and will be able to accept both read and write traffic. The newly promoted DB Instances will operate independently of one another. If you desire to delete these DB Instances in addition to the original source DB Instance, you must explicitly do so using the DeleteDBInstance API or AWS Management Console.

Question 42

Can I directly access the event logs for my Database Instance?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 42

With Amazon RDS for MySQL or Amazon RDS for MariaDB, you can use the mysqlbinlog utility to download or stream binary logs from your DB Instance. Amazon RDS for PostgreSQL does not currently provide access to the WAL files for your DB Instance.

Question 43

How much do Read Replicas cost? When does billing begin and end?

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Question 44

A Read Replica is billed as a standard DB Instance and at the same rates. Click here for more information on DB Instance billing visit this FAJust like a standard DB Instance, the rate per “DB Instance hour” for a Read Replica is determined by the DB Instance class of the Read Replica – please see Amazon RDS detail page for up-to-date pricing. You are not charged for the data transfer incurred in replicating data between your source DB Instance and Read Replica.

Multi-AZ Deployments and Read Replicas

Amazon Relational Database Service (RDS) | Database

Answer 44

Billing for a Read Replica begins as soon as the Read Replica has been successfully created (i.e. when status is listed as “active”). The Read Replica will continue being billed at standard Amazon RDS DB Instance hour rates until you issue a command to delete it.