HADR_LOGCAPTURE_SYNC Wait Type Explained

This wait type originates from the Always On log capture and transport subsystem that coordinates between the primary replica's log capture thread and secondary replicas' redo threads. When a partner state change occurs (such as a replica going offline, coming online, or changing synchronization modes), the log capture object requires exclusive access to update its internal state and scan structures.

The synchronization happens at the database engine level through the HADR manager component, which maintains connection metadata and partner state information. During state transitions, the log capture thread must serialize access to shared data structures that track log block sequences, LSN positions, and redo queue status across all replicas in the availability group.

SQL Server 2016 introduced optimizations to reduce lock contention during log capture synchronization, particularly for workloads with many small transactions. SQL Server 2019 further enhanced the coordination mechanism by implementing lockless algorithms for certain log capture scenarios, reducing HADR_LOGCAPTURE_SYNC waits during normal operation.

In SQL Server 2022, the Always On engine uses improved partner state caching that reduces the frequency of synchronization events. However, the wait type remains necessary during actual partner changes, network reconnections after outages, or when switching between synchronous and asynchronous commit modes.

The wait duration directly correlates with network latency between replicas and the complexity of the state change being processed. Extended waits often indicate network connectivity issues, secondary replica performance problems, or resource contention on either the primary or secondary instances.

-- Check current Always On wait statistics and identify HADR_LOGCAPTURE_SYNC patterns
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,
    CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER() AS DECIMAL(5,2)) AS pct_total_waits
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'HADR%'
    AND waiting_tasks_count > 0
ORDER BY wait_time_ms DESC;

-- Examine current availability group replica states and synchronization health
SELECT 
    ag.name AS availability_group,
    ar.replica_server_name,
    ar.availability_mode_desc,
    ar.failover_mode_desc,
    ars.role_desc,
    ars.operational_state_desc,
    ars.connected_state_desc,
    ars.synchronization_health_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;

-- Monitor log send queue and redo queue sizes that affect log capture sync
SELECT 
    db.name AS database_name,
    drs.synchronization_state_desc,
    drs.log_send_queue_size,
    drs.log_send_rate,
    drs.redo_queue_size,
    drs.redo_rate,
    drs.last_sent_lsn,
    drs.last_received_lsn,
    drs.last_hardened_lsn,
    drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states drs
    INNER JOIN sys.databases db ON drs.database_id = db.database_id
WHERE drs.is_local = 0
ORDER BY drs.log_send_queue_size DESC;

-- Check for blocking and resource waits affecting HADR operations
SELECT 
    s.session_id,
    s.wait_type,
    s.wait_time,
    s.wait_resource,
    s.blocking_session_id,
    s.command,
    s.status,
    t.text AS current_sql
FROM sys.dm_exec_requests s
    OUTER APPLY sys.dm_exec_sql_text(s.sql_handle) t
WHERE s.wait_type LIKE 'HADR%'
    OR s.command LIKE '%HADR%'
ORDER BY s.wait_time DESC;

-- Review Always On extended events for log capture synchronization issues
SELECT 
    xe.object_name,
    CAST(xe.event_data AS XML) AS event_data_xml,
    CAST(xe.event_data AS XML).value('(event/@timestamp)[1]', 'DATETIME2') AS event_timestamp,
    CAST(xe.event_data AS XML).value('(event/data[@name="database_name"]/value)[1]', 'NVARCHAR(128)') AS database_name,
    CAST(xe.event_data AS XML).value('(event/data[@name="availability_group_name"]/value)[1]', 'NVARCHAR(128)') AS ag_name,
    CAST(xe.event_data AS XML).value('(event/data[@name="current_state"]/text)[1]', 'NVARCHAR(50)') AS current_state
FROM sys.fn_xe_file_target_read_file('AlwaysOn*.xel', NULL, NULL, NULL) xe
WHERE xe.object_name IN ('availability_group_lease_expired', 'availability_replica_state_change', 'hadr_db_partner_set_sync_state')
ORDER BY CAST(xe.event_data AS XML).value('(event/@timestamp)[1]', 'DATETIME2') DESC;

