PARALLEL_REDO_DRAIN_WORKER is recorded when the main parallel redo thread for a database (on an AG replica, or during crash recovery on a standalone instance) waits for the other redo threads to finish all outstanding log record redo. Certain logged operations force this drain, checkpoints and log file size changes among them, because they must see a consistent point before proceeding.
It is a synchronisation barrier inside normal parallel redo.
Is It a Problem?
No; it is documented as part of normal operations and not indicative of a performance issue, so it belongs on the benign filter list with the rest of the redo bookkeeping waits. Its totals scale with how often drain-forcing operations occur in the log stream being redone.
Redo actually falling behind looks different: growing redo_queue_size in the replica DMVs and PARALLEL_REDO_FLOW_CONTROL climbing. Those are the signals with consequences (failover time, readable-secondary staleness); this drain wait is not one of them.
Common Causes
- Checkpoint records and file-size-change operations in the redone log forcing worker drains.
- Normal parallel redo on busy AG secondaries hitting periodic sync points.
What To Do
- Filter it out of wait analysis.
- Judge redo health by
redo_queue_sizeandredo_rate, plusPARALLEL_REDO_FLOW_CONTROLwhen the queue grows. - No action attaches to the drain wait itself.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as redo background noise.
PARALLEL_REDO_DRAIN_WORKER 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