Aurora

• Aurora is a fully managed relational database engine that's compatible with MySQL and PostgreSQL.

• With some workloads, Aurora can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL.

• The underlying storage grows automatically as needed.

  • An Aurora cluster volume can grow to a maximum size of 128 tebibytes (TiB).

• Aurora also automates and standardizes database clustering and replication.

High Availability

• Aurora automatically divides your database volume into 10GB segments spread across many disks.

  • Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones.

• It can handle the loss of up to two copies of data without affecting write availability.

• It can handle the loss up to three copies without affecting read availability.

• Amazon Aurora storage is also self-healing.

  • Data blocks and disks are continuously scanned for errors and repaired automatically.

• You can create 1 to 15 replicas, in any of 3 AZs, and Amazon RDS will automatically include them in failover primary selection in the event of a database outage.

Global Database

• An Aurora global database consists of one primary AWS Region where your data is maintained, and up to five read-only, secondary AWS Regions.

  • Aurora replicates data to the secondary AWS Regions with typical latency of under a second.

• You issue write operations directly to the primary DB instance in the primary AWS Region.

• An Aurora global database uses dedicated infrastructure to replicate your data, leaving database resources available entirely to serve application workloads.

• The Aurora cluster in the primary AWS Region where your data is mastered performs both read and write operations.

• The clusters in the secondary Regions enable low-latency reads.

• You can scale up the secondary clusters independently by adding one of more DB instances (Aurora Replicas) to serve read-only workloads.

Aurora Endpoints

• Aurora typically involves a cluster of DB instances instead of a single instance.

• Each connection is handled by a specific DB instance.

• When you connect to an Aurora cluster, the host name and port that you specify point to an intermediate handler called an endpoint.

• Aurora uses the endpoint mechanism to abstract these connections.

• An endpoint is represented as an Aurora-specific URL that contains a host address and a port.

• Cluster endpoint

  • A cluster endpoint (or writer endpoint) for an Aurora DB cluster connects to the current primary DB instance for that DB cluster.

  • This is the only endpoint which can perform write operations such as DDL statements.

  • Because of this, the cluster endpoint is the one that you connect to when you first set up a cluster or when your cluster only contains a single DB instance.

• Reader endpoint

  • A reader endpoint for an Aurora DB cluster provides load-balancing support for read-only connections to the DB cluster.

  • Use the reader endpoint for read operations, such as queries.

  • By processing those statements on the read-only Aurora Replicas, this endpoint reduces the overhead on the primary instance.

• Custom endpoint

  • A custom endpoint for an Aurora cluster represents a set of DB instances that you choose.

  • An Aurora DB cluster has no custom endpoints until you create one.

Aurora Serverless

• On-demand, autoscaling configuration for Aurora.

• Unlike Aurora provisioned database clusters for which you manually manage capacity, an Aurora Serverless database cluster is a database cluster that scales compute capacity up and down based on your application's needs.

• Provides a relatively simple, cost-effective option for infrequent, intermittent, or unpredictable workloads.

  • Cost-effective because it automatically starts up, scales compute capacity to match your application's usage, and shuts down when it's not in use.

• Instead of provisioning and managing database servers, you specify Aurora capacity units (ACUs).

  • Each ACU is a combination of processing and memory capacity.

Aurora Multi-Master Clusters

• In a multi-master cluster, all database instances have read/write capability.

• Writer:

  • A database instance that can perform write operations.

  • With a single-master cluster, if the writer becomes unavailable, the failover mechanism promotes another DB instance to become the new writer.

• Multi-master:

  • An architecture for Aurora clusters where each DB instance can perform both read and write operations.

  • Best suited for segmented workloads, such as for multitenant applications.

• Single-master:

  • Default architecture for Aurora clusters.

  • A single DB instance (the primary instance) performs writes.

  • All other DB instances (the Aurora Replicas) handle read-only query traffic.

  • Appropriate for general-purpose applications.

• Write conflict:

  • A situation that occurs when different DB instances attempt to modify the same data page at the same time.