Son zamanlarda SQL Server Always On Availability Groups kullanan bir müşterimizde oldukça dikkat çekici bir vaka yaşadık. İlk bakışta her şey normal görünüyordu. Monitoring ekranları yeşildi, SQL Server servisleri çalışıyordu, uygulama tarafında büyük bir hata görünmüyordu ve primary replica üzerinde işlemler devam ediyordu.
Ancak arka planda ciddi bir risk sessizce büyüyordu transaction log dosyaları hızla doluyor, secondary replica ile primary replica arasındaki veri farkı artıyor ve sistem, görünürde sağlıklı olmasına rağmen veri kaybı ve servis kesintisi riskiyle karşı karşıya kalıyordu.
Bu yazıda, SQL Server Always On Availability Groups ortamlarında kullanılan HADR SUSPEND komutunun neden dikkatli yönetilmesi gerektiğini, yanlış veya kontrolsüz kullanıldığında ne gibi riskler doğurabileceğini ve bu durumdan korunmak için hangi önlemlerin alınması gerektiğini paylaşacağım.
Always On AG’de Senkron Mod Bize Ne Sağlar?
SQL Server Always On Availability Groups mimarisinde senkron çalışan bir replica yapısında temel beklenti, primary replica üzerinde oluşan değişikliklerin secondary replica tarafına da güvenli şekilde aktarılmasıdır. Synchronous-commit mode kullanıldığında SQL Server, transaction commit sürecinde secondary replica tarafındaki log harden sürecini de dikkate alır. Bu yapı, doğru tasarlanmış ve sağlıklı çalışan bir ortamda veri kaybı riskini minimuma indirmek için tercih edilir. Microsoft dokümantasyonunda da availability mode’un replica seviyesinde belirlendiği ve synchronous-commit mode’un bu davranışı sağlamak için kullanıldığı belirtilir.
Fakat burada çok kritik bir nokta vardır: Senkron modda çalışıyor olmak, her durumda otomatik olarak “risk yok” anlamına gelmez. Veri hareketi askıya alınmışsa, secondary replica tarafına aktarım duruyorsa veya monitoring sistemi bu detayı yeterince takip etmiyorsa, dashboard üzerinde yeşil gördüğünüz bir ortam aslında ciddi bir problem yaşıyor olabilir.
HADR SUSPEND Nedir?
HADR SUSPEND, Always On Availability Groups ortamında bir availability database için data movement işlemini askıya almak amacıyla kullanılan bir komuttur.
Örnek kullanım:
ALTER DATABASE [DatabaseName] SET HADR SUSPEND;Bu komut çalıştırıldığında ilgili availability database için primary ve secondary arasındaki veri hareketi durur. Microsoft dokümantasyonunda, primary database üzerinde suspension yapıldığında ilgili secondary database’ler için data movement’ın duracağı, bu süre boyunca o database için redundancy ve failover yeteneklerinin devre dışı kalacağı açıkça belirtilir.
Data movement’ı tekrar başlatmak için ise aşağıdaki komut kullanılır:
ALTER DATABASE [DatabaseName] SET HADR RESUME;İlk bakışta bu komut maintenance işlemleri için pratik görünebilir. Ancak özellikle yoğun transaction üreten sistemlerde, bu komutun kontrolsüz kullanımı ciddi sonuçlar doğurabilir.
Gerçek Hayata Yakın Bir Senaryo
Diyelim ki yoğun çalışan bir finansal sisteminiz var. Sistem SQL Server Always On AG yapısı üzerinde çalışıyor. Primary replica aktif olarak kullanıcı işlemlerini karşılıyor, secondary replica ise yüksek erişilebilirlik ve felaket senaryoları için hazır bekliyor.
Bir DBA veya yetkili bir kullanıcı, planlı bir maintenance işlemi sırasında data movement’ı geçici olarak durdurmak istiyor ve aşağıdaki komutu çalıştırıyor:
ALTER DATABASE [FinanceDB] SET HADR SUSPEND;İşlem sonrası uygulama çalışmaya devam ediyor. Primary replica üzerinde transaction’lar alınmaya devam ediyor. Monitoring ekranında SQL servisleri ayakta görünüyor. Listener cevap veriyor. Hatta bazı basit health check ekranlarında her şey yeşil görünebiliyor.
İşte tehlike tam bu noktada başlıyor.
Çünkü HADR SUSPEND sonrası primary replica üzerindeki değişiklikler secondary replica’ya gönderilmez. Bu değişiklikler transaction log üzerinde birikmeye başlar. Secondary database suspended durumda kaldığı sürece, primary database’in transaction log’u truncate edilemez ve log kayıtları primary üzerinde birikmeye devam eder. Microsoft, suspended secondary database’in hızlıca resume edilmesini veya gerekiyorsa availability group’tan çıkarılmasını özellikle önerir.
Yeşil Dashboard Neden Yanıltıcı Olabilir?
Birçok kurumda monitoring sistemleri SQL Server servis durumunu, listener erişilebilirliğini, disk kullanımını, CPU/RAM değerlerini veya cluster node durumunu izler. Bunlar elbette önemlidir; ancak Always On AG ortamlarında yeterli değildir.
Çünkü AG özelinde izlenmesi gereken farklı metrikler vardır:
- Data movement suspended mı?
- Suspend sebebi nedir?
- Log send queue büyüyor mu?
- Redo queue birikiyor mu?
- Secondary replica primary’den ne kadar geride?
- Transaction log neden truncate edilemiyor?
- Catch-up süresi ne kadar olacak?
SQL Server tarafında sys.dm_hadr_database_replica_states DMV’si, availability database’lerin replica durumlarını, synchronization state bilgisini, suspend durumunu ve suspend reason bilgisini izlemek için kullanılır. Bu DMV içinde örneğin SUSPEND_FROM_USER, data movement’ın bir kullanıcı tarafından manuel olarak askıya alındığını gösterir.
Yani sadece “SQL Server ayakta mı?” sorusunu sormak yeterli değildir. Asıl sorulması gereken soru şudur:
SQL Server ayakta ama Availability Group gerçekten sağlıklı mı?
Asıl Risk: Transaction Log’un Kontrolsüz Büyümesi
HADR SUSPEND sonrası primary replica üzerinde yapılan işlemler durmaz. Uygulama insert, update ve delete işlemlerine devam eder. Ancak bu değişiklikler secondary replica’ya gönderilemediği için transaction log üzerinde birikmeye başlar.
Bu durum özellikle finans, e-ticaret, ERP, üretim veya yoğun batch işlem yapan sistemlerde çok hızlı şekilde büyüyebilir. Eğer log disk alanı doğru planlanmamışsa veya alert mekanizması yoksa, birkaç saat içinde transaction log diski dolabilir.
Transaction log dolduğunda ise zincirleme problemler başlar:
Uygulama yeni transaction yazamaz hale gelir. SQL Server hata üretmeye başlar. Database operasyonları durabilir. Backup ve maintenance süreçleri etkilenebilir. En önemlisi, sistem erişilebilir görünürken aslında iş yükünü sürdüremez hale gelir.
Bu nedenle Always On AG ortamlarında log disk kullanımı yalnızca kapasite metriği olarak değil, aynı zamanda HA sağlığı metriği olarak da değerlendirilmelidir.
Secondary Replica Geride Kaldığında Ne Olur?
Data movement askıya alındığında secondary replica artık primary replica ile aynı noktada değildir. Primary üzerinde yeni veriler oluşmaya devam ederken secondary aynı verileri almaz.
Bu durumun iki temel sonucu vardır.
Birincisi, failover senaryosu riskli hale gelir. Secondary replica güncel değilse, beklenmedik bir felaket durumunda failover kararı veri kaybı ihtimaliyle birlikte değerlendirilmek zorunda kalabilir.
İkincisi, HADR RESUME çalıştırıldığında secondary replica biriken tüm log kayıtlarını işlemek zorunda kalır. Bu süreçte log send, log harden ve redo işlemleri yoğun kaynak tüketebilir. Microsoft’un Always On performans izleme dokümantasyonunda da synchronization sürecinin ve log/redo kuyruklarının performans açısından takip edilmesi gereken temel başlıklar olduğu belirtilir.
Kısacası sorun yalnızca suspend süresinde yaşanmaz. Resume sonrası catch-up süreci de ayrıca izlenmelidir.
İzlenmesi Gereken Temel Metrikler
Always On AG ortamlarında yalnızca genel sistem sağlığını değil, AG’ye özel metrikleri de izlemek gerekir. Özellikle aşağıdaki alanlar kritik öneme sahiptir:
SELECT
ag.name AS ag_name,
ar.replica_server_name,
DB_NAME(drs.database_id) AS database_name,
drs.synchronization_state_desc,
drs.synchronization_health_desc,
drs.is_suspended,
drs.suspend_reason_desc,
drs.log_send_queue_size,
drs.redo_queue_size,
drs.last_commit_time
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar
ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag
ON ar.group_id = ag.group_id;
Burada özellikle şu kolonlara dikkat edilmelidir:
is_suspended değeri 1 ise data movement askıya alınmış demektir.
suspend_reason_desc alanı suspension sebebini gösterir. Örneğin SUSPEND_FROM_USER, işlemin kullanıcı tarafından manuel başlatıldığını ifade eder.
log_send_queue_size, primary üzerinde secondary’ye gönderilmeyi bekleyen log miktarını gösterir.
redo_queue_size, secondary üzerinde uygulanmayı bekleyen log miktarını gösterir.
Ayrıca SQL Server Database Replica performans sayaçlarında yer alan Log Send Queue, primary database log dosyalarında secondary replica’ya henüz gönderilmemiş log kayıtlarının KB cinsinden miktarını gösterir.
Bu Durumdan Nasıl Korunabiliriz?
Bu tip vakaların önüne geçmek için yalnızca teknik monitoring yeterli değildir. Yetki yönetimi, operasyonel disiplin ve değişiklik yönetimi de aynı derecede önemlidir.
Öncelikle HADR SUSPEND komutunun kullanımı sıkı kurallara bağlanmalıdır. Her DBA’in veya her yetkili kullanıcının bu komutu istediği zaman çalıştırabilmesi doğru bir yaklaşım değildir. Bu işlem mutlaka change kaydı, onay, bakım penceresi ve rollback planı ile yapılmalıdır.
İkinci olarak suspension süresi sınırlandırılmalıdır. Burada her sistem için tek bir doğru süre yoktur; ancak yoğun transaction üreten sistemlerde dakikalar bile önemli olabilir. Tecrübelerime göre 30 dakikayı aşan kontrolsüz suspension durumları çoğu ortamda riskli hale gelmeye başlar. Bu süre, sistemin transaction hacmine, log disk kapasitesine ve secondary replica’nın catch-up performansına göre daha kısa da olabilir.
Üçüncü olarak log disk kullanımı yakından takip edilmelidir. Sadece yüzde doluluk değil, büyüme hızı da izlenmelidir. Örneğin log diski yüzde 60 dolu olabilir; ancak dakikada birkaç GB büyüyorsa bu çok kritik bir alarm sebebidir.
Dördüncü olarak AG özelinde alert mekanizmaları kurulmalıdır. Aşağıdaki durumlar mutlaka alarm üretmelidir:
is_suspended = 1suspend_reason_desc = SUSPEND_FROM_USER- Log send queue hızlı büyüyorsa
- Redo queue beklenenin üzerinde artıyorsa
- Transaction log diski belirlenen eşiği aşıyorsa
log_reuse_wait_descdeğeri availability replica kaynaklı bekleme gösteriyorsa- Secondary replica uzun süre synchronized durumuna dönemiyorsa
Microsoft SQL Server policy kontrollerinde de data movement suspended olduğunda ilgili policy’nin unhealthy state’e geçeceği belirtilir. Bu nedenle monitoring sistemlerinin bu bilgiyi doğrudan SQL Server AG metriklerinden alması gerekir.
Vaka Özeti: Küçük Bir Komut, Büyük Bir Risk
Geçtiğimiz ay karşılaştığımız vakada, yetkili bir kullanıcı maintenance amacıyla bir availability database üzerinde HADR SUSPEND işlemi gerçekleştirmişti. İlk aşamada sistem çalışmaya devam ettiği için durum fark edilmedi. Primary replica işlem almaya devam ediyor, uygulama tarafı normal görünüyor ve temel monitoring ekranlarında kritik bir alarm oluşmuyordu.
Ancak maintenance süresi planlanandan uzun sürdü. Bu sırada primary replica üzerindeki transaction log büyümeye başladı. Secondary replica geride kaldı ve log disk kullanımı kritik seviyeye yaklaştı.
Neyse ki log büyümesini ve AG durumunu izleyen alert mekanizmamız devreye girdi. Durum fark edildi, ilgili ekipler hızlıca bilgilendirildi ve kontrollü şekilde HADR RESUME işlemi yapıldı.
Resume sonrası secondary replica’nın biriken logları işlemesi beklendi. Bu süreçte redo queue, log send queue, disk I/O, CPU kullanımı ve replica synchronization durumu yakından takip edildi. Sistem tekrar sağlıklı duruma getirildi.
Bu olay bize çok net bir şeyi tekrar hatırlattı:
Always On AG ortamlarında yeşil dashboard görmek, her şeyin gerçekten sağlıklı olduğu anlamına gelmez.
HADR RESUME Sonrası da Dikkatli Olunmalı
Birçok ekip hatayı yalnızca suspend sürecinde arar. Oysa resume sonrası da dikkatli olunmalıdır.
HADR RESUME komutu çalıştırıldığında secondary replica kaldığı yerden devam etmeye çalışır. Eğer primary üzerinde çok fazla transaction oluşmuşsa, secondary replica’nın bu logları alması, harden etmesi ve redo işlemlerini tamamlaması zaman alabilir.
Bu süreçte şu kaynaklarda artış görülebilir:
- Network trafiği
- Disk I/O
- CPU kullanımı
- Redo queue
- Log harden beklemeleri
- Secondary replica üzerinde read-only workload gecikmeleri
Bu nedenle resume komutu çalıştırıldıktan sonra “komut başarılı oldu” diyerek süreç bırakılmamalıdır. Secondary replica gerçekten synchronized duruma gelene kadar takip devam etmelidir.
Secondary Replica Üzerinde Maintenance Konusunda Önemli Not
Always On AG mimarisinde secondary replica çoğunlukla read-only workload, raporlama, backup offload veya read-only routing gibi senaryolar için kullanılır. Microsoft dokümantasyonu da readable secondary replica kullanımını read-only query ve reporting workload offload senaryoları üzerinden açıklar.
Bu nedenle index rebuild gibi veri değiştiren klasik bakım işlemlerinin doğrudan secondary availability database üzerinde yapılabileceği düşünülmemelidir. Index maintenance genellikle primary replica üzerinde planlanmalı, oluşan değişiklikler AG mekanizmasıyla secondary replica’ya aktarılmalıdır.
Eğer amaç backup offload, raporlama, read-only workload yönetimi, patching, storage bakımı veya geçici performans rahatlatması ise her senaryo ayrı değerlendirilmelidir. HADR SUSPEND bu işlerin tamamı için standart ve ilk tercih edilecek yöntem değildir. Bazı durumlarda daha güvenli alternatifler tercih edilebilir.
En İyi Uygulama Önerileri
Production ortamlarında HADR SUSPEND kullanımı için aşağıdaki prensipleri önerebilirim:
HADR SUSPEND komutunu yalnızca gerçekten gerekli olduğunda kullanın.
İşlem öncesinde mutlaka change kaydı oluşturun.
İşlem için net bir başlangıç ve bitiş süresi belirleyin.
Rollback planı olmadan production ortamında işlem yapmayın.
Log disk kapasitesini işlem öncesinde kontrol edin.
İşlem sırasında log büyüme hızını takip edin.
AG dashboard yerine doğrudan DMV ve AG metriklerinden doğrulama yapın.
Resume sonrası secondary replica synchronized olana kadar izlemeye devam edin.
Yetkisiz veya kontrolsüz kullanımı engellemek için rol ve permission yönetimini gözden geçirin.
Alert mekanizması yoksa HADR SUSPEND kullanılan bir ortamı production-ready kabul etmeyin.
