SQL Server Always On Gecikmesi: Log Send ve Redo Kuyrukları
Log gönderim ve redo kuyruklarını ayrı teşhis eder; ağ kopması, askıya alınmış veri hareketi ve yavaş secondary nedenlerini ayırır.
Operasyonel Güvenlik ve Risk Uyarısı
Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.
1. Belirti / Symptom
- 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. Etki / 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. Teşhis / Diagnosis
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. Müdahale / Response
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. Doğrulama / Verification
- `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. Geri Alma / Rollback
- `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.**