Plan and configure high availability and disaster recovery →hardMultiple Choice

Troubleshoot Always On AG: Disconnected Replica

Exhibit

Availability group configuration:
AG1 (Synchronous commit)
- Primary replica: SQL1 (automatic failover)
- Secondary replica: SQL2 (automatic failover, readable secondary)
- Secondary replica: SQL3 (synchronous commit, manual failover, readable secondary)

Listener: listener1, port 1433

Error log on SQL1:
2025-03-15 15:00:00.00 spid31s     The availability group 'AG1' is being restarted due to a failure. Error: 35201. A connection timeout has occurred.
2025-03-15 15:00:05.00 spid31s     The local availability replica of availability group 'AG1' has transitioned from resolving role to primary role.
2025-03-15 15:00:10.00 spid31s     The availability group 'AG1' is online.

Query on SQL1:
SELECT replica_server_name, role_desc, synchronization_health_desc, connected_state_desc FROM sys.dm_hadr_availability_replica_states
WHERE group_id = '...'

Results:
SQL1 | PRIMARY | HEALTHY | CONNECTED
SQL2 | SECONDARY | NOT_HEALTHY | DISCONNECTED
SQL3 | SECONDARY | HEALTHY | CONNECTED

Refer to the exhibit. After a brief outage, the availability group recovered. However, SQL2 shows NOT_HEALTHY and DISCONNECTED. What is the most likely cause?

⚠ Common exam trap

The trap is that candidates might focus on quorum or listener issues, but the specific combination of NOT_HEALTHY and DISCONNECTED on one secondary points directly to a network connectivity problem.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The network connection between SQL1 and SQL2 is still down after the outage.

The most likely cause is that the network connection between SQL1 and SQL2 is still down after the outage. In an Always On availability group, a secondary replica showing NOT_HEALTHY and DISCONNECTED typically indicates a connectivity issue between the primary and secondary. Since the outage occurred, it's plausible that network connectivity was not fully restored.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The automatic failover policy requires a quorum that is not met.
Why it's wrong here
Quorum governs whether the availability group itself can fail over or come online, not an individual secondary's synchronisation health. Quorum is the right cause when the whole availability group is offline or automatic failover refuses to trigger.
✗
The listener is not configured correctly for SQL2.
Why it's wrong here
A misconfigured listener affects client redirection to the availability group, not the replica's own synchronisation state; SQL2 would still report HEALTHY internally. Listener configuration is the correct answer when clients cannot connect despite all replicas showing healthy.
✗
The secondary replica SQL2 has an incompatible database version.
Why it's wrong here
An incompatible database version would prevent the replica from joining the availability group at all, not leave it briefly connected then NOT_HEALTHY and DISCONNECTED after an outage. Version mismatch is the right diagnosis when a replica never synchronises from initial configuration.
✓
The network connection between SQL1 and SQL2 is still down after the outage.
Why this is correct
A persistent network partition prevents SQL2 from exchanging heartbeat messages with the primary replica, so the availability group reports DISCONNECTED and NOT_HEALTHY. Without connectivity, the secondary cannot synchronise or confirm its state, directly matching the stem's post-outage symptom of a replica that recovered but remains unreachable.

Go deeper

Troubleshoot Always On AG: Disconnected Replica

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question