Aurora MySQL Now Supports Multi-Source Replication and Delayed Replication!

Hi, I'm Shii-chan!

AWS What's New aws.amazon.com

Today I've got a replication update for Amazon Aurora MySQL from AWS's What's New. This one's great news if you're running database operations!

What was announced?

According to AWS's What's New, Amazon Aurora MySQL now supports two new replication capabilities: multi-source replication and delayed replication. Both are available starting with Aurora MySQL version 8.4.8, in all AWS Regions where Aurora MySQL is available.

Multi-source replication lets a single Aurora MySQL cluster replicate from multiple source databases at the same time. It's designed for use cases like merging shards, or consolidating separate databases split by region or department into one place for things like reporting and backups.

Delayed replication lets you configure a binlog replica to intentionally lag behind its source by a set period of time. It's a simple safeguard against human error and logical data corruption.

The story so far

Until now, Aurora MySQL replication was mostly built around a single source replicating to a single replica. If you wanted to consolidate multiple MySQL databases into one Aurora cluster, you had to combine separate mechanisms or work around it at the application level.

Recovering from a bad change on the source was also tricky. Because replicas are designed to keep up with the source as closely as possible, a harmful change would propagate to the replica right away too. That meant recovery often required a full restore from backup, which could take a while.

What changes

With multi-source replication, you can now consolidate data from multiple MySQL databases — say, separate regional or departmental instances — directly into a single Aurora MySQL cluster. That's useful whenever you need to bring data from multiple systems into one central place for operational workflows like reporting and backups.

With delayed replication, if a harmful change is made on the source, you can stop replication to the delayed replica before that change is applied, then promote it — recovering quickly without a full database restore. It also comes in handy as a fallback during upgrades, or as a way to inspect an earlier state of your data.

Dive Deep

Multi-source replication lets a single Aurora MySQL cluster replicate from multiple source databases at the same time

As the announcement puts it, the intended use cases for multi-source replication include merging shards and consolidating separate databases — like regional or departmental instances — into one place.

For delayed replication, the mechanism is that a binlog replica lags behind the source by a configured amount of time, giving you a window to act before a harmful change on the source reaches the replica.

Both features build on MySQL's native replication capabilities. AWS points to the MySQL multi-source replication documentation and the MySQL delayed replication documentation for setup details.

Both are supported on Aurora MySQL 8.4.8 and higher, in every AWS Region where Aurora MySQL is available.

Wrap-up

• Amazon Aurora MySQL now supports two new replication features: multi-source replication and delayed replication
• Multi-source replication lets a single Aurora MySQL cluster replicate from multiple source databases at once, useful for merging shards or consolidating data
• Delayed replication keeps a binlog replica intentionally lagging, so you can recover from mistakes or data corruption without a full restore
• Both are available on Aurora MySQL 8.4.8 and higher, across every region where Aurora MySQL runs

This is a great update if you're a database engineer who needs to consolidate multiple MySQL databases into one place, or wants a straightforward recovery mechanism for human error.