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 ElasliCache database caching tier.
I’d say C, because A is not logical, since we’d be moving away from RDBM. Not B, because standby replicas are not query’able. Not D, because we’d be changing the caching paterns and the user data might be purged in favor of reporting data or otherwise we’d be hitting production database without data found in elasticache
C
C
C.
Launch a RDS Read Replica connected to your Multi AZ master database and generate reports by querying the
Read Replica.
c
Agree with “A”
A. Fetching data from S3, does not impact performace of DB by any means
B & C will have effect on the performance of DB due to eventual consistency behavior
D may impact overall performance of the application or may not have all the data it should have
This question has been asked many different ways – it’s c
The two best choices seem to be A,C. Now out of the two which is the least impacting to the DB, that seems to be impressed upon in the question at the very end. I could not find from my search which out of the two is less impacting to the master DB. Choice A does byte range requests, whereas, C does the replication by creating Read Replicas to the master DB instance and is more native and perhaps more efficient and least impacting to the master DB. So, I would say C.
I would choose C:
A. This choice is incorrect because, while RDS may be storing SQL transaction logs on the back end for its use in point-in-time recovery, you do not have access to do anything with them. It’s just one of those parts of the RDS service that AWS manages for you.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.html
(In that doc, search for: “Viewing, downloading, or watching transaction logs is not supported.”)
B. Incorrect because Multi-AZ standby DBs are not query-able for read purposes. Use a read replica for that.
C. Correct, this is the easiest way to get an “out of band” copy of the database for your analysis tools to play with, while only very minimally impacting the performance on the front end. (The master DB instance would have to perform asynchronous replication operations to the read replica, which has a very small performance impact. Unless you’re replicating to many read replicas in which the performance hit could become noticeable. If you need many read replicas, use Aurora, which has workarounds for this performance hit and can do up to 15 read replicas. Or if your app is married to MySQL, do read replicas of read replicas if you need more than the limit of 5 and can deal with the asynchronous replication delay.)
D. This one is plausible at first glance, but in practice could impact performance more than the read replica option due to potentially very large queries that the reporting tier could be running. Also, if your cache is only maintaining the most recently-used records, you could miss pieces of the data you would want to have for reporting. Reporting would probably need access to everything across the board in your DB.
I completely agree with kirrim answer and its perfrect.
(like)
C.
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.