SQL Server Always On Availability Groups: Adım Adım Kurulum ve Strateji

Merhaba,

SQL Server Always On Availability Groups, kurumsal veritabanı ortamlarında yüksek erişilebilirlik ve felaket kurtarmanın birincil çözümü. Database Mirroring'in yerine geçen bu teknoloji artık olgunlaştı ve neredeyse her kurumsal SQL Server dağıtımında kullanılıyor. Gelin derinlemesine inceleyelim arkadaşlar.

Always On AG Nedir?

SQL Server Always On AG, aynı veritabanının birden fazla SQL Server instance'ında eş zamanlı tutulmasını sağlıyor. Primary replica yazma işlemlerini alır, secondary replica'lar veriyi alır. Primary arızalandığında secondary otomatik veya manuel olarak primary'ye terfi ettirilebiliyor. Tek bir AG'de maksimum 9 secondary replica mümkün (SQL Server 2022).

Senkron vs Asenkron Replica

En kritik tasarım kararı bu:

• Senkron commit: Primary, transaction'ı secondary'ye yazdığını onaylamadan commit etmiyor. Sıfır veri kaybı garantisi ama ağ gecikmesi write performansını etkiliyor. Aynı data center veya düşük latency WAN için uygun. Otomatik failover sadece senkron replica'larla mümkün.
• Asenkron commit: Primary beklemiyor, secondary kendi hızında yetişiyor. Yüksek performans ama failover'da veri kaybı riski var. Farklı lokasyonlar için (DR site) tercih edilir.

Kurumsal tasarım: aynı lokasyonda 1 senkron secondary (otomatik failover), DR lokasyonunda 1 asenkron secondary (manuel failover).

Windows Server Failover Cluster (WSFC) Gereksinimi

Always On AG, WSFC (Windows Server Failover Cluster) üzerine kuruluyor. Her node'un domain'e join olması, cluster kurulumu ve SQL Server AG enable edilmesi gerekiyor. Azure'da SQL Server VM'ler için Cloud Witness kullanılabiliyor (Azure Storage Account quorum için). On-premise'de FSW (File Share Witness) yaygın.

AG Listener: Uygulamaların Bağlantı Noktası

Listener, AG'ye sanal bir IP ve hostname sağlıyor. Uygulamalar listener'a bağlanıyor, failover olduğunda listener otomatik olarak yeni primary'ye yönlendiriyor. Uygulama connection string'inde değişiklik gerekmiyor — bu Always On'un en büyük operasyonel avantajlarından biri.

Readable Secondary: Rapor Yükünü Dağıtın

Secondary replica'lar read-only sorgular için kullanılabiliyor. Raporlama, BI sorguları, data warehouse feed'leri secondary'ye yönlendirilebiliyor. Primary'deki okuma yükü azalıyor. Connection string'e ApplicationIntent=ReadOnly eklemek yeterli — listener otomatik secondary'ye yönlendiriyor. Lisans açısından dikkat: secondary'de SQL Server lisansı gerekiyor.

Monitoring ve Alert

Always On Dashboard (SSMS ile) AG durumunu görsel olarak gösteriyor. Ama production'da sadece buna güvenmeyin. SQL Server Agent Alert ile AG health state değişikliklerinde e-posta alert kurun. sys.dm_hadr_availability_replica_states DMV'si ile synchronization lag'ı izleyin. 30 saniyeyi geçen lag ciddi sorun sinyali.

Yaygın Hatalar

Sahadan birkaç gözlem: DTC (Distributed Transaction Coordinator) gerektiren cross-database transaction'lar AG ile çalışmıyor — mimariyi buna göre tasarlayın. Backup stratejisi secondary'yi dahil etmeli ama hangi node'un backup alacağını sys.fn_hadr_backup_is_preferred_replica ile kontrol edin. Ve en önemlisi: failover testini production öncesi mutlaka yapın — DR testleri gerçek arıza geldiğinde hayat kurtarıyor.

Sonuç

SQL Server Always On AG, kurumsal ortamda artık standart mimari. Senkron/asenkron replica kararı, listener konfigürasyonu ve readable secondary — bunları doğru kurgularsanız hem yüksek erişilebilirlik hem de raporlama ölçeklenebilirliği elde ediyorsunuz :)

İyi Günler Dilerim,