What’s the issue?
Each replica in an Always On Availability Group has a synchronization state that reflects how current it is relative to the primary. The states include SYNCHRONIZED (the replica is fully caught up and committed transactions have been hardened on it), SYNCHRONIZING (the replica is processing log records but is not guaranteed to be fully current), NOT SYNCHRONIZING (the replica is not receiving updates), and REVERTING or INITIALIZING during specific transient operations.For a synchronous-commit replica to be eligible for automatic failover or for a manual failover without data loss, it must be in the SYNCHRONIZED state. Replicas in any other state are not considered ready for failover, even if they appear to be receiving updates and processing them normally.
This finding identifies AGs with failover mode AUTOMATIC have one or more replicas are in a state other than SYNCHRONIZED, indicating that the AG cannot fail over cleanly to those replicas at the current moment.
Why is this a problem?
A replica that is not synchronized cannot serve as a clean failover target. If the primary fails while a synchronous-commit replica is in SYNCHRONIZING state, the cluster may not initiate automatic failover to that replica, and a manual failover would either fail or proceed only with the data loss option, accepting whatever transactions had not yet been committed on the secondary.For asynchronous-commit replicas, the synchronization state is expected to lag behind the primary, but the replica should still be SYNCHRONIZING rather than stuck in another state. A replica that is NOT SYNCHRONIZING is genuinely disconnected from the primary’s data flow and is becoming further out of date with every transaction that commits on the primary.
The condition also indicates that the high availability promise of the AG is not currently being met. The whole point of having multiple replicas is to provide failover targets, and a replica that is not in a failover-ready state is not contributing to availability. If the primary fails during this window, the recovery experience is significantly worse than the AG’s design implied.
What should you do about this?
Investigate the cause of the unsynchronized state. Common causes include data movement having been suspended (covered separately), connectivity problems between replicas, the AG endpoint being offline (covered separately), the replica being unable to keep up due to resource pressure on the secondary, or a long-running transaction on the primary preventing log records from being delivered cleanly.For replicas in NOT SYNCHRONIZING state due to suspended data movement, resume the movement with ALTER DATABASE [DatabaseName] SET HADR RESUME; after addressing whatever caused the suspension. For replicas falling behind due to throughput issues, investigate the secondary’s resource utilization (CPU, I/O on the log volume, network bandwidth between replicas) and address any bottlenecks identified.
If the secondary needs to catch up after a long period of disruption, expect the catch-up to take time proportional to how much log accumulated on the primary while the secondary was behind. Monitor the log send queue and redo queue sizes to track progress, and confirm that the synchronization state returns to SYNCHRONIZED (for synchronous replicas) or stable SYNCHRONIZING (for asynchronous replicas) when catch-up completes.