### Basic concepts - HADR_SYNC_COMMIT wait: Primary has generated log records for a transaction. Before committing, it must wait for the secondary to harden (write to log) those same LSNs. - send_log_queue_size (not yet shipped): amount of log (in bytes) that has been generated on the primary but not yet sent to the secondary. - Redo Queue Size (shipped but not applied): amount of log (in bytes or LSNs) that has already been received, hardened, but has not yet been redo-applied. ### Issue: HADR_SYNC_COMMIT waits inside a synchronous replication [Lesson Learned #337: HADR_SYNC_COMMIT wait type delay in Azure SQL Database](https://techcommunity.microsoft.com/blog/azuredbsupport/lesson-learned-337-hadr-sync-commit-wait-type-delay-in-azure-sql-database/3778228) > During their troubleshooting process they found that they got many request with the wait type is `HADR_SYNC_COMMIT`. This wait type indicates the time that the primary replica spends waiting for the secondary replica to harden the log records (LSN). This wait type only occurs on the primary replica and only inside a synchronous replication that we could have for every internal replica when we created a business critical or premium service tier database. #### Possible causes - Network issue between replicas. - Slow secondary replica: check redo_queue_size & redo_rate https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-database-replica-states-azure-sql-database?view=azuresqldb-current - Heavy primary replica: throttling at log generation; check log_send_queue_size and log_send_rate. There is no straitforward articles for SQLDB thus refer the SQL server article: [Troubleshooting intermittent connection time-outs between availability group replicas ](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/availability-groups/troubleshooting-intermittent-connection-timeouts-availability-groups) Sometimes we see high `HADR_SYNC_COMMIT` because connection timeouts between local replicas; SQL Server might be busy for any of several reasons, and doesn't service the mirroring endpoint connection within the availability group SESSION_TIMEOUT period. This causes the connection time-out. Some of these reasons are: - SQL Server experiences 100 percent CPU utilization - SQL Server experiences non-yielding scheduler events. - SQL Server experiences worker thread exhaustion, out-of-memory problems, or application problems that affect its ability to service the mirroring endpoint connection.