Mistake #1: treating synchronized data as proof that disaster recovery works. Failover can still expose poor secondary performance, missing permissions, encryption mismatches, or other operational failures. Find those problems during a controlled test—not at 2 a.m. during a real incident. section 13.3
The secondary replica that could not serve users
An availability group fails over from a primary replica to a secondary replica in another data center. The transition succeeds, but users immediately face unacceptable performance because of network latency or insufficient secondary capacity. Failover can also fail when the SYSTEM account lacks VIEW SERVER STATE, CONNECT SQL, or ALTER ANY AVAILABILITY GROUP, or when forced encryption prevents health monitoring from connecting. section 13.3
Use a recurring DR-test checklist:
- Test every application regularly; an annual test is common, preferably through a rolling schedule. section 13.6
- Measure performance after failover and involve users to confirm that the application remains usable. section 13.3 section 13.6
- Check secondary-node capacity, required permissions, encryption configuration, monitoring, and the behavior of the selected HA/DR technology. section 13.3 section 13.5
- Avoid overloading a cluster: capacity-plan for a failed-over workload and rehearse the event before relying on it. section 13.5
Figure 13.6 Active/active cluster using availability groups providing automatic failover in a single site
Use the active/active availability-group cluster diagram to relate automatic failover, shared cluster capacity, and overload risk. section 13.5
