Migrating Data from a MySQL
DB Instance to an Amazon Aurora MySQL DB Cluster by Using an Aurora Read
Replica

Amazon RDS uses the MySQL DB engines' binary log replication functionality to create
a
special type of DB cluster called an Aurora Read Replica for a source MySQL DB
instance. Updates made to the source MySQL DB instance are asynchronously replicated
to the Aurora Read Replica.

We recommend using this functionality to migrate from a MySQL DB instance to an
Aurora MySQL DB cluster by creating an Aurora Read Replica of your source MySQL DB
instance. When the replica lag between the MySQL DB instance and the Aurora Read
Replica is 0, you can direct your client applications to the Aurora Read Replica and
then stop replication to make the Aurora Read Replica a standalone Aurora MySQL DB
cluster.
Be prepared for migration to take a while, roughly several hours per tebibyte (TiB)
of data.

For
a list of regions where Aurora is available, see Amazon Aurora in the
AWS General Reference.

When you create an Aurora Read Replica of a MySQL DB instance, Amazon RDS creates
a DB
snapshot of your source MySQL DB instance (private to Amazon RDS, and incurring no
charges). Amazon RDS then migrates the data from the DB snapshot to the Aurora Read
Replica. After the data from the DB snapshot has been migrated to the new Aurora
MySQL DB cluster, Amazon RDS starts replication between your MySQL DB instance and
the
Aurora MySQL DB cluster. If your MySQL DB instance contains tables that use storage
engines other than InnoDB, or that use compressed row format, you can speed up the
process of creating an Aurora Read Replica by altering those tables to use the InnoDB
storage engine and dynamic row format before you create your Aurora Read Replica.
For
more information about the process of copying a MySQL DB snapshot to an Aurora MySQL
DB cluster, see Migrating Data from a MySQL DB Instance
to an Amazon Aurora MySQL DB Cluster by Using a DB Snapshot.

You can only have one Aurora Read Replica for a MySQL DB instance.

Note

Replication issues can arise due to feature differences between Amazon Aurora
MySQL and the MySQL database engine version of your RDS MySQL DB instance that
is the replication master. If you encounter an error, you can find help in the
Amazon RDS Community Forum
or by contacting AWS Support.

Choose the MySQL DB instance that you want to use as the source
for your Aurora Read Replica and choose Create Aurora read
replica from Instance
actions.

Choose the DB cluster specifications you want to use for the Aurora
Read Replica, as described in the following table.

Option

Description

DB instance class

Choose a DB instance class that defines the
processing and memory requirements for the primary
instance in the DB cluster. For more information
about DB instance class options, see Choosing the DB Instance Class.

Multi-AZ deployment

Choose Create Replica in Different
Zone to create a standby replica of the
new DB cluster in another Availability Zone in the
target AWS Region for failover support. For more
information about multiple Availability Zones, see
Choosing the Regions and Availability Zones.

DB instance identifier

Type a name for the primary instance in your
Aurora Read Replica DB cluster. This identifier is
used in the endpoint address for the primary
instance of the new DB cluster.

The DB instance identifier has the following
constraints:

It must contain from 1 to 63 alphanumeric
characters or hyphens.

Its first character must be a letter.

It cannot end with a hyphen or contain two
consecutive hyphens.

It must be unique for all DB instances for
each AWS account, for each AWS Region.

Because the Aurora Read Replica DB cluster is
created from a snapshot of the source DB instance,
the master user name and master password for the
Aurora Read Replica are the same as the master user
name and master password for the source DB
instance.

Virtual Private Cloud (VPC)

Select the VPC to host the DB cluster. Select
Create new VPC to have Amazon RDS
create a VPC for you. For more information, see
DB Cluster Prerequisites.

Subnet group

Select the DB subnet group to use for the DB
cluster. Select Create new DB subnet
group to have Amazon RDS create a DB subnet
group for you. For more information, see DB Cluster Prerequisites.

