HADR_LOGPROGRESS_SYNC is recorded when a thread waits for exclusive access to the structure holding the latest log-harden LSN on an Availability Group primary with a synchronous replica. That structure is the release gate for synchronous commits: sessions parked in HADR_SYNC_COMMIT get signalled to continue once the hardened LSN passes their commit LSN, and updating or reading that LSN goes through this lock.
It is a small but load-bearing piece of the synchronous commit machinery.
Is It a Problem?
Small amounts ride along with any synchronous AG. It matters when it becomes prevalent, because contention on the release gate delays the signalling of completed commits, and you will see HADR_SYNC_COMMIT inflate alongside it even though the replica and network are fine. That combination, sync-commit waits up while send/redo queues look healthy, is this wait’s signature.
There is a documented case (fixed in 2016 SP1 CU7) where a non-yielding thread on the same scheduler caused exactly this pattern, so build currency is part of the checklist.
Common Causes
- Very high commit concurrency hammering the LSN structure on the primary.
- Scheduler-level problems (non-yielding threads) starving the structure’s updates on affected builds.
- General CPU saturation slowing everything in the commit signalling path.
What To Do
- Distinguish the source of sync-commit pain: check
log_send_queue_sizeand replica health first; if those are clean butHADR_SYNC_COMMITand this wait rise together, the primary-side gate is the story. - Verify build currency against known fixes for this pattern.
- Check scheduler health (
sys.dm_os_schedulers, non-yielding warnings in the error log) during the episodes.
How To See It
Rank it against everything else with Get-WaitStatistics, and read it strictly in combination with HADR_SYNC_COMMIT and the replica DMVs.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply