During a failover test, the standby database became the new primary within a minute, but the applications kept trying to reach the old server for over an hour until their configuration files were edited. Each application's connection string contained the old server's IP address. How should this be prevented?
Select an answer to reveal the explanation.
Short Explanation
Hard-coding an IP is like printing someone's desk number on the invitations; move the desk and nobody finds them. A DNS name is the reception desk that points people to wherever they sit now. Keep the TTL low so clients ask again quickly after you fail over.
Full Explanation
Clients should reach a database through a name, not a fixed address, so that the location can change without touching every application. With a DNS record, or a cluster listener that is itself published in DNS, pointing to the current primary, the failover process updates the record to the new primary's address. A low time to live limits how long clients and resolvers cache the old answer, so connections move to the new server within roughly the TTL plus the application's reconnect logic. Editing hard-coded IP addresses after every failover is the manual, error-prone process the stem shows took over an hour; it does not scale and defeats a one-minute failover. Reassigning a MAC address to the new primary is a low-level network workaround that conflicts with how addresses and switching are normally managed, does not work across subnets and does not change the destination IP the applications use. Raising the TTL makes the problem worse, because clients keep the stale address cached longer after the record changes. Exam caveat: some drivers and connection pools cache resolved addresses themselves, so pool settings must also allow re-resolution. Operational check: during the next failover test, time how long it takes for application connections to appear on the new primary after the DNS record changes.