A retailer replicates its primary database asynchronously to a replica on another continent. Monitoring shows the replica running about 45 seconds behind the primary. The primary site then fails, and the team promotes the replica to keep the business running. What is the most likely consequence of this failover?
Select an answer to reveal the explanation.
Short Explanation
Asynchronous replication is like mailing copies of your notes overseas: the post is always a little behind. If your house burns down, whatever was still in the mailbox is gone. That lag figure on your dashboard is literally the slice of committed work you're betting with, so don't confuse async with the "wait for the ack" behavior of synchronous mode.
Full Explanation
With asynchronous replication the primary commits a transaction locally and returns success before the change reaches the replica. Changes then travel to the replica in the background, so the replica always trails by some amount, here about 45 seconds. When the primary site fails, any committed transactions still in flight or queued on the lost primary never arrive, and promoting the replica makes its slightly older state the new truth. The data loss is therefore bounded by the replication lag, which is why lag is monitored against the recovery point objective. The claim that no data is lost describes synchronous replication, where the primary waits for the replica's acknowledgment; asynchronous mode explicitly does not wait. The idea that the replica must replay the failed primary's log before promotion is wrong in this scenario because that log is on the site that failed; the replica can be promoted with what it has, accepting the loss. Saying only uncommitted transactions are lost misreads lag: uncommitted work is always discarded on failover, but lag means committed transactions are at risk too. Exam caveat: long-distance links usually force asynchronous mode, so design the RPO around the realistic lag. Operational check: alert when replication lag exceeds the documented RPO and record the lag value at the moment of any failover.