Public accessibility

Select Yes to give the DB cluster
a public IP address; otherwise, select
No. The instances in your DB cluster
can be a mix of both public and private DB
instances. For more information about hiding
instances from public access, see Hiding a DB Instance in a VPC from the Internet.

Select Create new VPC security
group to have Amazon RDS create a VPC
security group for you. Select Select
existing VPC security groups to specify
one or more VPC security groups to secure network
access to the DB cluster. For more information,
see DB Cluster Prerequisites.

Database port

Specify the port for applications and
utilities to use to access the database. Aurora
MySQL DB clusters default to the default MySQL
port, 3306. Firewalls at some companies block
connections to this port. If your company firewall
blocks the default port, choose another port for
the new DB cluster.

Choose Disable encryption
if you don't want your new Aurora DB cluster to be
encrypted. Choose Enable
encryption for your new Aurora DB
cluster to be encrypted at rest. If you choose
Enable encryption, you must
choose an AWS KMS encryption key as the
Master key value.

If your MySQL DB instance is encrypted,
specify an encryption key to have your DB cluster
encrypted at rest using the specified encryption
key. You can specify the encryption key used by
the MySQL DB instance or a different key. You
can't create an unencrypted DB cluster from an
encrypted MySQL DB instance.

Priority

Choose a failover priority for the DB cluster.
If you don't select a value, the default is
tier-1. This priority
determines the order in which Aurora Replicas are
promoted when recovering from a primary instance
failure. For more information, see Fault Tolerance for an Aurora DB
Cluster.

Backup retention period

Select the length of time, from 1 to 35 days,
that Aurora retains backup copies of the database.
Backup copies can be used for point-in-time
restores (PITR) of your database down to the
second.

Enhanced
Monitoring

Choose Enable enhanced
monitoring to enable gathering metrics
in real time for the operating system that your DB
cluster runs on. For more information, see Enhanced Monitoring.

Monitoring Role

Only available if Enhanced
Monitoring is set to Enable
enhanced monitoring. Choose the IAM
role that you created to permit Amazon RDS to
communicate with Amazon CloudWatch Logs for you, or choose
Default to have RDS create a
role for you named
rds-monitoring-role. For more
information, see Enhanced Monitoring.

Granularity

Only available if Enhanced
Monitoring is set to Enable
enhanced monitoring. Set the interval,
in seconds, between when metrics are collected for
your DB cluster.

Select Select window and
specify the weekly time range during which system
maintenance can occur. Or, select No
preference for Amazon RDS to assign a period
randomly.

Choose Create read replica.

CLI

To create an Aurora Read Replica from a source MySQL DB instance, use the
create-db-cluster and create-db-instance AWS CLI commands to create a new
Aurora MySQL DB cluster. When you call the create-db-cluster
command, include the --replication-source-identifier parameter
to identify the Amazon Resource Name (ARN) for the source MySQL DB instance.
For more information about Amazon RDS ARNs, see Amazon Relational Database Service
(Amazon RDS).

Don't specify the master username, master password, or database name as
the Aurora Read Replica uses the same master username, master password, and
database name as the source MySQL DB instance.

If you use the console to create an Aurora Read Replica, then Amazon RDS
automatically creates the primary instance for your DB cluster Aurora Read
Replica. If you use the AWS CLI to create an Aurora Read Replica, you must
explicitly create the primary instance for your DB cluster. The primary
instance is the first instance that is created in a DB cluster.

You can create a primary instance for your DB cluster by using the create-db-instance AWS CLI command with the
following parameters.

--db-cluster-identifier

The name of your DB cluster.

--db-instance-class

The name of the DB instance class to use for your primary
instance.

--db-instance-identifier

The name of your primary instance.

--engine aurora

In this example, you create a primary instance named
myreadreplicainstance for the DB cluster
named myreadreplicacluster, using the DB instance
class specified in myinstanceclass.

