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.

PreviousRDS IAM database authentication NextElastiCache

Last updated 4 years ago

Was this helpful?

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.