HADR_PARTNER_SYNC Wait Type Explained

This wait type surfaces within SQL Server's Always On availability group infrastructure when the primary replica needs to synchronize partner metadata with secondary replicas. The wait occurs in the availability group state machine when threads are blocked waiting for exclusive access to update the internal partner list structure.

The partner list is a critical metadata structure that tracks all replicas participating in an availability group, including their endpoints, roles, and synchronization states. When configuration changes occur (adding/removing replicas, changing synchronization modes, or during automatic failover scenarios), SQL Server must acquire exclusive locks on this structure to ensure consistency across all replicas.

The wait manifests in the SQLOS scheduler when worker threads executing availability group management operations are suspended while waiting for the partner list lock. This coordination happens through the availability group's internal synchronization primitives, which use Windows synchronization objects underneath.

In SQL Server 2016 and later versions, Microsoft improved the efficiency of partner list updates by implementing more granular locking mechanisms, reducing the frequency and duration of these waits. SQL Server 2019 introduced additional optimizations for scenarios with multiple availability groups on the same instance, further minimizing contention on shared metadata structures.

The wait becomes problematic when it persists during steady-state operations, indicating potential issues with network connectivity between replicas, slow secondary replicas preventing metadata synchronization, or excessive configuration changes happening simultaneously.

-- Check current HADR_PARTNER_SYNC wait statistics
SELECT 
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms,
    signal_wait_time_ms,
    wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'HADR_PARTNER_SYNC'
    AND waiting_tasks_count > 0;

-- Identify active HADR_PARTNER_SYNC waits and associated sessions
SELECT 
    s.session_id,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.wait_resource,
    t.text AS current_statement,
    s.program_name,
    s.host_name
FROM sys.dm_exec_requests r
INNER JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.wait_type = 'HADR_PARTNER_SYNC'
ORDER BY r.wait_time DESC;

-- Check availability group replica states and synchronization health
SELECT 
    ag.name AS availability_group_name,
    ar.replica_server_name,
    ars.role_desc,
    ars.synchronization_state_desc,
    ars.synchronization_health_desc,
    ars.connected_state_desc,
    ars.last_connect_error_number,
    ars.last_connect_error_description
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id
ORDER BY ag.name, ar.replica_server_name;

-- Monitor partner sync operations in the error log
EXEC xp_readerrorlog 0, 1, N'partner', N'sync', NULL, NULL, N'DESC';

-- Check for recent availability group configuration changes
SELECT 
    ag.name AS availability_group_name,
    ar.replica_server_name,
    ar.availability_mode_desc,
    ar.failover_mode_desc,
    ar.create_date,
    ar.modify_date
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
WHERE ar.modify_date >= DATEADD(hour, -24, GETDATE())
ORDER BY ar.modify_date DESC;

Restart availability group to clear stuck partner synchronization

-- Use with extreme caution - will cause brief unavailability
-- Test in development environment first
USE [master]
GO

DECLARE @AGName NVARCHAR(128) = 'YourAvailabilityGroupName'
DECLARE @SQL NVARCHAR(MAX)

-- Stop the availability group
SET @SQL = 'ALTER AVAILABILITY GROUP [' + @AGName + '] OFFLINE'
EXEC sp_executesql @SQL

WAITFOR DELAY '00:00:05' -- Allow time for cleanup

-- Bring the availability group back online
SET @SQL = 'ALTER AVAILABILITY GROUP [' + @AGName + '] ONLINE'
EXEC sp_executesql @SQL

PRINT 'Availability group restart completed'

This forces a clean restart of the availability group state machine, clearing any stuck partner synchronization operations. Only use during maintenance windows as it causes temporary unavailability.

Force partner list refresh by toggling replica session timeout

-- Run on the primary replica to force a partner metadata refresh
-- Safe to run during production hours
-- Temporarily change session timeout to trigger state refresh
ALTER AVAILABILITY GROUP [YourAvailabilityGroupName]
MODIFY REPLICA ON N'SecondaryServerName'
WITH (SESSION_TIMEOUT = 15);

WAITFOR DELAY '00:00:05';

-- Reset to your standard timeout value
ALTER AVAILABILITY GROUP [YourAvailabilityGroupName]
MODIFY REPLICA ON N'SecondaryServerName'
WITH (SESSION_TIMEOUT = 10);

This forces a partner metadata refresh by toggling the session timeout. Verify replica states afterward using sys.dm_hadr_availability_replica_states.

Clear wait statistics to get fresh baseline

-- Clear historical wait stats to focus on current issues
-- Safe to run in production
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

PRINT 'Wait statistics cleared. Monitor for 15-30 minutes for fresh data.'

Resets wait statistics counters to establish a new baseline for monitoring partner sync waits.

Configure availability group endpoints with adequate timeout values to prevent premature partner sync failures. Set the endpoint connection timeout to at least 60 seconds in environments with network latency over 100ms.

Implement monitoring for availability group replica states using sys.dm_hadr_availability_replica_states to detect synchronization issues before they manifest as persistent HADR_PARTNER_SYNC waits. Alert on any replica showing "NOT_HEALTHY" synchronization_health_desc for more than 5 minutes.

Avoid making multiple simultaneous configuration changes to availability groups. Batch replica additions or modifications during maintenance windows to prevent partner list lock contention.

Size network bandwidth appropriately for Always On traffic. Partner synchronization competes with data synchronization for network resources. Monitor network utilization during peak times and ensure at least 20% headroom.

Enable Always On health events in the Windows event log and SQL Server error log to capture detailed information about partner synchronization failures. Use trace flag 1480 in SQL Server 2019+ to get enhanced logging for availability group operations.

Configure automatic page repair to minimize scenarios where corrupted pages on secondary replicas cause synchronization delays that manifest as partner sync waits.