You are running a successful multitier web application on AWS and your marketing department has asked you
to add a reporting tier to the application. The reporting tier will aggregate and publish status reports every 30
minutes from user-generated information that is being stored in your web application s database. You are
currently running a Multi-AZ RDS MySQL instance for the database tier. You also have implemented
Elasticache as a database caching layer between the application tier and database tier. Please select the
answer that will allow you to successfully implement the reporting tier with as little impact as possible to your
database.
A.
Continually send transaction logs from your master database to an S3 bucket and generate the reports off
the S3 bucket using S3 byte range requests.
B.
Generate the reports by querying the synchronously replicated standby RDS MySQL instance maintained
through Multi-AZ.
C.
Launch a RDS Read Replica connected to your Multi AZ master database and generate reports by querying
the Read Replica.
D.
Generate the reports by querying the ElastiCache database caching tier.
Explanation:
Amazon RDS allows you to use read replicas with Multi-AZ deployments. In Multi-AZ deployments for MySQL,
Oracle, SQL Server, and PostgreSQL, the data in your primary DB Instance is synchronously replicated to to a
standby instance in a different Availability Zone (AZ). Because of their synchronous replication, Multi-AZ
deployments for these engines offer greater data durability benefits than do read replicas. (In all Amazon RDS
for Aurora deployments, your data is automatically replicated across 3 Availability Zones.)
You can use Multi-AZ deployments and read replicas in conjunction to enjoy the complementary benefits of
each. You can simply specify that a given Multi-AZ deployment is the source DB Instance for your Read
replicas. That way you gain both the data durability and availability benefits of Multi-AZ deployments and the
read scaling benefits of read replicas.
Note that for Multi-AZ deployments, you have the option to create your read replica in an AZ other than that of
the primary and the standby for even more redundancy. You can identify the AZ corresponding to your standby
by looking at the “Secondary Zone” field of your DB Instance in the AWS Management Console.
Ans D. we can query Elastic cache to complete the report within 30 min. Can’t we?
These reports need the most upto date data. If you query the cache, it will only be good if ure querying old data.
There’s nothing that says the reports are generated from data that was created or used in the last n hours.
Even if there was there’s no guarantee that the cache would be holding it.
There’s nothing to say that ElastiCache is the primary read source *backed* by a database for its persistence, so the implication is its “just a cache”.
Therefore any reads of the cache are unlikely to be satisfied and will hit the database, impacting performance of both database and the cache itself
A
The obvious answer is a read replica.
its read replica because elasticache just used for static queries