Aurora

Aurora Simplified

Aurora is the AWS flagship DB known to combine the performance and availability of traditional enterprise databases with the simplicity 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.

Aurora Key Details

• 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 abstract these connections.
  • Thus, you don't have to hard code all the host names or write your own logic 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 copies total for all of your Aurora data.

• This makes it possible for it to handle the potential loss of up to 2 copies of your data without impacting write availability and up to 3 copies of your data without impacting read availability.

• Aurora `storage is self-healing and data blocks and disks are continuously scanned for errors. If any are found, those errors are repaired automatically.

  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 (1) or PostgreSQL (5) as you replicated copies

• Automated failover is only possible with Aurora read replication

• Automated backups are always enabled on Aurora instances and backups don’t impact DB performance.

• You can also take snapshots which also don’t impact performance. Your snapshots can be shared across AWS accounts.

A common tactic for migrating RDS DBs into Aurora RDs is to create a read replica of a RDS MariaDB/MySQL DB as an Aurora DB. Then simply promote the Aurora DB into a production instance and delete the old MariaDB/MySQL DB.

• Aurora starts w/ 10GB and scales per 10GB all the way to 64 TB via storage autoscaling. Aurora's computing power scales up to 32vCPUs and 244GB memory

Aurora Endpoints

Cluster Endpoints

• 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

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.

• 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.
• There are upto 15 Aurora Read Replicas because a Reader Endpoint to help handle read-only query traffic.
• 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.

Custom endpoint

• represents a set of DB instances that you choose.
• When you connect to the endpoint, Aurora performs load balancing and chooses one of the instances in the group to handle the connection.
• You define which instances this endpoint refers to, and you decide what purpose the endpoint serves.

Instance endpoint

• connects to a specific DB instance within an Aurora cluster.
• The instance endpoint provides direct control over connections to the DB cluster.
• The main way that you use instance endpoints is to diagnose capacity or performance issues that affect one specific instance in an Aurora cluster.

Aurora Global Database

• An Aurora global database spans multiple AWS Regions, enabling low latency global reads and disaster recovery from region-wide outages.
• Consists of one primary AWS Region where your data is mastered, and one read-only, secondary AWS Region.
• Aurora global databases use dedicated infrastructure to replicate your data.
• Aurora global databases introduce a higher level of failover capability than a default Aurora cluster.
• An Aurora cluster can recover in less than 1 minute even in the event of a complete regional outage. This provides your application with an effective Recovery Point Objective (RPO) of 5 seconds and a Recovery Time Objective (RTO) of less than 1 minute.
• Has managed planned failover capability, which lets you change which AWS Region hosts the primary cluster while preserving the physical topology of your global database and avoiding unnecessary application changes.

Monitoring

• Subscribe to Amazon RDS events to be notified when changes occur with a DB instance, DB cluster, DB cluster snapshot, DB parameter group, or DB security group.
• Database log files
• RDS Enhanced Monitoring — Look at metrics in real time for the operating system.
• RDS Performance Insights monitors your Amazon RDS DB instance load so that you can analyze and troubleshoot your database performance.
• Use CloudWatch Metrics, Alarms and Logs

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.