SQL Server AG’de Yeşil Dashboard’un Ardındaki Tehlike: HADR SUSPEND

Son zamanlarda SQL Server Always On Availability Groups kullanan bir müşterimizde yaşanan ilginç bir vakayı sizlerle paylaşmak istiyorum. Monitoring ekranlarında her şey yeşil görünürken, aslında ciddi bir veri kaybı riski ile karşı karşıya kalabilirsiniz. Bu yazımda sizlere HADR SUSPEND komutunun görünmeyen tehlikelerinden bahsedeceğim.

Always On AG ortamında senkron modda çalışan bir sistemde, normal şartlarda veri kaybı yaşanmaması gerekir. Primary sunucuda yapılan her işlem, secondary sunucuya yazıldıktan sonra kullanıcıya başarılı yanıtı döner. Bu sayede her iki sunucudaki veriler birebir aynı olur. Peki ya bir DBA yada yetkili bir kullanıcı tarafından , maintenance işlemi yada farklı bir sebepten dolayı bilinçsiz ve yetkisi dahilinde HADR SUSPEND komutunu kullanırsa ne olur?

Gelin gerçek bir senaryo üzerinden ilerleyelim. Diyelim ki yoğun bir finansal sistemde çalışıyorsunuz ve secondary sunucuda bazı index maintenance işlemleri yapmanız gerekiyor. İşlemi gerçekleştirmek için HADR SUSPEND komutunu kullandınız. Dashboard hala yeşil görünüyor, primary sunucu işlemlerine devam ediyor ve herhangi bir hata almıyorsunuz. Kulağa hoş geliyor, değil mi?

İşte tam bu noktada tehlike başlıyor. SUSPEND durumunda primary sunucudaki tüm işlemler transaction log’da birikmeye başlar. Secondary’ye gönderilmeyi bekleyen bu log kayıtları, disk alanınızı hızla doldurabilir. Daha da kötüsü, bu süre zarfında primary’de yapılan işlemler secondary’ye hiç ulaşmaz. Yani görünürde senkron çalışan bir sistemde, aslında ciddi bir veri farkı oluşmaya başlar.

Peki bu durumdan nasıl korunabiliriz? İşte size birkaç önemli öneri:

1. HADR SUSPEND kullanımını sıkı kurallara bağlayın. Her DBA’in istediği zaman kullanabileceği bir komut olmamalı.
2. Suspension süresini kesinlikle sınırlayın. Tecrübelerime göre 30 dakikayı geçen suspension’lar genellikle sorunla sonuçlanıyor.
3. Log disk kullanımını yakından takip edin. Primary sunucuda biriken log kayıtları sizi zor durumda bırakabilir.
4. Mutlaka monitoring ve alerting sistemi kurun. SUSPEND durumunu ve log büyümesini takip eden alertler hayat kurtarıcı olabilir.

Geçen ay karşılaştığımız bir vakada, bir DBA arkadaşımız secondary’de index maintenance yapmak için HADR SUSPEND kullanmıştı. İşlem planlandığından uzun sürünce, primary’deki log disk dolmaya başladı. Neyse ki alerting sistemimiz bizi uyardı ve hızlıca müdahale edebildik. Aksi halde sistemin durması kaçınılmaz olacaktı.

HADR RESUME işleminden sonra da dikkatli olmalısınız. Secondary sunucu, biriken tüm log kayıtlarını işlemek zorunda kalacak ve bu süre zarfında yüksek kaynak kullanımı görülebilir. Bu catch-up sürecini de yakından takip etmek gerekiyor.

Sonuç olarak, Always On AG’de yeşil bir dashboard görüyor olmanız her şeyin yolunda olduğu anlamına gelmiyor. HADR SUSPEND gibi maintenance amaçlı kullanılan komutların arkasındaki riskleri iyi anlamalı ve gerekli önlemleri almalısınız.

Bu konuda sizin de benzer tecrübeleriniz var mı? Yorumlarda paylaşırsanız sevinirim. Bir sonraki yazımda AG ortamlarında karşılaştığımız diğer ilginç vakalardan bahsedeceğim. Takipte kalın!

Not: Bu yazıda bahsedilen senaryoları test ortamınızda deneyerek tecrübe kazanmanızı şiddetle tavsiye ederim. Production ortamda yapacağınız her işlem için mutlaka bir rollback planınız olsun.HADR SUSPEND kullanmak tek çözüm olmamak ile birlikte alternatif kullanımları da bir sonraki makale de anlatıyor olacağım.