API

To create an Aurora Read Replica from a source MySQL DB instance, use the
CreateDBCluster and CreateDBInstance Amazon RDS API commands to create
a new Aurora DB cluster and primary instance. Do not specify the master
username, master password, or database name as the Aurora Read Replica uses
the same master username, master password, and database name as the source
MySQL DB instance.

You can create a new Aurora DB cluster for an Aurora Read Replica from a
source MySQL DB instance by using the CreateDBCluster Amazon RDS API command with the
following parameters:

If your MySQL DB instance is encrypted, specify an
encryption key to have your DB cluster encrypted at rest
using the specified encryption key. Otherwise, your DB
cluster is encrypted at rest using the encryption key for
the MySQL DB instance.

Note

You can't create an unencrypted DB cluster from an
encrypted MySQL DB instance.

The list of EC2 VPC security groups to associate with this DB
cluster.

In this example, you create a DB cluster named
myreadreplicacluster from a source MySQL DB
instance with an ARN set to mysqlmasterARN,
associated with a DB subnet group named
mysubnetgroup and a VPC security group named
mysecuritygroup.

If you use the console to create an Aurora Read Replica, then Amazon RDS
automatically creates the primary instance for your DB cluster Aurora Read
Replica. If you use the AWS CLI to create an Aurora Read Replica, you must
explicitly create the primary instance for your DB cluster. The primary
instance is the first instance that is created in a DB cluster.

You can create a primary instance for your DB cluster by using the CreateDBInstance Amazon RDS API command with the
following parameters:

DBClusterIdentifier

The name of your DB cluster.

DBInstanceClass

The name of the DB instance class to use for your primary
instance.

DBInstanceIdentifier

The name of your primary instance.

Engine=aurora

In this example, you create a primary instance named
myreadreplicainstance for the DB cluster
named myreadreplicacluster, using the DB instance
class specified in myinstanceclass.

CLI

To determine which MySQL DB instance is the master, use the describe-db-clusters and specify the cluster
identifier of the Aurora Read Replica for the
--db-cluster-identifier option. Refer to the
ReplicationSourceIdentifier element in the output for the
ARN of the DB instance that is the replication master.

To determine which DB cluster is the Aurora Read Replica, use the describe-db-instances and specify the instance
identifier of the MySQL DB instance for the
--db-instance-identifier option. Refer to the
ReadReplicaDBClusterIdentifiers element in the output for
the DB cluster identifier of the Aurora Read Replica.

Promoting an
Aurora Read Replica

After migration completes, you can promote the Aurora Read Replica to a
stand-alone DB
cluster
and direct your client applications to the endpoint for the Aurora Read Replica.
For more information on the Aurora endpoints, see Amazon Aurora Connection Management. Promotion should complete
fairly quickly, and you can read from and write to the Aurora Read Replica during
promotion. However, you can't delete the master MySQL DB instance or unlink the
DB Instance and the Aurora Read Replica during this time.

Before you promote your Aurora Read Replica, stop any transactions from being
written to the source MySQL DB instance, and then wait for the replica lag on
the Aurora Read Replica to reach 0. You can view the replica lag for an Aurora
Read Replica by calling the SHOW SLAVE STATUS command on your Aurora
Read Replica and reading the Seconds behind
master value.

You can start writing to the Aurora Read Replica after write transactions to
the master have stopped and replica lag is 0. If you write to the Aurora Read
Replica before this and you modify tables that are also being modified on the
MySQL master, you risk breaking replication to Aurora. If this happens, you must
delete and recreate your Aurora Read Replica.

After you promote, confirm that the promotion has completed by choosing
Instances in the navigation pane and confirming that
there is a Promoted Read Replica cluster to stand-alone database
cluster event for the Aurora Read Replica. After promotion is
complete, the master MySQL DB Instance and the Aurora Read Replica are unlinked,
and you can safely delete the DB instance if you want to.