HADR_AG_MUTEX is recorded when a thread waits for the critical section guarding an Availability Group’s configuration. AG DDL statements (ALTER AVAILABILITY GROUP, adding or removing databases and replicas) and Windows Server Failover Clustering commands need exclusive read/write access to the AG’s configuration, and only one such operation can hold it at a time.
Two configuration changes arriving together means one of them waits here.
Is It a Problem?
Rarely; it has not been a contention point, because AG configuration changes are inherently infrequent. When it does appear with real duration, the meaning is concrete: an AG management operation is queued behind another one that is taking its time, a failover in progress, a database being added, a replica join, or an automated tool issuing overlapping AG commands.
Chronic presence usually implicates automation issuing AG DDL more often than it should.
Common Causes
- Concurrent AG DDL: two administrative changes to the same AG at once.
- Failover or cluster operations holding the configuration while a management command waits.
- Monitoring or orchestration tooling issuing frequent AG state-change commands.
What To Do
- When an AG command hangs, look for the other one:
sys.dm_exec_requestsshows what else is touching the AG, and the cluster log covers WSFC-initiated operations. - Serialise your own automation; AG management commands to one group should not race each other.
- During incidents, let in-flight failover operations complete before issuing more AG DDL; stacking commands behind the mutex helps nothing.
How To See It
Rank it against everything else with Get-WaitStatistics; occurrences will map to specific AG management activity in your timeline.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply