Skip to content

🤔 Unexpected Aurora Cross-Region Read Replica Behavior - Need Expert Input

0

I'm seeing unusual behavior with my Aurora MySQL cross-region read replica that doesn't match the documented behavior:

Setup: • Primary cluster: us-east-1 • Cross-region read replica: us-west-2 • NOT using Aurora Global Database (confirmed via describe-global-clusters)

Expected Behavior: Read replica should be read-only

Actual Behavior: ✅ us-west-2 replica accepts writes (INSERT/UPDATE work) ✅ Replication still flows us-east-1 → us-west-2 ✅ Both clusters show IsClusterWriter: true ✅ us-west-2 shows ReplicationSourceIdentifier pointing to us-east-1

Test Results: • Inserted record in us-east-1 → appeared in us-west-2 ✅ • Inserted record in us-west-2 → stayed local (didn't replicate back) • Record counts differ between regions (us-west-2 has more)

Question: Is this expected behavior for Aurora cross-region read replicas? The documentation suggests replicas should be read-only, but mine accepts writes while maintaining replication.

Has anyone seen this configuration before? TIA

AWS

asked a year ago283 views

3 Answers
0

What you're experiencing is not the expected behavior for a standard Aurora MySQL cross-region read replica. Typically, Aurora read replicas should be read-only, not accepting writes.

The behavior you're describing suggests that what you have is not a standard read replica but potentially a split-brain scenario or an incorrectly configured replication setup. In a proper cross-region read replica configuration:

  1. The replica should be read-only and should not accept writes (INSERT/UPDATE statements)
  2. The replication flow should be one-way only (primary to replica)
  3. Only the primary cluster should show IsClusterWriter: true

The fact that both clusters show IsClusterWriter: true is particularly concerning, as this indicates both clusters are operating as primaries. This could lead to data inconsistency issues since changes made in us-west-2 aren't propagating back to us-east-1.

For Aurora MySQL cross-region replication, the process works through binary log (binlog) replication where:

  • Transactions committed on the primary cluster are recorded in binary log files
  • These changes are sent through an I/O thread to relay logs in the secondary region
  • The changes are then applied to the secondary Aurora cluster

Some potential causes for your situation:

  • The replica might have been promoted to a writer at some point
  • There might be configuration issues with the replication setup
  • The binlog settings might be misconfigured

I recommend checking your binary logging configuration, verifying the replication status, and potentially recreating the cross-region replica if necessary to ensure proper read-only behavior.
Sources
Aurora MySql replication problem | AWS re:Post
Cross-Region Aurora Replicas - AWS Prescriptive Guidance

answered a year ago

  • Checked all the above and none apply. This must be a bug in RDS Aurora MySQL. I will open up a support ticket.

0

Can you please check if the DB cluster has write forwarding enabled? In the AWS Management Console, on the Configuration tab of the details page for the cluster, you see the status Enabled for Local read replica write forwarding. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-write-forwarding.html

If its set to true that is most likely the cause of records getting accepted on the reader. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-write-forwarding-enabling.html

AWS
EXPERT

answered a year ago

0

Hi. No. Both clusters (primary and secondary) show:

Local read replica write forwarding Disabled

Local read replica write forwarding Disabled

AWS

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.