PARALLEL_REDO_LOG_CACHE is recorded infrequently on an Availability Group replica after the main redo thread has hit a bottleneck, that is, following episodes of PARALLEL_REDO_FLOW_CONTROL. It relates to the log cache the redo pipeline reads from, and it appears as an occasional after-effect of the pipeline having been throttled.
It is one of the minor bookkeeping waits in the parallel redo family.
Is It a Problem?
No; it is documented as part of normal parallel redo and not indicative of a performance issue. Its main informational value is circumstantial: seeing it at all suggests the redo pipeline has recently been in flow control, so if you were unaware of redo pressure, it is a nudge to check the primary signals.
Those primary signals remain the same as always for redo: queue size, redo rate, and flow-control wait time.
Common Causes
- Aftermath of
PARALLEL_REDO_FLOW_CONTROLepisodes on busy AG secondaries. - Heavy log bursts from the primary (index maintenance, bulk loads) working through the redo pipeline.
What To Do
- Filter it out of routine analysis with the other redo bookkeeping waits.
- If it prompts curiosity, check
redo_queue_sizetrends andPARALLEL_REDO_FLOW_CONTROLon the same database; act on those if they warrant it. - Nothing attaches to this wait directly.
How To See It
Rank waits with Get-WaitStatistics; expect only occasional traces, clustered after redo-pressure episodes.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply