A Database Specialist is troubleshooting an application connection failure on an Amazon Aurora DB cluster with multiple Aurora Replicas that had been running with no issues for the past 2 months…

Question

Options

• AAfter a database crash, Aurora needed to replay the redo log from the last database checkpoint
• BThe client-side application is caching the DNS data and its TTL is set too high
• CAfter failover, the Aurora DB cluster needs time to warm up before accepting client connections
• DThere were no active Aurora Replicas in the Aurora DB cluster

• A
  8% (4)
• B
  63% (30)
• C
  4% (2)
• D
  25% (12)

Explanation

Explanation

When Aurora performs a failover, the process itself completes in approximately 15 seconds by updating the DNS endpoint to point to the new primary instance - but if the client application is caching the old DNS record with a high TTL (Time To Live), it will continue attempting to connect to the old, now-demoted instance for the duration of that TTL, causing an extended outage well beyond the actual failover window. This perfectly explains the 5-minute gap despite the 15-second failover completion.

Option A is incorrect because Aurora uses a cluster volume shared across all nodes, eliminating the need for redo log replay after failover - this behavior is more characteristic of traditional RDS MySQL/PostgreSQL. Option C is incorrect because Aurora replicas are already in sync with the cluster volume and do not require a warm-up period before accepting connections after promotion. Option D is incorrect because even if there were no replicas, Aurora would still complete failover by restarting the writer on a new host within ~15 seconds, not 5 minutes.

Memory Tip: Think of DNS caching as a "sticky address book" - even after someone moves (failover), your app keeps calling the old number until the TTL expires. Always set DNS TTL to ≤30 seconds for Aurora connection strings to minimize outage windows.

No community discussion yet for this question.