PARALLEL_REDO_FLOW_CONTROL Wait Type in SQL Server

PARALLEL_REDO_FLOW_CONTROL is recorded on an Availability Group secondary when the main redo thread has dispatched as much log as it is allowed to the parallel redo worker threads and must wait for one of them to finish before dispatching more. The same wait can also appear during crash recovery of a standalone database, which uses the same parallel redo machinery.

It is the redo pipeline’s internal throttle: the dispatcher pausing because the workers’ plates are full.

Is It a Problem?

Sometimes, and it is version-sensitive. On builds before SQL Server 2016 SP1 CU2 this wait was the signature of a serious parallel redo bottleneck on AG secondaries. On modern builds, moderate amounts just mean redo is busy; sustained high values mean the workers cannot chew through log as fast as it arrives, and your redo_queue_size will confirm it.

A growing redo queue matters even if users on the primary feel nothing: it delays failover (outstanding redo must complete first) and makes readable-secondary queries see stale data.

Common Causes

• Log arriving faster than the parallel redo workers can apply it, typically during index rebuilds or bulk loads on the primary.
• Redo workers competing with a heavy read workload on a readable secondary.
• Known inefficiencies in parallel redo on older builds (pre-2016 SP1 CU2 especially).
• Slow data-file storage on the secondary, since redo ultimately writes pages.

What To Do

1. Measure the backlog: redo_queue_size and redo_rate in sys.dm_hadr_database_replica_states, per database.
2. Patch. If you are on an affected older build, current CUs substantially improved parallel redo.
3. If redo still cannot keep up, test serial redo with trace flag 3459; for some workloads serial redo is actually faster than parallel coordination overhead. Test on your workload before committing.
4. Reduce the incoming burst (tune index maintenance on the primary) or strengthen the secondary’s storage and CPU.

How To See It

Rank it against everything else with Get-WaitStatistics on the secondary, and judge it by the redo queue trend, not the raw wait time.

---

Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.