A Database Specialist must create a read replica to isolate read-only queries for an Amazon RDS for MySQL DB instance. Immediately after creating the read replica, users that query it report slow…

Question

Options

• ANew volumes created from snapshots load lazily in the background
• BLong-running statements on the master
• CInsufficient resources on the master
• DOverload of a single replication thread by excessive writes on the master

• A
  74% (31)
• B
  7% (3)
• C
  5% (2)
• D
  14% (6)

Explanation

Explanation

When an RDS Read Replica is created, it is built from a snapshot of the master instance, and Amazon EBS volumes created from snapshots use lazy loading - meaning data blocks are pulled from Amazon S3 only when first accessed, causing latency until the full volume is warmed up. This explains the immediate slow performance right after creation, as the underlying storage hasn't fully initialized yet.

Why the distractors are wrong:

• B (Long-running statements on master): While long-running queries on the master can cause replication lag, they wouldn't specifically explain slowness immediately after replica creation affecting all read queries.
• C (Insufficient master resources): Resource constraints on the master affect write performance and replication lag, but the replica operates independently for read queries once set up.
• D (Overload of single replication thread): This describes replication lag from heavy writes, not the immediate read slowness users experience right after creation.

Memory Tip: Think of a lazy employee on their first day - a new EBS volume from a snapshot doesn't do all the work upfront; it fetches data on demand from S3, causing slowness until "warmed up." If you ever see "immediately after creation + slow reads," think lazy loading/EBS initialization.

No community discussion yet for this question.