After a failover, production has run on the disaster recovery server for a week while the original primary was repaired. Management now wants to return operations to the original primary. What must the DBA ensure before failing back?
Select an answer to reveal the explanation.
Short Explanation
Failback is coming home from a long trip: you have to bring your luggage with you. The DR server holds a week of new data, so you sync it back to the primary first, then switch over in a planned window. Point clients home too early and that whole week stays behind at the hotel.
Full Explanation
Failback returns operations from the disaster recovery site to the original primary after it has been restored. During the week on the DR server, every new transaction was written there, so the original primary is out of date. Before moving clients, the DBA re-establishes replication or another synchronization method from the DR server to the original primary, waits until it is fully caught up, then performs a planned switch in a maintenance window, stopping writes, confirming no lag, promoting the original primary and redirecting clients, with the DR server returned to its standby role. Pointing clients back immediately would run production on a database missing a week of changes, and new writes would diverge further, making reconciliation difficult or impossible. Restoring the original primary from a pre-disaster backup produces an even older copy and discards everything written since the incident. Letting both servers accept writes at once creates a split-brain situation with conflicting changes on each side, which most relational systems cannot reconcile automatically. Exam caveat: failback is a planned, controlled event and deserves the same testing and change management as a failover. Operational check: compare row counts or checksums for key tables on both servers before the switch, and confirm replication lag is zero at cutover.