I found a number of troubleshooting tips for this situation here.
I've summarized them below:
"AVAILABILITY_REPLICA" indicates that the logged changes in the availability database at the primary replica that have not arrived and that these changes were applied to the availability database at one of the secondary replicas. Until logged changes arrive and are applied, the changes cannot be truncated from the availability database log at the primary replica.
Troubleshooting
"Log Send Queue" and "Redo Queue" are measurable data points during availability database synchronization. You can monitor these data points in order to determine whether an availability database log cannot be truncated because of the log uses type AVAILABILITY_REPLICA.
- Log Send Queue -
When a transaction is performed at the primary, the logged blocks must be delivered and hardened to the database log file at the secondary. Any delay will prevent truncation of those logged changes in the database at the primary replica. A common reasons for a sustained log send queue is latency in the network or during hardening (write to disk) of the log blocks on the secondary.
- Redo Queue -
As soon as it is hardened to the secondary database log file, a dedicated redo thread applies the log records. If the redo operation cannot keep up with the transaction log that is generated, log growth may occur. If the secondary replica redo operation is behind in applying those changes to a corresponding secondary database, the primary will truncate the transaction log.
Identify the secondary database that is delaying log truncation
If there is more than one secondary, there may be a particular secondary that is responsible for the log truncation issue. To identify the secondary database that is delaying log truncation, log on to the primary replica, query the truncation_lsn column of the sys.dm_hadr_database_replica_states dynamic management view (DMV), and then review the log_send_queue and redo_queue data points to help diagnose the issue.
The AlwaysOn dashboard and the sys.dm_hadr_database_replica_states DMV help monitor the redo progress. The following table lists some key fields:
For example, execute the following query against the primary replica in order to report the log_send_queue and redo_queue values for each secondary availability database.
SELECT ar.replica_server_name
,drs.truncation_lsn
,drs.log_send_queue_size
,drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
WHERE drs.is_local = 0
Corrective measures may include but are not limited to the following:
- Make sure that there is no resource or performance bottleneck of the secondary.
- Make sure that the Redo thread is not blocked in the secondary.
- Make sure that the Redo thread does not fall behind because resource contention created a reporting workload.
