SQL Server Always On AG: Failover, Not Synchronizing ve Kuyruk Gecikmesi
Always On AG rolünün RESOLVING olması, NOT SYNCHRONIZING / SUSPENDED durumları, planlı manuel failover ve veri kaybı riskli zorunlu failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) acil müdahale rehberi.
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
- Availability Group rolü `RESOLVING` durumuna geçti veya replica `DISCONNECTED`.
- Veritabanı durumu `NOT SYNCHRONIZING`, `SYNCHRONIZING / NOT HEALTHY` veya `SUSPENDED`.
- `log_send_queue_size` veya `redo_queue_size` hızla büyüyor (M32 alarmı).
- Primary sunucu yanıt vermiyor; acil failover kararı gerekiyor.
2. Etki / Impact
Yüksek Erişilebilirlik (HA) ve Felaket Kurtarma (DR) koruması kaybolur; senkron modda istemci commit süreleri uzar veya durur; primary çökmesi durumunda RPO ve RTO garantileri bozulur.
3. Teşhis / Diagnosis
-- AG ve Replika Genel Durumu
SELECT
ag.name AS ag_name, ar.replica_server_name, ar.availability_mode_desc,
ars.role_desc, ars.synchronization_health_desc, ars.connected_state_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id;
-- Veritabanı Bazında Kuyruk ve Senkronizasyon Durumu
SELECT
db_name(database_id) AS db_name, synchronization_state_desc,
synchronization_health_desc, is_suspended, suspend_reason_desc,
log_send_queue_size, log_send_rate, redo_queue_size, redo_rate
FROM sys.dm_hadr_database_replica_states;- `SYNCHRONIZED` ve `HEALTHY` -> Planlı failover güvenli, veri kaybı sıfır.
- `NOT SYNCHRONIZING` / `SUSPENDED` -> Önce Müdahale A ile askıya alma nedenini çözün, sonra failover değerlendirin.
- `log_send_queue_size > 1 GB` -> Açık büyük transaction var; planlı failover öncesi kuyruğun boşalmasını bekleyin.
4. Müdahale / Response
### Müdahale A: Not Synchronizing ve Suspended Durumunu Düzeltme
En yaygın nedenler: Transaction log doluluğu, ağ kesintisi veya yetersiz ikincil disk alanı.
-- 1. Askıya alınma nedenini belirleyin
SELECT database_id, synchronization_state_desc, suspend_reason_desc
FROM sys.dm_hadr_database_replica_states
WHERE synchronization_state_desc <> 'SYNCHRONIZED';
-- 2. HADR Endpoint çalışıyor mu kontrol edin
SELECT name, state_desc, port FROM sys.database_mirroring_endpoints;
-- 3. Veri akışını devam ettirin (Replica üzerinde)
ALTER DATABASE [MyDB] SET HADR RESUME;
-- 4. Eğer resume olmazsa seeding'i yeniden başlatın (SQL Server 2016+)
-- Primary üzerinde:
ALTER AVAILABILITY GROUP [AG1] REMOVE DATABASE [MyDB];
ALTER AVAILABILITY GROUP [AG1] ADD DATABASE [MyDB];
-- İkincilde otomatik seeding başlar; manuel gerekiyorsa:
-- RESTORE DATABASE [MyDB] FROM ... WITH NORECOVERY;### Müdahale B: Planlı Manuel Failover (Sıfır Veri Kaybı)
Ön koşul: `availability_mode = SYNCHRONOUS_COMMIT` ve `synchronization_state = SYNCHRONIZED`.
-- Yeni Primary olacak Secondary sunucu üzerinde çalıştırın:
ALTER AVAILABILITY GROUP [AG1] FAILOVER;
-- Doğrulama:
SELECT @@SERVERNAME AS current_node, ars.role_desc
FROM sys.dm_hadr_availability_replica_states ars
JOIN sys.availability_replicas ar ON ars.replica_id = ar.replica_id
WHERE ar.replica_server_name = @@SERVERNAME;### Müdahale C: Zorunlu Failover (Primary Öldü, Veri Kaybı Riski Var)
⚠️ **SADECE DR VE ACİL DURUMDA UYGULAYIN!**
-- Eski Primary tamamen kapalıyken, ayakta olan Secondary üzerinde:
ALTER AVAILABILITY GROUP [AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS;
-- Eski primary daha sonra ayağa kalktığında:
-- 1. Eski primary'yi RESOLVING durumundan çıkarın
ALTER AVAILABILITY GROUP [AG1] SET (ROLE = RESOLVING);
-- 2. LSN ve veri farkını karşılaştırın
-- 3. Eski sunucuyu AG'ye ikincil olarak tekrar dahil edin5. Doğrulama / Verification
- Tüm kullanıcı veritabanlarının `SYNCHRONIZED` veya `SYNCHRONIZING` durumuna geçtiğini doğrulayın.
- AG Listener IP ve DNS çözümlemesini test edin:
SELECT dns_name, ip_address, is_online FROM sys.availability_group_listeners;- Uygulama bağlantı cümlesinde `MultiSubnetFailover=True` parametresinin etkin olduğunu ve yeni primary'ye bağlandığını teyit edin.
6. Geri Alma / Rollback
- Planlı failover sonrası eski role dönmek için eski primary üzerinde tekrar `ALTER AVAILABILITY GROUP [AG1] FAILOVER;` komutunu çalıştırın.
- **Zorunlu failover (FORCE_FAILOVER) geri alınamaz!** Veri kaybı yaşanmışsa LSN çatallanmasını çözmek için ikincil veritabanını tam yedekten baştan kurun.
- **Önleme Checklist:**
- [ ] Windows Server Failover Cluster (WSFC) Quorum Witness (File Share / Cloud) sağlıklı mı?
- [ ] Haftalık `sp_Blitz` veya sağlık sorguları ile AG replika metrikleri denetleniyor mu?
- [ ] `log_send_queue_size > 500MB` için proaktif alarm var mı?
- [ ] Yılda en az 2 kez kontrollü failover tatbikatı yapılıyor mu?
Mühendislik Triadı: Doğrudan Teşhis Scriptleri
Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:
SQL Server Always On Availability Group Sağlık ve Gecikme Durumu
Replika durumlarını, senkronizasyon sağlığını, log gönderim ve redo kuyruklarını gösterir. Failover hazırlığını ve veri kaybı riskini izlemek için kullanılır.