Always On Availability Groups ile Failover Cluster Instance arasındaki temel fark nedir?

FCI tüm SQL Server instance'ını korur ve shared storage (SAN) gerektirir; node'lar aynı diski paylaşır. Availability Groups ise veritabanı düzeyinde çalışır, her node bağımsız storage kullanır ve log gönderimi ile senkronizasyon yapar. Bu nedenle AG, cloud ve hybrid senaryolarda çok daha esnektir.

Otomatik failover için hangi koşullar sağlanmalıdır?

Otomatik failover yalnızca synchronous commit modunda yapılandırılmış replica'lar arasında çalışır. Ayrıca ilgili secondary replica SYNCHRONIZED durumda olmalı, failover modu Automatic seçilmeli ve WSFC quorum'u sağlıklı durumda bulunmalıdır. Asenkron replica'lar yalnızca manuel veya forced failover ile devreye alınabilir.

Bir Availability Group'ta kaç secondary replica desteklenir?

SQL Server 2014 ile 8 secondary desteği gelmiştir ve bu sınır 2016, 2017, 2019 ve 2022 sürümlerinde de geçerlidir. Bu 8 replica'nın en fazla 3 tanesi senkron commit modunda olabilir, geri kalanlar asenkron yapılandırılır. Basic AG'de ise yalnızca 1 secondary izin verilir.

Always On kurmak için domain ortamı zorunlu mudur?

SQL Server 2016 öncesi sürümlerde Active Directory domain zorunluydu. 2016 ile birlikte Workgroup Cluster ve domain-independent Availability Groups desteği geldi; sertifika tabanlı kimlik doğrulama ile domain olmadan AG kurulabilir. Yine de kurumsal ortamlarda domain'li senaryolar yönetim kolaylığı açısından tercih edilir.

Secondary replica'lar için ayrı SQL Server lisansı gerekir mi?

Software Assurance kapsamındaki pasif secondary replica'lar lisanssız kullanılabilir; pasif olmak, yalnızca failover beklemek anlamına gelir. Ancak secondary üzerinde read-only sorgu, backup veya DBCC CHECKDB çalıştırılırsa replica aktif sayılır ve primary ile aynı çekirdek sayısında lisans gerekir.

Senkron commit modunda ağ gecikmesi ne kadar olmalıdır?

Senkron commit'te primary, secondary'nin log harden onayını beklediği için her transaction'ın commit süresine ağ RTT değeri eklenir. Pratikte 5 ms altı RTT önerilir; 10 ms üzerinde yazma performansı belirgin biçimde düşer. Bu nedenle senkron replica'lar aynı veri merkezi veya yakın metro bağlantısı içinde konumlandırılır.

Always On ortamında backup nereden alınmalıdır?

Backup preference ayarı ile secondary'lerden öncelikli yedek alınacak şekilde yapılandırılabilir. Secondary üzerinden COPY_ONLY full backup ve transaction log backup desteklenir, böylece primary'nin I/O yükü azalır. Differential backup yalnızca primary'de alınabilir; bu nedenle yedekleme stratejisi bu kısıtı dikkate almalıdır.

SQL SERVER ALWAYS ON NEDİR?

Q: Read-Only Routing tam olarak ne işe yarar?

Read-Only Routing, ApplicationIntent=ReadOnly parametresiyle gelen bağlantıları otomatik olarak salt okunur secondary replica'ya yönlendirir. Bu sayede raporlama, BI ve analitik sorguları primary'yi yormadan secondary üzerinden çalışır. Connection string tarafında listener adresi değişmez, yönlendirme listener tarafından şeffafça yapılır.

SQL Server Always On primary veri tabanı silindiri ve secondary replica düğümlerinin senkron bağlantısı

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.

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.

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.

Senkron ve asenkron commit modlarında veri kopyalama gecikmesinin karşılaştırıldığı iki paralel akış

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.

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:

WSFC, primary'nin offline olduğunu tespit eder ve quorum oylamasını başlatır.
Senkron secondary'ler arasından failover öncelik sırasına göre yeni primary seçilir.
Seçilen replica üzerindeki veritabanları RECOVERY moduna geçer ve okuma/yazma açılır.
Listener'ın IP ve DNS kaydı yeni primary'ye yönlendirilir.
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.

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.

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ı.

Otomatik failover sırasında primary düğümün düşmesi ve secondary replica üzerinden devralma akışı

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.

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.