SQL Server Always On Lag: Log Send and Redo Queues
Diagnoses log-send and redo queues separately and distinguishes network failures, suspended data movement and slow secondaries.
Operational Safety & Risk Notice
This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.
1. Symptom & Signals
- M32'de `log_send_queue_size` veya `redo_queue_size` (KB) sürekli büyüyor; `NOT SYNCHRONIZING`, `NOT SYNCHRONIZED`, `SUSPENDED` veya bağlantı hatası görülüyor.
- Secondary okuma verisi eski, failover hazırlığı bozulmuş; senkron modda commit gecikebilir.
2. Business & Technical Impact
- **Asenkron modda:** Gönderilmemiş log birikimi failover sırasında veri kaybı (RPO) riski yaratır.
- **Senkron modda:** Bağlı/senkron secondary ack bekleme uygulama gecikmesi yaratabilir; senkron değilse otomatik failover beklentisi karşılanmaz. Redo kuyruğu okunabilir secondary'de eski veri ve uzun kurtarma süresi doğurabilir.
3. Diagnosis & Root-Cause Analysis
SELECT ag.name AS ag_name, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc,
DB_NAME(drs.database_id) AS db_name,
drs.is_local,
drs.synchronization_state_desc, drs.synchronization_health_desc,
drs.is_suspended, drs.suspend_reason_desc,
drs.log_send_queue_size AS send_kb, drs.log_send_rate AS send_kb_per_sec,
drs.redo_queue_size AS redo_kb, drs.redo_rate AS redo_kb_per_sec,
drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars ON ars.replica_id = ar.replica_id
ORDER BY ag.name, ar.replica_server_name, db_name;`DB_NAME(drs.database_id)` yerel instance bağlamında gösterilir; remote satırların database_id eşleşmesini ve görünürlüğünü karşı tarafta doğrulayın. Sürüm/yetki farklarında alanlar değişebilir.
4. Remediation & Action Plan
ALTER DATABASE [OrnekDb] SET HADR RESUME;Önce durumun gerçekten `SUSPENDED` olduğunu ve uygulanacak replika/DB'yi doğrulayın.
4. **Kalıcı çözüm:** Send/redo kuyruklarını ve senkronizasyon sağlığını ayrı alarmlayın; secondary depolamasını primary yazma hızına uygun tutun.
5. Verification & Health Checks
- `is_suspended = 0`, `connected_state_desc = CONNECTED`; uygun modda durum `SYNCHRONIZED`/`SYNCHRONIZING`.
- Kuyrukların eğilimi düşüyor, M32 normale dönüyor; secondary okuma gecikmesi ve (varsa) senkron commit süreleri iyileşti.
6. Rollback & Contingency Plan
- `SET HADR RESUME` sonrasında veri hareketini tekrar askıya almak (`SET HADR SUSPEND`) gecikmeyi artırır; yalnızca güvenlik/kurtarma nedeni varsa ayrı karar verin.
- Altyapı/yönlendirme değişikliklerini önceki ayarlara döndürün; **olası veri kaybı yaşanmış failover geri alınabilir bir ayar değildir.**