Reset wait statistics to establish baseline for monitoring:

-- Clear wait stats to get fresh measurements after addressing HADR issues
-- WARNING: This clears all wait statistics, affecting monitoring baselines
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR);

This resets all wait statistics counters, allowing accurate measurement of HADR_LOGCAPTURE_SYNC waits after implementing fixes. Only run during maintenance windows as it affects all monitoring baselines.

Force partner state refresh for problematic availability groups:

-- Force refresh of partner states and connections for availability group
-- Replace 'YourAGName' with actual availability group name
DECLARE @ag_name NVARCHAR(128) = 'YourAGName';

ALTER AVAILABILITY GROUP [YourAGName] 
MODIFY REPLICA ON 'SecondaryServerName' 
WITH (SESSION_TIMEOUT = 10); -- Reset to default timeout

-- Then immediately set back to desired timeout
ALTER AVAILABILITY GROUP [YourAGName] 
MODIFY REPLICA ON 'SecondaryServerName' 
WITH (SESSION_TIMEOUT = 30); -- Set to your standard timeout

This forces a state synchronization between replicas by temporarily changing configuration. Test in development first and ensure secondary replica name matches your environment exactly.

Optimize log send buffer sizes for high-throughput scenarios:

-- Increase log send buffer size to reduce synchronization frequency
-- This is an instance-level configuration change
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

-- Set max server memory if not already configured to prevent memory pressure
EXEC sp_configure 'max server memory (MB)', 16384; -- Adjust based on server specs
RECONFIGURE;

EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;

Memory pressure can cause excessive log capture synchronization waits. Ensure adequate memory allocation prevents resource contention during HADR operations. Requires SQL Server service restart for some configurations.

Enable specific Always On extended events for ongoing monitoring:

-- Create extended event session to monitor HADR synchronization issues
IF EXISTS (SELECT * FROM sys.server_event_sessions WHERE name = 'HADR_LogCapture_Monitoring')
    DROP EVENT SESSION HADR_LogCapture_Monitoring ON SERVER;

CREATE EVENT SESSION HADR_LogCapture_Monitoring ON SERVER
ADD EVENT sqlserver.hadr_db_partner_set_sync_state,
ADD EVENT sqlserver.availability_replica_state_change,
ADD EVENT sqlserver.log_send_manager_capture_log_block
ADD TARGET package0.event_file(SET filename='HADR_LogCapture_Monitoring.xel', max_file_size=50, max_rollover_files=5);

ALTER EVENT SESSION HADR_LogCapture_Monitoring ON SERVER STATE = START;

Creates targeted monitoring for log capture synchronization events. Files are automatically rotated and limited to 250MB total. Review captured events regularly during troubleshooting periods.

Configure Always On availability groups with appropriate session timeout values (30-40 seconds for WAN connections, 10-15 seconds for LAN) to prevent unnecessary state change events that trigger synchronization waits. Shorter timeouts cause frequent false-positive partner failures, while longer timeouts delay legitimate failover detection.

Implement network redundancy between availability group replicas using multiple network paths or NIC teaming to minimize connection interruptions that force partner state recalculation. Each network disconnection triggers log capture synchronization as replicas reconnect and verify their state consistency.

Monitor secondary replica performance proactively using log send queue and redo queue metrics. Secondary replicas struggling with redo operations cause primary replicas to buffer more transaction log data, increasing the complexity of log capture synchronization operations and extending HADR_LOGCAPTURE_SYNC wait times.

Size Always On databases appropriately for the network bandwidth between replicas. Large transaction log records or burst transaction activity can overwhelm log transport mechanisms, forcing frequent synchronization events. Consider implementing transaction log file management policies that maintain optimal VLF counts (30-50 VLFs per database) to improve log capture efficiency.

Set up automated monitoring for availability group dashboard metrics including synchronization lag, connection status, and partner health. Most HADR_LOGCAPTURE_SYNC issues correlate with degraded replica connectivity or performance problems that appear in these standard metrics before wait times become excessive.