Aurora Create cross-region read replica vs Add Region

Question

I have 3 questions regarding aurora read replica:

1. When I create a cross region read replica the resulting replica cluster in the new region creates a writer instance when multi-AZ is enabled. An interesting thing is that the writer instance appears as a reader during creation and switched to a writer after creation. I would assume that the writer is disabled but why does it appear as a writer even though it is a cross-region READ replica?

2. What is the difference between read replicas created by 'Create Cross-Region Read Replica' and 'Add Region'. It seems the the underlying implementation is different: binlog based sync and storage-layer based sync. Also, they appear differently from the console - Cross-region read replica appears to be an independent cluster in another region but read replicas created by Add Region appear as a secondary of the primary cluster in the source region. Given the differences, my question is what is the difference of the two types of replicas? How do I need to guide customers when asked which one to choose?

3. Do replicas in different region automatically escalated to a primary? I guess it requires some manual work such as changing the endpoint etc.

Joe_C · Accepted Answer

1. You're replicating to a new cluster, and each cluster needs a writer instance. It is recommended that customers apply the read_only parameter to the replica, but by default they are able to write to this instance. This allows for architectures where the replica is read & writable.

2. 'Create Cross-Region Read Replica' sets up [binary log replication][1], utilizing MySQL's built-in functionality to replicate changes to another database. Binlog replication comes with its own challenges, including higher potential for replicas to fall behind the writer for heavy workloads. It is native to MySQL though, and has been around a long time.  'Add Region' sets up [Aurora Global Database][2], which uses Aurora's storage-based replication. Aurora GlobalDB is going to give customers lower (typically less than 1 second) and more consistent replica lag. There are a few technical [limitations][3] to consider if using GlobalDB, but this also allows for customers to have an easier way to failover and use advanced features like [Write Forwarding][4]. In addition to a second cluster being setup, customers are also charged for Replicated Write I/Os to the secondary region(s).

3. No, we don't auto-failover to another region. This requires manual effort from the customer.

[1]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html
  [2]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
  [3]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html#aurora-global-database.limitations
  [4]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding.html

Aurora Create cross-region read replica vs Add Region

Relevant content