Amazon Aurora High Availability

• AWS Aurora is the fastest growing service
• Database service with superior MySQL and PostgreSQL engine compliant service
• Separate the compute layer and the storage layer

Amazon Aurora Architecture Overview

• A key architectural decision that allows you to dial-up and down the availability of your data
• The compute layer when launched can be provisioned in several configurations — providing varying forms of performance and availability
• The compute layer is implemented using EC2 instances, but since this is a managed service these will not show up on the EC2 console

Database management RDS vs. Aurora

• When compared with RDS — the management of data from a replication viewpoint is fundamentally different
• With RDS data needs to be replicated from the master to each of its replicas
• Aurora on the other hand has no need for replication since it uses and shares a single volume amongst all compute instances

Aurora Data Consistency

• Aurora uses a quorum and gossip protocol baked within the storage layer to ensure that the data remain consistent
• Together the quorum and gossip protocol provide a continuous self-healing mechanism for the data
• To peer to peer gossip protocol is used to ensure that data is copied across each of 6 storage nodes
• Aurora in general, and regardless of the compute layer setup always provides 6 way replicated storage across 3 availability zones
• Because of Aurora storage layer design, Aurora is only supported in regions that have 3 or more availability zones
• Aurora provides both automatic and manual failover of master either of which takes approximately 30 seconds to complete
• In the event that Aurora detects a master going offline, Aurora will either launch a replacement master or promote an existing read replica to the role of master, with the latter being the preferred option as it is quicker for this promotion to complete

Connection endpoint

There are 4 different connection endpoint types. Which one you use is dependent on your requirement:

• Cluster Endpoint — The cluster endpoint points to the current master database instance. Using the Cluster endpoint allows your application to perform read and write against the master instance
• Reader Endpoint — The reader endpoint load balancers connections across the read replica fleet within the cluster
• Custom Endpoint — This endpoint can be used to group instances based on instance size or maybe group them on a particular DB parameter group. You can then dedicate the custom endpoint for a specific role or task within your organization. For example, a requirement to generate month-end reports — You could connect custom endpoint specifically for this task
• Instance Endpoint — An instance endpoint maps directly to a cluster instance. Each and every cluster instance has its own endpoint. You can use an instance endpoint when you want fine-grained control over which instance you need to serve your request

General Points

• Read intensive workloads should connect via the reader endpoint
• Reader and Custom connection endpoints are designed to load balance connections across their members
• Connection endpoint load balancing is implemented internally using Route53 DNS
• Be careful in the client layer not to catch the connection endpoint lookups longer than their specific TTLs
• Connection endpoints are mostly applicable and used in “Single Master with Multiple Read Replica” setups

Nadtakan Futhoem — Sr. Software Engineer