A company operates two data centers 10 km apart connected by dedicated low-latency fiber. The business requires that no committed transaction be lost if the primary database server fails, and it accepts slightly slower commits to achieve this. Which replication mode should the DBA configure?

Synchronous replication makes the commit path wait for the standby to acknowledge that it has received and durably recorded the change. Because the primary reports success only after that acknowledgment, any transaction the application saw as committed also exists on the standby, giving a recovery point objective of zero for a primary failure. The cost is added commit latency equal to at least one network round trip, which is why the design suits nearby sites joined by low-latency links, exactly as described. Asynchronous replication commits locally first and sends changes afterward; it is faster, but anything not yet shipped when the primary fails is lost, so it cannot guarantee zero loss. Nightly log shipping moves changes only once a day, so up to a full day of committed work could be missing on the standby. Snapshot replication copies a point-in-time image of the data on a schedule, so every change since the last snapshot is at risk and the standby is never current. Exam caveat: synchronous replication protects against losing committed data, but it does not protect against logical errors such as an accidental delete, which are replicated just as faithfully. Operational check: confirm the replica reports a synchronous state, then measure commit latency before and after enabling it so the slowdown is documented against the baseline.