Aurora is the AWS flagship DB known to combine the perfoemance and availability of traditional enterprise databases with the siplicity and cost-effectiveness of open source databases. It is a MySQL/PostgreSQL-compatible RDBMS that provides the security, availability, and reliability of commercial databases at 1/10th the cost of competitors.
It is far more effective as an AWS database due to the 5x and 3x performance multipliers for MySQL and PostgreSQl respectively.
-
In case of an infrastructure failure, Aurora performs an automatic failover to a replica of its own.
-
Amazon 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 abtracy these cnnections. Thus, you don’t have to hard code all the host names or write your own logix for load-balancing and rerouting connections when some DB instances aren’t available.
-
By default, there are 2 copies in a minimum of 3 availability zones for 6 total copies of all of your Aurora data. This makes it possible for it to handel the potential loss of up to 2 copis of your data without impacting write availability and up to 3 copies of yout data without impacting read availability.
-
Aurora replication differs from RDS replicas in the sense that it is possible for Aurora’s replicas to be both a standby as part of a multi-AZ configuration as well as a target for read traffic. In RDS, the multi-AZ standby cannot be configured to be a read endpoint and only read replicas can serve that function.
-
With Aurora replication, you can have up to fifteen copies. If you want downstream MySQL or PostgreSQL as you replicated copies, then you can only have 5 or 1.
Aurora Serverless:
-
Aurora Serverless is a simple, on-demand, autoscaling configuration for the MySQL/PostgreSQl-compatible editions of Aurora. With Aurora Serverless, your instance automatically scales up or down and starts on or off based on your application usage. The use cases for this service are infrequent, intermittent, and unpredictable workloads.
-
This also makes it possible cheaper because you only pay per invocation
-
With Aurora Serverless, you simply create a database endpoint, optionally specify the desired database capacity range, and connect your applications.
-
It removes the complexity of managing database instances and capacity. The database will automatically start up, shut down, and scale to match your application’s needs. It will seamlessly scale compute and memory capacity as needed, with no disruption to client connections.
Cluster Endpoint
-
Using cluster endpoints, you map each connection to the appropriate instance or group of instances based on your use case.
-
You can connect to cluster endpoints associated with different roles or jobs across your Aurora DB. This is because different instances or groups of instances perform different functions. For example, to perform DDL statements you can connect to the primary instance. To perform queries, you can connect to the reader endpoint, with Aurora automatically performing load-balancing among all the Aurora Replicas behind the reader endpoint. For diagnosis or tuning, you can connect to a different endpoint to examine details.
-
Since the entryway for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention for any of your endpoints.
Reader Endpoints
-
Aurora Reader endpoints are a subset of the above idea of cluster endpoints. 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.
-
It also helps the cluster to scale the capacity to handle simultaneous SELECT queries, proportional to the number of Aurora Replicas in the cluster. Each Aurora DB cluster has one reader endpoint.
-
If the cluster contains one or more Aurora Replicas, the reader endpoint load-balances each connection request among the Aurora Replicas. In that case, you can only perform read-only statements such as SELECT in that session. If the cluster only contains a primary instance and no Aurora Replicas, the reader endpoint connects to the primary instance directly. In that case, you can perform write operations through the endpoint.
reference
