Replication copies your mistakes too

Replication protects against losing a place. Against a bad change it does nothing, because it delivers the bad change everywhere, promptly, as designed.

A migration that drops the wrong column or a script with the wrong filter reaches every region within the replication lag. AWS's disaster recovery guidance says continuous replication may not protect against corruption or deletion unless versioning or point-in-time recovery sits beside it, and that even active-active designs fall back on backups here, with a recovery point from before the problem was noticed.

That is the gap between redundancy and independence. Two regions are redundant against a flood in one. They are not independent against anything that reaches both through a shared path, such as the same data stream or the same deploy pipeline. Shared paths are the theme of Most outages are not regional, and breaking them up is what staged rollouts are for.

Two tools cover this case. MySQL can run a replica a fixed delay behind its source, precisely so it can be recovered to the moment before a user's mistake. Point-in-time restores approach it from the other side (Backups are not a failover plan).