Search code examples
amazon-web-servicescloudrds

Multi-az deployment in AWS Aurora and read replicas


can someone help me with these questions please :

1- the documentation stated that Aurora will automatically fail-over to the read replicas, my question is how does it select the replica which will be promoted if you have more than one with different instances class?

2- can I disable this automatic fail-over (just asking, not stating that I will do it)

3- what is the purpose of multi-az in Aurora if you can have the same effect with much more control on instances classes while creating replicas and let Aurora do the auto fail-over for you. please correct me if I am wrong with this assumption.

thanks in advance


Solution

  • The algorithm for election of a new master in case of failure is not really documented... but it doesn't seem to matter, because Aurora replicas seem to be different than other RDS replicas, because all the instances in the cluster are necessarily of the same instance class.

    Unlike other RDS offerings, read replicas in Aurora do not appear to have an independent copy of the backing store -- instead, the backing store itself provides redundancy, being replicated at the storage level with two copies in each of three availability zones.

    The cluster volume is made up of multiple copies of the data for the DB cluster, but the data in the cluster volume is represented as a single, logical volume to the primary and Aurora Replicas in the DB cluster.

    Because the cluster volume is shared among all instances in your DB cluster, no additional work is required to replicate a copy of the data for each Aurora Replica.

    http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html

    Multi-AZ in Aurora is also not the same thing -- with other RDS products, multi-AZ involves a second, invisible instance, running in parallel with the master. The Aurora literature uses the phrase "multi-AZ technology," but the meaning appears to be different. Note that the Aurora pricing tables don't show a separate pricing rate for "multi-AZ" the way MySQL and MariaDB do.

    Failover doesn't appear to be something that can be disabled. Even if you have no replicas, Aurora will still "fail over" if the master fails -- but it does it by spinning up a replacement master using the existing cluster volume as the backing store.