PARALLEL_REDO_WORKER_SYNC is recorded when the main parallel redo thread on an Availability Group replica waits for its redo worker threads to complete their assigned work. It is the general completion-synchronisation wait of the redo pipeline, the main thread pausing at a rendezvous point while workers finish.
It completes the set of parallel redo coordination waits alongside the drain, log cache, transaction list, and turn-order variants.
Is It a Problem?
No; it is documented as part of normal parallel redo operations and not indicative of a performance issue, and it belongs on the benign filter list. Its size tracks how much redo work flows through the pipeline and how often the main thread synchronises, neither of which is a fault condition.
The family’s one genuinely actionable member remains PARALLEL_REDO_TRAN_TURN (ordering stalls from primary-side page splits); everything else, this wait included, is machinery noise.
Common Causes
- Normal parallel redo on AG secondaries, with the main thread synchronising on worker completion.
- Heavy redo periods raising both the work and the synchronisation frequency.
What To Do
- Filter it out of wait analysis.
- Watch redo health where it is actually visible:
redo_queue_size,redo_rate, and the flow-control and tran-turn waits when the queue grows. - No action exists at this wait’s level.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as redo background noise.
PARALLEL_REDO_WORKER_SYNC is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- HADR_SYNC_COMMIT Wait Type, the closest wait worth investigating when this one is high.
- High Availability, the scripts and guides for this part of the stack.
Leave a Reply