# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://karansingh.gitbook.io/aws-saa-c02/rds/aurora.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.