Aurora Global Database is an option supported on AWS Aurora MySQL and PostgreSQL engines enabling two primary use cases.
The first use case supports a disaster recovery solution that can handle a full regional failure with a low recovery point objective (RPO) and a low recovery time objective (RTO) while minimizing the performance impact on the protected database cluster.
The second major use case for Aurora Global Database is providing read-only copies of an Amazon Aurora cluster in up to five remote regions to serve users close to those regions. This provides users in remote regions with lower latency reads and some write capabilities than having to connect to the, further away, primary region.
Aurora was designed with high performance, reliability, and scalability in mind. It delivers high performance through innovative storage and replication mechanisms. It accesses data fast and supports high throughput. Aurora automatically scales data volume, ensuring performance and stability as the workload increases. Its built-in high availability mechanisms include automatic data backups and the ability to create replicas for read load balancing.
AWS Aurora is designed for intensive heavy-duty operations.
The AWS Aurora can be considered as a global database, that contains one primary and a few secondary clusters spread across multiple regions. The primary cluster of AWS Aurora is the cluster having one writer/reader DB instance with some extra readers. And secondary clusters are AWS Aurora clusters with reader DB instances.
AWS Aurora reader instances allow the offload of read-intensive workloads, to make the system more performant and scalable.
The AWS Aurora global database includes multiple AWS regions. It allows to have low-latency global reads and to enable disaster recovery in case of emergency across AWS regions.
One of the remarkable features of AWS Aurora is the distributed, fault-tolerant, auto-scaling storage decoupled from compute resources. The Amazon Aurora storage engine is a distributed SAN. It spans multiple availability zones (AZs) in a region. The storage is managed by AWS Aurora, and there is no need to provision its volume and I/O configuration.
The storage of AWS Aurora is distributed across regions, that’s why it takes milliseconds to get transactions executed on the primary cluster DB instance to be propagated to the secondary clusters.
The choice of AWS Aurora represents an advantage for critical enterprise-grade systems that require continuous availability. AWS Aurora replicates data across AZs in a region for high availability. It synchronously replicates data to six storage nodes connected to cluster volume across Availability Zones when it is written to the primary DB instance. In addition to avoiding I/O freezes and minimizing latency spikes during system backups, this approach offers data redundancy.
There are two main configurations of AWS Aurora: provisioned and serverless.
AWS Aurora provisioned option allows the creation of DB instances in the clusters of a specific type, for example, r7g.4xlarge. This is suitable when the workload has a constant predictable pattern. It creates the right balance between resources, performance, and cost.
In case workloads are changing, and are hardly predictable it can choose serverless AWS Aurora instances configuration. It allows scaling up and scaling down DB instances in the clusters elastically, transparently, and automatically according to the actual load. The Aurora serverless configuration uses minimal and maximum ACUs (Aurora Compute Units). Each ACU is associated with allocated CPU, memory, and networking. Once the workload of the DB instance increases, there is a demand for more resources, and the DB instance scales up automatically according to the configured ACUs range. Once the workload decreases, the AWS Aurora scales down automatically. It allows one to adjust performance better and helps to keep the optimal cost.
AWS Aurora’s I/O-Optimized storage configuration allows predictable pricing for applications and improved price performance, significant cost savings for I/O-intensive applications.
AWS Aurora's original failover mechanism deserves special attention. In case of a possible outage Aurora automatically performs failover to a reader DB instance in the same cluster. In case no reader exists in the cluster, it will create it automatically in case of failover. In case there are a few readers in the cluster the tier DB instance configuration parameter defines the priority of the failover. AWS Aurora ensures that the failover will not require changing the connection string on the application side. In addition, in the case of global database configuration, Aurora allows failover to another region.
Top comments (0)