> For the complete documentation index, see [llms.txt](https://karansingh.gitbook.io/aws-saa-c02/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://karansingh.gitbook.io/aws-saa-c02/rds/aurora.md). # 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.