What’s the issue?
Always On Availability Groups maintain synchronization between replicas by streaming transaction log records from the primary to each secondary, where the secondary applies the records to its copy of the database through a process called redo. The time between when a transaction commits on the primary and when it is applied on the secondary represents the lag, with separate measurements available for log send latency (primary to secondary network) and redo latency (the secondary catching up its data files).This finding identifies AGs where one or more replicas are exhibiting estimated secondary lag exceeding 5 seconds. The condition can apply to either synchronous-commit or asynchronous-commit replicas, with different implications depending on the configuration.
Why is this a problem?
For asynchronous-commit replicas, lag is expected and is part of the design tradeoff. The asynchronous mode trades up-to-date secondaries for reduced impact on the primary, with the understanding that some lag is normal. However, sustained lag well beyond what the team has documented as acceptable may indicate problems that should be investigated, since significant lag at the moment of a primary failure translates directly into data loss equal to the lag duration.For synchronous-commit replicas, lag indicates that the secondary is having trouble keeping up with the primary, which can begin to affect performance on the primary itself. Synchronous mode requires the primary to wait for the secondary to harden each transaction’s log records, so a slow secondary directly slows down primary commit times. Sustained lag in synchronous mode is also one of the conditions that can drive the AG out of SYNCHRONIZED state, eliminating the secondary as a clean failover target.
Lag also affects readable secondary scenarios. If applications use secondary replicas for read-only queries, the data they see may be substantially behind the primary, which can produce stale reads, inconsistent reporting, and confusion when results from the primary and the secondary disagree. Reporting that depends on near-current data is particularly sensitive to extended lag.
The condition can also point to broader infrastructure issues. Network bandwidth or latency problems between replicas, slow storage on the secondary, resource pressure (CPU, memory) that is starving the redo process, or schema patterns that produce inefficient redo (heavy DDL, large transactions, parallel index builds) can all produce sustained lag. Addressing the root cause often improves performance for the whole AG, not just the lagging replica.
What should you do about this?
Identify the lag pattern by querying sys.dm_hadr_database_replica_states and determining whether it is concentrated in log send (network or delivery between replicas) or in redo (secondary applying the log records). The two have different causes and remediations.For log send lag, investigate network latency and bandwidth between the primary and the affected replica, and confirm the replica is appropriately placed for the AG’s design. For redo lag, investigate the secondary’s storage I/O and overall resource utilization, since redo is write-heavy and most often constrained by data file storage performance.
Review the primary’s workload for activities that generate heavy redo such as large index rebuilds, schema changes on large tables, and large transactions, and schedule these during low-activity windows where possible. For asynchronous replicas with sustained but acceptable lag, document the expected range and confirm monitoring thresholds reflect realistic expectations.