Welcome back! In this lecture, you’ll learn about the HA configuration options available within Amazon Aurora. Knowing of these options and how to apply them will ensure that your applications run with maximum uptime.

For starters, Amazon Aurora which is often quoted as AWS’s fastest growing service is a database service which provides superior MySQL and Postgres engine compliant performance, and is designed in a way that separates the compute layer from the storage layer. Separating the compute layer and storage layer from each other is a key architectural decision which allows you to dial up and down the availability of your data - mostly in the way that read replicas can be easily introduced and removed at will - more on this later.

The compute layer when launched can be provisioned in several configurations - providing varying forms of performance and availability which I’ll cover off individually in the coming slides. The compute layer is implemented using EC2 instances, but since this is a managed service these will not show up within the EC2 console.

The storage layer is shared amongst all compute nodes within the cluster regardless of the cluster configuration. Aurora stores data in 10 GB blocks, with each block being replicated six times across three AZs - two within each availability zone. From an availability and durability point of view, Aurora can handle up to 3 copies lost for reads, and up to 2 copies lost for writes. This makes the data highly redundant, durable, and available. The storage layer is presented to the compute layer as a single logical volume. This same single logical volume is shared across all compute instances involved in the compute layer whether it be a master or read replica - allowing the read replicas to accomplish the near-identical query performance as the master itself.

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 logical volume amongst all compute instances.

Aurora uses a quorum and gossip protocol baked within the storage layer to ensure that the data remains consistent. Together the quorum and gossip protocol provide a continuous self-healing mechanism for the data. Reads require a quorum of 3 and Writes require a quorum of 4. The peer to peer gossip protocol is used to ensure that data is copied across each of the 6 storage nodes. If a storage node goes offline intermittently - when it comes back online it will receive all data modifications from its peers via the gossip protocol. Availability zones are connected together using very high-speed backbone interconnects - which means that the gossip protocol is very fast.

Aurora in general, and regardless of the compute layer setup - always provides 6 way replicated storage across 3 availability zones. Because of Aurora's storage layer design, Aurora is only supported in regions that have 3 or more availability zones.

Aurora provides both automatic and manual failover of the master either of which takes approximately 30 seconds to complete - its very quick one of the great benefits of using Aurora.

In the event that Aurora detects the master going offline, an automatic failover will be performed. In this scenario, 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.

Connecting to an Aurora database is performed by using one of the database connection endpoints.

Connection endpoints are created by the service to allow you to connect particular compute instances of the cluster.

There are 4 different connection endpoint types. Which one you end up using is dependent on your requirements. Let’s now quickly review each of them:

• Cluster Endpoint: The cluster endpoint points to the current master database instance. Using the Cluster endpoint allows your application to perform read and writes against the master instance.
• Reader Endpoint: The reader endpoint load balancers connections across the read replica fleet within the cluster.
• Custom Endpoint: A custom endpoint load balancer's connections across a set of cluster instances that you choose and register within the custom endpoint. Custom endpoints 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, you may have a requirement to generate month end reports - therefore you connect to a custom endpoint that has been specifically set up for this task. 
• Instance Endpoint: An instance endpoint maps directly to a cluster instance. Each and every cluster instance has its own instance endpoint. You can use an instance endpoint when you want fine-grained control over which instance you need to service your requests.

As a general rule of thumb - read-intensive workloads should connect via the reader endpoint.

Reader and Custom connection endpoints are designed to load balance connections across their members - with the intention of spreading load across the member instances. Connection endpoint load balancing is implemented internally using Route 53 DNS - therefore be careful in the client layer not to cache the connection endpoint lookups longer than their specified TTLs.

Connection endpoints are mostly applicable and used in “Single Master with Multiple Read Replica” setups.