Best practices for faster seeding of cross-region replica Aurora cluster to enable failback

0

Customer has currently has multiple databases in a single Aurora - MySQL Regional Cluster. Customer is planning DR strategy. They have two choices: 1\ Aurora - MySQL Regional - Cross Region Replica based on Binlog a.k.a Logical Replication 2\ Aurora - MySQL Global - Physical Replication

What is the best strategy in both the options to reduce the time it takes to seed a replica cluster in case of failback (not failover)? Customer has done experiments, and found that with no changes to their current databases to cluster ratio, it takes 3.75 hrs with Aurora Regional + Logical Replication, and 3 hrs for Aurora Global to build a new replica cluster in a new region. I did ask that typically failback has no SLA requirements, it is mostly related to failover, then why customer is interested in reducing that duration. But, again if there is no options, I will emphasize this. But, in the meantime, I would like your view on these options and considerations:

Option 1: Split the cluster to maintain a ratio with 1 DB per Cluster. This way the overall cluster size is reduced, and brining up a replica to another region would be faster regardless of whether they go with Aurora Regional or Aurora Global.

Option 2: It doesn't matter whether you split or not. Which I doubt.

If Option 1 is the right way to go, the next question comes is mechanisms to split the DBs to their individual clusters:

Option A: Take a Snapshot of existing multi-DB cluster > Restore it to either Aurora Regional or Aurora Global and delete all the databases except one. Do this for as many databases you have in that cluster. Will this way of doing reduces the overall size of the cluster? I believe no, because Aurora storage does not shrink with deleted tables or database space, it might surely claim this space to reuse (in certain conditions). So, when a replica cluster has to be created on a new region, it will also occupy the same storage space or content as it originally had before deleting the database. Is this true? If true will the behavior be different between Regional and Global offerings of Aurora.

Option B: The granularity of Aurora backup and restore is at the cluster level, so you can individual backup a database and restore it to a new cluster. Use some mechanism - DMS or other means to individual migrate the contents of the database to the new cluster. This is not clear to me, so I need some more clarity on what is AWS recommendation here.

profile pictureAWS
EXPERT
asked 5 years ago594 views
1 Answer
0
Accepted Answer

In general, when we create a read replica on RDS DB, it will take snapshot of primary/writer db instance and restore on new DB instance with recovery. In case of Aurora MySQL cross region replica creation, the DB backup will restore on secondary region. The DB restoration process in Aurora is parallel async operation. The time estimation for creating read replica is based on DB size, however the restoration process is much faster as compare to RDS MySQL because of parallel restoration from S3.

Dropping tables or databases, will not able to help you to optimize Aurora cross region replica creation process since it’s physical backup restoration process i.e. map all allocated blocks/pages to Aurora db instance including empty pages/blocks allocated.

profile pictureAWS
EXPERT
answered 5 years ago
profile picture
EXPERT
reviewed 5 months 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.

Guidelines for Answering Questions