AWS – Creating an RDS database read replica

How to install Ubuntu Server 19.10

This recipe will show you how to create an RDS read replica. You can use read replicas to increase the performance of your application by off-loading database reads to a separate database instance. You can provision up to five read replicas per source DB.

Getting ready

You will need an RDS DB deployed with backup retention enabled. We are going to build upon the DB deployed in the previous recipe.

You’re going to need the following values:

  • The identifier for your source RDS instance, for example, eexocwv5k5kv5z
  • A unique identifier for the read replica we’re going to create, for example, read-replica-1

How to do it…

In the AWS CLI, type this command:

aws rds create-db-instance-read-replica \
  --source-db-instance-identifier <source-db-identifier> \
  --db-instance-identifier <unique-identifier-for-replica>

RDS will now go ahead and create a new read replica for you.

How it works…

Some parameters are inherited from the source instance and can’t be defined at the time of creation:

  • Storage engine
  • Storage size
  • Security group

The CLI command accepts some parameters that we could have defined but didn’t to keep things simple. They will instead be inherited from the source database. The main two are as follows:

  • --db-instance-class: The same class as the source instance is used.
  • --db-subnet-group-name: The source instance’s subnet group will be used and a subnet is chosen at random (hence, an AZ is chosen at random).

There’s more…

Here is some additional information about read replicas:

  • Read replicas are deployed in a single AZ; there is no standby read replica.
  • It’s not possible to enable backups on read replicas during the time of creation. This must be configured afterward.
  • The default storage type is standard (magnetic). You can increase performance by choosing gp2 or using provisioned IOPS.
  • It’s possible to add MySQL indexes directly to a read replica to further increase read performance. These indexes are not required to be present on the primary DB.
  • Using read replicas for availability purposes is more of a complementary DR strategy and shouldn’t be used in place of multi-AZ RDS. A multi-AZ configuration gives you the benefit of failure detection and automatic failover.
  • It is possible to deploy a read replica in an entirely different region.
  • Unlike the replication between a primary and standby DB (which is synchronous), replication to a read replica is asynchronous. This means that a read replica can fall behind the primary. Keep this in mind when sending time-sensitive read queries to your read replicas.

Comments are closed.