In AWS the Amazon Relational Database Service (RDS) allows you to deploy, manage, and operate traditional relational databases with managed options for elasticity, scalability, as well as high availability and resilience.
You can easily make these databases highly available by deploying them in a Multi-AZ deployment. When running Multi-AZ, the service maintains a synchronous replica of the database in another availability zone. This means that any data that has been written to the primary is sent over to the replica. The replica stores the data and sends a successful response. Only then will a successful response be provided within the SQL transaction. Thus, any transaction committed to the primary is guaranteed to be stored on the secondary as well. If the primary fails, the service detects the failure and promotes the secondary into the primary role. A new secondary is deployed in another AZ from the most recent snapshot and synchronized with the new primary. Figure 5.3 demonstrates a resilient database design.
FIGURE 5.3 RDS Multi-AZ
Remember that the secondary Multi-AZ replica is never available for any read or write operations while in the secondary role. Its sole purpose is to enable almost instant failover in case of the primary’s failure.
As mentioned in the previous chapter, read replicas can be added to a primary database whether it utilizes Multi-AZ or not. A read replica can also be manually promoted to a primary, but you should not expect the data to be synchronous on read replicas. The promotion of a read replica to a primary can be useful if you are replicating the database across the region and intend to promote the replica in case of a regional outage or other type of disaster recovery.
Amazon Aurora is the next-generation open-source engine with native support for both MySQL and PostgreSQL engines. Aurora has a decoupled architecture with all data being stored on a volume that is replicated six times across three AZs. The SQL front end resides on the Aurora nodes. Aurora supports one primary node for read/write access and up to 15 Aurora replicas in the same region. Aurora clusters can also be replicated to other regions with up to 16 replicas of the database in each of the other regions. Figure 5.4 demonstrates the Aurora cluster design.
FIGURE 5.4 Aurora architecture
Because all nodes of the Aurora cluster access the same cluster volume, the state of the replication across the cluster is near synchronous and depends on the performance of the underlying cluster volume rather than the instances themselves. This means that there is no overhead when calculating the performance required for the read replicas like there is with RDS. The primary and the replicas also have different DNS names provided, so you can easily configure your application to send all writes to the primary and all read requests to the read replicas. Any Aurora read replica can also instantly be promoted into the primary role. This capability is useful in case of a failure of the primary instance or when you want to increase the size of the primary instance.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
