SQL SERVER ALWAYS ON NEDİR?

Cuma akşamı 18:42. Primary node aniden yanıt vermiyor, uygulama ekibi telefonda, müşteri çağrı merkezi kilitli. Yedekten dönüş 4 saat sürdü ve bu süreçte hiçbir sipariş işlenemedi. Oysa aynı senaryo Always On Availability Groups kurulu bir ortamda yaşansaydı, secondary replica saniyeler içinde devreye girer ve kullanıcı bir kesinti bile fark etmezdi. SQL Server'ın bu yüksek erişilebilirlik çözümü, downtime maliyetini saatlerden saniyelere indirir.

1. SQL Server Always On Nedir?

Always On, SQL Server 2012 ile birlikte tanıtılan ve klasik Database Mirroring ile Failover Cluster Instance (FCI) çözümlerinin yerini alan kurumsal seviye bir yüksek erişilebilirlik (HA) ve felaket kurtarma (DR) teknolojisidir. Temelinde Windows Server Failover Cluster (WSFC) servisini kullanır; ancak veritabanı düzeyinde çalıştığı için tüm instance'ı değil, seçilen veritabanı gruplarını koruma altına alır.

İki ana bileşeni vardır: Availability Groups (AG) ve Failover Cluster Instances (FCI). Çoğu kurumsal senaryoda kastedilen, Availability Groups yapısıdır. Bir AG; bir primary replica ile bir veya daha fazla secondary replica arasında veritabanı kopyalarını senkronize tutar. Pratik detaylar için kapsamlı dokümanları incelenebilir.

2. Availability Group Mimarisinin Bileşenleri

Bir Always On AG ortamı aşağıdaki yapı taşlarından oluşur:

• Primary Replica: Okuma ve yazma işlemlerinin yapıldığı asıl node. Aynı anda yalnızca bir tane olabilir.
• Secondary Replica: Primary'den gelen log kayıtlarını uygulayan kopyalar. SQL Server 2019 ile bir AG'de en fazla 8 secondary desteklenir.
• Availability Database: Gruba dahil edilmiş, korunan veritabanı. Birden fazla veritabanı tek bir AG altında birleştirilebilir.
• Listener: Uygulamaların bağlandığı sanal ağ adı (VNN). Failover sonrası bağlantı yeniden yönlendirme bu katmanda olur.
• WSFC Quorum: Cluster'ın sağlığını belirleyen oylama mekanizması. File share witness veya cloud witness ile desteklenir.

3. Senkron ve Asenkron Replikasyon Modları

Always On iki farklı commit modu sunar ve seçim doğrudan failover davranışını belirler:

• Synchronous Commit: Primary, transaction'ı yalnızca secondary'nin log kaydını disk'e yazdığını onayladıktan sonra commit eder. Veri kaybı sıfırdır (RPO = 0) ve otomatik failover yalnızca bu modda mümkündür. Latency'ye duyarlı, aynı veri merkezi içinde önerilir.
• Asynchronous Commit: Primary, secondary'yi beklemeden commit eder. Coğrafi olarak uzak DR site'lar için idealdir; ancak yalnızca manuel failover ve potansiyel veri kaybı içerir.

Bir AG içinde her replica için commit modu bağımsız ayarlanabilir. Tipik bir kurumsal yapı: aynı şehirde 2 senkron secondary + uzak DR lokasyonunda 1 asenkron secondary.

4. Otomatik Failover Nasıl Çalışır?

Primary node'un sağlık durumunu WSFC sürekli izler. SQL Server servisi yanıt vermediğinde, disk erişimi kaybolduğunda veya node tamamen düştüğünde aşağıdaki akış tetiklenir:

1. WSFC, primary'nin offline olduğunu tespit eder ve quorum oylamasını başlatır.
2. Senkron secondary'ler arasından failover öncelik sırasına göre yeni primary seçilir.
3. Seçilen replica üzerindeki veritabanları RECOVERY moduna geçer ve okuma/yazma açılır.
4. Listener'ın IP ve DNS kaydı yeni primary'ye yönlendirilir.
5. Uygulamalar connection string'i değiştirmeden, sadece bağlantıyı yenileyerek devam eder.

Bu süreç tipik olarak 10-30 saniye sürer. Doğru yapılandırılmış bir Always On ortamı, 4 saatlik downtime senaryolarını sub-dakika seviyesine indirir. Konuyu derinlemesine ele alan bir SQL Server DBA eğitimi programından yararlanarak failover senaryolarını lab ortamında deneyimleyebilirsiniz.

5. Read-Only Routing ve Yük Dağıtımı

Always On'un performans tarafındaki en büyük katkılarından biri, secondary replica'ların salt okunur sorgulara hizmet verebilmesidir. Read-Only Routing yapılandırıldığında, ApplicationIntent=ReadOnly parametresiyle bağlanan istemciler otomatik olarak okuma yapan replica'ya yönlendirilir.

Bu sayede raporlama, BI ve analitik sorguları primary'nin yükünden ayrıştırılır. Backup operasyonları da secondary üzerinden alınarak primary'nin I/O baskısı azaltılır.

6. Always On Kurmadan Önce Kontrol Listesi

• SQL Server Enterprise Edition (Basic AG için Standard yeterli, 1 DB & 1 secondary sınırı vardır).
• Tüm node'larda aynı versiyon ve patch seviyesi.
• WSFC kurulumu ve quorum modeli kararı (Node Majority, File Share Witness, Cloud Witness).
• Domain ortamı veya SQL Server 2016+ için domain-independent AG (Workgroup Cluster).
• Yeterli ağ bant genişliği: senkron replikasyon için < 5 ms RTT önerilir.
• Veritabanlarının FULL recovery model'de olması ve full backup alınmış olması.

7. FCI ve Database Mirroring ile Farkı

Failover Cluster Instance (FCI) tüm SQL Server instance'ını koruma altına alır ve paylaşımlı disk (SAN) gerektirir. Always On AG ise her node'da bağımsız storage kullanır, shared disk gereksinimi yoktur. Bu mimari fark, AG'yi cloud ve hybrid senaryolar için çok daha esnek kılar.

Database Mirroring (deprecated) yalnızca tek bir veritabanını, tek bir mirror'a kopyalayabiliyordu. Always On ise hem birden çok veritabanını tek grupta yönetir hem de 8 secondary'ye kadar ölçeklenir. Yeni projelerde mirroring tercih edilmez; mevcut mirroring ortamlarının AG'ye taşınması önerilir. Migrasyon planlaması için DBA eğitim içeriklerini inceleyebilirsiniz.

8. Maliyet ve Lisanslama Notları

Always On AG, lisans tarafında dikkat gerektiren bir konudur. Secondary replica'lar pasif olarak duruyorsa (failover bekliyorsa) Software Assurance kapsamında lisanssız olabilir; ancak read-only sorgu, backup veya DBCC CHECKDB çalıştırılır çalıştırılmaz aktif sayılır ve ayrı lisans gerekir. Microsoft 2019 sonrası bu kuralı sıkılaştırmıştır, kurulum öncesi lisans danışmanıyla doğrulama yapılmalıdır.

Sonuç olarak Always On, SQL Server tarafında downtime'ı saatlerden saniyelere indiren, okuma yükünü dağıtan ve DR planlamasını tek mimari altında toplayan olgun bir çözümdür. Doğru kurgulanmış bir AG ortamı, cuma akşamı 18:42'de yaşanan o 4 saatlik kesinti senaryosunun bir daha tekrarlanmamasını sağlar.