An application allows users at a company's headquarters to access product data. The product data is stored in an Amazon RDS MySQL DB instance. The operations team has isolated an application performance slowdown and wants to separate read traffic from write traffic. A solutions architect needs to optimize the application's performance quickly.
What should the solutions architect recommend?
To optimize the application's performance and separate read traffic from write traffic, creating read replicas for the database and configuring them with the same compute and storage resources as the source database is the best approach. Read replicas allow the application to direct read-only queries to these replicas, thus offloading read traffic from the primary database and improving overall performance. Configuring the read replicas with the same resources ensures that they can handle the read workload efficiently, providing the necessary performance boost.
The solutions architect should recommend option D: Create read replicas for the database. Configure the read replicas with the same compute and storage resources as the source database. Creating read replicas allows the application to offload read traffic from the source database, improving its performance. The read replicas should be configured with the same compute and storage resources as the source database to ensure that they can handle the read workload effectively.
The best solution is to create read replicas for the database and configure them with the same compute and storage resources as the source database. The key requirements are to quickly optimize performance by isolating reads from writes. Read replicas allow read-only workloads to be directed to one or more replicas of the source RDS instance. This separates reporting or analytics queries from transactional workloads. The read replicas should have the same compute and storage as the source to provide equivalent performance for reads. Scaling down the replicas would limit read performance. Using Multi-AZ alone does not achieve read/write separation. The secondary AZ instance is for disaster recovery, not performance.
A. In a Multi-AZ deployment, a standby replica of the database is created in a different AZ for high availability and automatic failover purposes. However, serving read requests from the primary AZ alone would not effectively separate read and write traffic. Both read and write traffic would still be directed to the primary database instance, which might not fully optimize performance. B. The secondary instance in a Multi-AZ deployment is intended for failover and backup purposes, not for actively serving read traffic. It operates in a standby mode and is not optimized for handling read queries efficiently. C. Configuring the read replicas with half of the compute and storage resources as the source database might not be optimal. It's generally recommended to configure the read replicas with the same compute and storage resources as the source database to ensure they can handle the read workload effectively. D. Configuring the read replicas with the same compute and storage resources as the source database ensures that they can handle the read workload efficiently and provide the required performance boost.
Can anyone explain why B is not an option?
CHATGPT says: To optimize the application's performance and separate read traffic from write traffic, the solutions architect should recommend creating read replicas for the database and configuring them to serve read requests. Option C and D both suggest creating read replicas, but option D is a better choice because it configures the read replicas with the same compute and storage resources as the source database. Option A and B suggest changing the existing database to a Multi-AZ deployment, which would provide high availability by replicating the database across multiple Availability Zones. However, it would not separate read and write traffic, so it is not the best solution for optimizing application performance in this scenario.
Multi-AZ: Synchronous replication occurs, meaning that synchronizing data between DB instances immediately can slow down application's performance. But this method increases High Availability. Read Replicas: Asynchronous replication occurs, meaning that replicating data in other moments rather than in the writing will maintain application's performance. Although the data won't be HA as Multi-AZ kind of deployment, this method increases Scalability. Good for read heavy workloads.
Keyword: "separate read traffic from write traffic" = Read Replica = Option A and B are not the correct answer. Option C: Why would you try to have half the resource for read replicas ?. It must be equal resources to ensure read load can be served consistently. Correct Answer is D: Read replica with same compute power as source database instance.
By default, a read replica is created with the same storage type as the source DB instance. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
A: This will not have any change as you are still reading from same instance as you are writing to B: Not possible (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html) C: Why would you do that even if that was possible? No one asked to save on cost D: Read replicas are normally for handling read-only traffic
In a Multi-AZ deployment, the standby instance is kept in sync with the primary instance and is used for failover purposes only. You cannot read data from the standby instance in a Multi-AZ deployment. If you need to offload read traffic from the primary instance, you can create one or more Read Replicas. Read Replicas are read-only copies of your database that can be used to offload read traffic from the primary instance, which can help improve performance
D. Configuring the read replicas with the same compute and storage resources as the source database ensures that they can handle the read workload efficiently and provide the required performance boost.
You can create up to 15 read replicas from one DB instance within the same Region. For replication to operate effectively, each read replica should have the same amount of compute and storage resources as the source DB instance. If you scale the source DB instance, also scale the read replicas.
I think for RDS it is 5 read replicas. 15 is for aurora serverless
D makes the most sense.
Both B and D would work. Amazon RDS now offers Multi-AZ deployments with readable standby instances (also called Multi-AZ DB cluster deployments) . You should consider using Multi-AZ DB cluster deployments with two readable DB instances if you need additional read capacity in your Amazon RDS Multi-AZ deployment and if your application workload has strict transaction latency requirements such as single-digit milliseconds transactions. https://aws.amazon.com/blogs/database/readable-standby-instances-in-amazon-rds-multi-az-deployments-a-new-high-availability-option/#:~:text=read%20replicas.-,Amazon%20RDS,-now%20offers%20Multi
Read replica + Same resources as we may need to turn replica to primary in few cases
D meets the requiremets.
Option C suggests creating read replicas for the database and configuring them with half of the compute and storage resources as the source database. This is a better option as it allows read traffic to be offloaded from the primary database, separating read traffic from write traffic. Configuring the read replicas with half the resources will also save on costs.
Err, just curious, what if the production database is 51% full? Your half storage read replica would explode…?
If the source database is already 40% full, the read replica's performance will degrade as it is @ 80% capacity. This will not optimize the apps performance.
Option D
D is correct
D https://www.examtopics.com/discussions/amazon/view/46461-exam-aws-certified-solutions-architect-associate-saa-c02/