Delayed Replication w/ Aurora MySQL

Question

A customer is interested in implementing Delayed Replication for their Aurora MySQL DB instances as a way to recover quickly from a failed database migration or human error. It looks like this feature was added to RDS for MySQL in [August 2018][1] , but not Aurora MySQL.

1. Is this something that can be implemented with Aurora MySQL?
2. For Aurora MySQL customers looking to have a multi-hour delay between replicas, what is the best path forward? Should Aurora Backtrack be instead positioned here?

[1]: https://aws.amazon.com/about-aws/whats-new/2018/08/amazon-rds-mysql-now-supports-delayed-replication/

Accepted Answer

Yes, Aurora [backtrack][1] is the solution for the delayed replication however the limit for a backtrack window is 72 hours. Also, there are other [limitation][2].

Backtrack Demonstration: https://www.youtube.com/watch?v=20xXnoQA2j4&feature=youtu.be&t=1468

The RDS MySQL the replication uses the traditional binary log [MySQL replication][3] between the MASTER and Read Replicas.

However, in Amazon Aurora replicas share the same underlying [storage][4] as the source instance and replication happens on the storage layer (Without binary logs). For a write to be considered durable in Aurora, the primary instance (“master”) sends a redo stream to six storage nodes, two in each availability zone for the storage volume, and waits until four of the six nodes have responded.

[1]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html#AuroraMySQL.Managing.Backtrack.Overview
  [2]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html#AuroraMySQL.Managing.Backtrack.Limitations
  [3]: https://dev.mysql.com/doc/refman/5.6/en/replication-configuration.html
  [4]: https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/

Delayed Replication w/ Aurora MySQL

関連するコンテンツ