This chapter is from the book
This chapter is from the book
This chapter is from the book
Read Replicas
This section covers the following official AWS Certified SysOps Administrator - Associate (SOA-C02) exam domain:
Domain 2: Reliability and Business Continuity
There are five general approaches to scaling database performance:
Vertical scaling: You can add more CPU and RAM to the primary instance.
Horizontal scaling: You can add more instances to a database cluster to increase the available CPU and RAM, but this approach is not always supported.
Sharding: When horizontal scaling is not supported, you can distribute the dataset across multiple primary database engines, thus achieving higher write performance.
Caching: You can add a caching cluster to offload reads, which can be expensive.
Read replicas: You can add read replicas to offload read traffic, possibly asynchronous.
Read replicas can potentially offer the same benefit of read offloading that caching can have for your application. One big benefit of read replicas is that the whole database is replicated to the read replica, not just frequently read items. This means that read replicas can be used where the reads are frequently distributed across the majority of the data in the database. As you can imagine, this would be very expensive and resource intensive to achieve in the cache. You would need to provision enough in-memory capacity (potentially terabytes), read the entire database, and write the data into the cache before you could perform any complex operation on the data in the cache. Sometimes complex operations can’t even be performed on the caching server; for example, joins of multiple tables for analytics, business intelligence, or data mining purposes are just not possible within the cache.
This is where read replicas excel. You can introduce read replicas in most instance-based AWS database services, including RDS, Aurora, DocumentDB, and Neptune.
In the RDS service, up to five read replicas can be deployed in any MySQL, MariaDB, PostgreSQL, or Oracle database. Because the data resides on the volume attached to the instance, built-in database replication tools are used to replicate the data across the network to the read replica. This means that read replicas introduce additional load on the primary instance and that the replication is always asynchronous with a potential lag of a few seconds to potentially a few minutes in extreme cases. Figure 4.12 illustrates RDS read replicas.
)
FIGURE 4.12 RDS read replicas
The replica can be placed in any availability zone in the same region as the primary database or can be deployed in a cross-region deployment. A read replica can also be promoted to a primary instance, which means that establishing a read replica can be an easy way to clone a database. After the replica is promoted to primary only, a sync of all the missing data is required.
Other AWS database services employ a decoupled compute–datastore approach. For example, the AWS Aurora service stores all the data on a cluster volume that is replicated to six copies across (at least) three availability zones. The primary instance has read and write access. All writes are sent as changelogs directly to the six nodes of the storage volume, and the commit to the database page is done at the storage cluster. This means that the replication is near synchronous with potentially no more than a few milliseconds of replication lag due to the network distance between the cluster volume nodes in other availability zones and several hundred milliseconds if the replication is done across regions. Additionally, Aurora supports up to 15 read replicas per region and can be deployed to multiple regions with an additional 16 read replicas in other regions. All of the read replicas read from the same cluster volume, meaning they can deliver near synchronous data for each read request. The read replicas can also be seamlessly scaled because there is no requirement to replicate the data on to the replica. When a replica is started, it is simply connected to the cluster volume. This allows the cluster to avoid initial replication lags that you would see in traditional databases. This feature can be used both for elasticity and vertical as well as horizontal scaling of the cluster. Figure 4.13 illustrates an Aurora cluster design.
)
FIGURE 4.13 Aurora cluster design
A similar approach to decoupling the storage volume and the database nodes is used in DocumentDB, Neptune, and so on.
On top of this capability, Aurora can forward some read-heavy analytical operations to the cluster volume nodes and offload the primary from having to perform the reads for any JOIN, GROUP BY, UNION, and such operations across approximately a million or more rows. This capability extends the lightweight analytics capabilities of RDS read replicas to deliver much more power to your analytics queries.
Aurora natively supports MySQL and PostgreSQL databases and is slightly more expensive than RDS MySQL and RDS PostgreSQL.
Cram Quiz
Answer these questions. The answers follow the last question. If you cannot answer these questions correctly, consider reading this section again until you can.
1. You have been instructed to eliminate any inefficiencies in the following deployment:
Web tier: EC2 autoscaling group scaling on CPU usage, 30% floor, 70% ceiling, minimum 1, maximum 10.
App tier: EC2 autoscaling group scaling on CPU usage, 20% floor, 80% ceiling, minimum 1, maximum 6.
Cache tier: 1 ElastiCache Memcached cluster with 2 partitions
Database tier: Multi-AZ MySQL RDS with 3 read replicas
Which of the following would allow you to cost optimize the cluster? (Choose all that apply.)
A. Evaluate whether all RDS read replicas are required.
B. Evaluate the maximum on the App and Web EC2 autoscaling groups.
C. Evaluate the partition configuration of the ElastiCache cluster.
D. Evaluate the network performance if the app tier matches the network performance of the database tier.
2. You have been asked to propose a solution to scale the read portion of an application database back end in the most cost-effective manner possible. Your application runs Linux LAMP stack with a 30 GB MySQL RDS Multi-AZ back end. The read-heavy operations are very predictable and occur during a particularly heavy four-hour operation each week and require the whole dataset. Which option would you recommend?
A. Replace the RDS MySQL with Aurora MySQL and let Aurora add read replicas automatically as needed.
B. Point the read-heavy operation at the RDS Multi-AZ replica in the other availability zone.
C. Deploy a read replica in RDS. Point the application at the RDS read replica. Terminate the read replica after the read-heavy operation is complete. Repeat the process with a script next week.
D. Deploy a read replica in RDS. Point the application at the RDS read replica. Create a script that powers off the read replica after the read-heavy operation is complete and powers it on before the next operation with enough time to synchronize the changes.
Cram Quiz Answers
1. Answer: A and C are correct. You should always evaluate whether the read replicas and caching clusters you deployed are required and properly scaled.
2. Answer: C is correct. Although A and D are possible solutions, deploying a read replica on a weekly basis would be the most cost-effective way to achieve this goal because the operation is sparse in nature and lasts for only four hours. Deploying a read replica is performed from a snapshot and can be just as fast or even faster than replicating a week’s worth of data to the powered-off replica. Although the charges of powered-off instances are reduced, they are not zero. Remember also that you can stop a DB instance for up to seven days. If you don’t manually start your DB instance after seven days, your DB instance is automatically started so that it doesn’t fall behind any required maintenance updates. B is impossible because a Multi-AZ replica is not accessible for any SQL operations.