What is exactly the difference between Log Send Queue Size and Redo Queue size on AOAG?

Question

we noticed one of ours servers died some days ago...by enabling it again, I learned (late) that we have more options when looking at the aoag dashboard. I see we would like to see "log send queue size" and "redo queue size".

but I failed to understand the difference on them. By the docs:

The Availability Group Log Send Queue Size (KB) alert indicates the amount of log records in KB needed to ship to the secondary replica to complete synchronization. Alert includes affected databases.

The Availability Group Redo Queue Size (KB) alert indicates the amount of log records from log files in KB that need redoing in the secondary replica to complete synchronization. Alert includes affected databases. For more information on configuring alerts and setting thresholds, see Configure alerts.

what is exactly the difference on them?one is a total of logs, and the other is the size of each log being replicated?

I'm also checking select * from sys.dm_hadr_database_replica_states. so much cool info there.

Answer 1

for redo queue size : High network latency/low network throughput is one of the reasons for the accumulation of REDO queues.The secondary replica may need to harden and redo more logs in a short time after network problems and recovery. And you need to keep an eye on both, Send and Redo queues. https://sqlperformance.com/2015/08/monitoring/availability-group-replica-sync

Only the secondary replica uses the synchronous commit mode, the primary database transaction commit will be affected by the secondary database and wait (HADR_SYNC_COMMIT). Because in the synchronous commit mode, before the primary database commits the transaction, the primary replica has to wait for the synchronous commit secondary replica to confirm that it has hardened the log to disk.

For log queue size : In case of synchronous replicas, large Send queue implies potential blocking. In the synchronous mode, the commit towards the application is delayed until an acknowledge from the synchronous secondary replicas return and the acknowledge is sent when the content sent to the replica is persisted in the transaction log of secondary replica.

With asynchronous replicas, large Send queue dictates potential data loss – data from the queue has not been sent to secondaries. In case of synchronous replicas, large Send queue implies potential blocking. In the synchronous mode, the commit towards the application is delayed until an acknowledge from the synchronous secondary replicas return and the acknowledge is sent when the content sent to the replica is persisted in the transaction log of secondary replica.

https://aboutsqlserver.com/2019/06/09/hadr-sync-commit/ You can say that because primary will not wait for the commit on secondary and if primary goes down and these logs are not sent to secondary and you being up secondary this information would not be there and that would be a data loss to you. That is one of the prime disadvantage of Async mode