Can AWS Aurora High Availability allow different Schema on Replicas?

Question

Our company is thinking of migrating from SQL Server to Amazon AuroraDB.

In SQL Server, there are AlwaysOn and Transactional Replication - two different things.

1. AlwaysOn is utilized more for disaster recovery, it sends whole database to another cluster, providing database level protection. The data is sent directly with a transaction log redo thread. Microsoft AlwaysOn

2. In Replication, data is first sent to a distribution database then to a subscriber. Replication allows for only certain tables to be sent, with different schema and indexes on subscriber, which can be different from Publisher. Microsoft Replication

Is AWS High Availability similar to MS AlwaysOn Disaster Recovery or Replication? It seems more similar to AlwaysOn.

If so, does it have a Replication type technology? We want to make schema changes on the subscriber. (add indexes, remove certain tables not required in reporting env)

Stack

Answer 1

AWS Aurora's replication is more akin to Always On Availability Group. The primary pushes storage changes to other replicas. You don't get to make schema changes on the subscriber.

More details are available in several re:Invent deep dive sessions.

Answer 2

This may not have been the case when the question was asked but the docs now show a table that clearly answers this question.

So you can have a different schema in binlog replicas but not Aurora replicas.

As noted in a comment in the other answer this approach can have drawbacks if you intend to modify parts of the schema that are replicated from the master, but it can still have value as a simple/reliable/cheap extract and load mechanism where you could build adjacent schemas in a MySQL RDS replica.