Replication with Amazon Aurora
Aurora Replicas are independent endpoints in an Aurora DB cluster, best used for scaling read operations and increasing availability. Up to 15 Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans within a region. Although the DB cluster volume is made up of multiple copies of the data for the DB cluster, the data in the cluster volume is represented as a single, logical volume to the primary instance and to Aurora Replicas in the DB cluster.
As a result, all Aurora Replicas return the same data for query results with minimal replica lag—usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag.
Aurora Replicas work well for read scaling because they are fully dedicated to read operations on your cluster volume. Write operations are managed by the primary instance. Because the cluster volume is shared among all instances in your DB cluster, no additional work is required to replicate a copy of the data for each Aurora Replica. In contrast, MySQL Read Replicas must replay, on a single thread, all write operations from the master DB instance to their local data store, which can affect MySQL Read Replicas ability to support large volumes of read traffic.
To increase availability, you can use Aurora Replicas as failover targets. That is, if the primary instance fails, an Aurora Replica is promoted to the primary instance with only a brief interruption during which read and write requests made to the primary instance fail with an exception. If your Aurora DB cluster doesn't include any Aurora Replicas, then the primary instance is recreated during a failure event. However, promoting an Aurora Replica is much faster than recreating the primary instance. For high-availability scenarios, we recommend that you create one or more Aurora Replicas, of the same DB instance class as the primary instance, in different Availability Zones for your Aurora DB cluster. For more information on Aurora Replicas as failover targets, see Fault Tolerance for an Aurora DB Cluster.
Aurora Replicas always use the
REPEATABLE READ default transaction
isolation level for operations on InnoDB tables. You can use the
TRANSACTION ISOLATION LEVEL command to change the transaction level only
for the primary instance of an Amazon Aurora DB cluster. This restriction avoids
user-level locks on Aurora Replicas and allows Aurora Replicas to scale to support
thousands of active user connections while still keeping replica lag to a
For details on how to create an Aurora Replica, see Creating an Aurora Replica Using the Console.
You can set up replication between two Amazon Aurora DB clusters in different AWS regions. For details, see Replicating Amazon Aurora DB Clusters Across AWS Regions.
You can set up replication between two Amazon Aurora DB clusters using MySQL binary log (binlog) replication. For details, see Replication Between Aurora and MySQL or Between Aurora and Another Aurora DB Cluster.
You can set up replication between an RDS MySQL DB instance as the master and an Aurora DB cluster by creating an Aurora Read Replica of a MySQL DB instance. Typically, this approach is used for migration to Aurora rather than for ongoing replication. For details, see Migrating Data from a MySQL DB Instance to an Amazon Aurora DB Cluster by Using a Read Replica.
Rebooting the primary instance of an Amazon Aurora DB cluster also automatically reboots the Aurora Replicas for that DB cluster.
Monitoring Aurora Replication
Read scaling and high availability depend on minimal lag time. You can monitor how
far an Aurora Replica is lagging behind the primary instance of your Aurora DB cluster
by monitoring the Amazon CloudWatch
ReplicaLag metric. Because Aurora Replicas
read from the same cluster volume as the primary instance, the
ReplicaLag metric has a different meaning for an Aurora DB cluster.
ReplicaLag metric for an Aurora Replica indicates the lag for the
page cache of the Aurora Replica compared to that of the primary instance.
If you need the most current value for Aurora Replica lag, you can query the
mysql.ro_replica_status table in your Aurora DB cluster and check
the value in the
Replica_lag_in_msec column. This column value is
provided to Amazon CloudWatch as the value for the
ReplicaLag metric. The values
mysql.ro_replica_status are also provided in the
INFORMATION_SCHEMA.REPLICA_HOST_STATUS table in your Aurora DB
For more information on monitoring RDS instances and CloudWatch metrics, see Monitoring Amazon RDS.