REDO_THREAD_PENDING_WORK is recorded on an Availability Group secondary when a redo thread is waiting to be signalled that more log has arrived to apply. When the secondary is fully caught up, the redo thread has nothing to do and parks here until the primary generates more transactions.
It is one of the most common top waits on AG secondaries, and it means the replica is up to date.
Is It a Problem?
No; if anything it is the good news wait. On an AG whose primary generates little log, expect very high totals here, because the redo thread spends most of its life waiting for work. It is filtered as benign in sensible wait analysis, and its size mostly tracks how quiet the primary is.
The condition worth worrying about on a secondary is the opposite one: redo falling behind, which shows up as a growing redo_queue_size and waits like PARALLEL_REDO_FLOW_CONTROL, while this wait shrinks because the redo threads are never idle.
Common Causes
- A caught-up secondary with a quiet or bursty primary.
- Overnight and weekend troughs in log generation.
- Multiple AG databases, each with mostly-idle redo threads.
What To Do
- Filter it out of wait analysis on secondaries.
- Judge redo health by
redo_queue_sizeandredo_rateinsys.dm_hadr_database_replica_states, never by this wait. - If someone cites its huge total as evidence of an AG problem, point them at the redo queue instead; big idle time here is the absence of a problem.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as noise on AG secondaries.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply