SQL Server Always On Nedir? Availability Groups ve FCI Rehberi

SQL Server Always On, kritik SQL Server ortamlarında yüksek erişilebilirlik ve disaster recovery gereksinimlerini karşılamak için kullanılan teknolojileri kapsar. Ancak “Always On” tek bir özellik değildir. SQL Server ortamının ihtiyacına göre Availability Groups, Failover Cluster Instance (FCI), synchronous veya asynchronous replica yapıları ve farklı failover modelleri birlikte değerlendirilebilir.

Doğru mimariyi seçmek için yalnızca “sistem kesilmesin” hedefi yeterli değildir. Hangi seviyede koruma gerektiği, kabul edilebilir veri kaybı, kesinti süresi, veri merkezi yapısı, network latency, SQL Server edition, lisanslama ve uygulama bağlantıları birlikte değerlendirilmelidir.

Bu rehberde SQL Server Always On yapısını, Availability Groups ile Failover Cluster Instance arasındaki farkları, synchronous ve asynchronous çalışma modellerini ve kritik SQL Server ortamlarında HA/DR mimarisi planlanırken dikkat edilmesi gereken başlıkları ele alıyoruz.

SQL Server Always On Nedir?

SQL Server Always On, Microsoft SQL Server’ın high availability ve disaster recovery çözümlerini kapsayan yapıdır.

Başlıca iki teknoloji öne çıkar:

• Always On Availability Groups (AG)
• Always On Failover Cluster Instances (FCI)

İki teknoloji de SQL Server erişilebilirliğini artırmaya yönelik olsa da aynı problemi aynı seviyede çözmez.

Availability Groups temel olarak veri tabanı seviyesinde koruma sağlarken, Failover Cluster Instance SQL Server instance seviyesinde yüksek erişilebilirlik sağlar.

Microsoft’un güncel SQL Server business continuity dokümantasyonunda Availability Groups, Failover Cluster Instances ve log shipping farklı high availability ve disaster recovery senaryoları için kullanılan temel seçenekler arasında yer alır.

SQL Server Availability Group Nedir?

Always On Availability Groups, bir veya daha fazla kullanıcı veri tabanını farklı SQL Server instance’ları arasında korumaya yönelik high availability ve disaster recovery çözümüdür.

Yapıda bir primary replica bulunur. Secondary replica’lar primary üzerindeki transaction log değişikliklerini alarak kendi veri tabanı kopyalarını güncel tutar.

Bir failover gerçekleştiğinde uygun secondary replica primary role geçebilir ve uygulamalar yeni primary üzerinden çalışmaya devam edebilir.

Availability Group içindeki veri tabanları birlikte failover edilecek şekilde gruplanabilir. Bu özellik özellikle aynı uygulamaya ait birden fazla veri tabanının birlikte çalıştığı kurumsal sistemlerde önemlidir.

Primary Replica

Primary replica, uygulamaların normal koşullarda read/write işlemlerini gerçekleştirdiği aktif SQL Server instance’ıdır.

Secondary Replica

Secondary replica, primary veri tabanındaki transaction log değişikliklerini alarak veri tabanının güncel bir kopyasını tutar.

Mimariye ve SQL Server edition’a bağlı olarak secondary replica high availability, disaster recovery, read-only workload veya belirli backup senaryoları için kullanılabilir.

Synchronous ve Asynchronous Commit Arasındaki Fark Nedir?

Availability Group tasarımındaki en önemli kararlardan biri replica’ların synchronous veya asynchronous çalışmasıdır.

Synchronous Commit

Synchronous commit modunda primary replica, transaction’ı tamamlamadan önce ilgili secondary replica’nın transaction log kaydını diske yazdığını doğrulamasını bekler.

Secondary replica SYNCHRONIZED durumda olduğunda committed transaction’ların korunması açısından daha güçlü bir high availability modeli oluşturulur.

Ancak primary replica secondary’den onay beklediği için network latency transaction response süresini etkileyebilir.

Bu nedenle synchronous replica’lar genellikle network latency’nin düşük olduğu aynı veri merkezi veya birbirine yakın lokasyonlarda değerlendirilir.

Asynchronous Commit

Asynchronous commit modunda primary replica transaction’ı tamamlamak için secondary replica’nın log kaydını diske yazmasını beklemez.

Böylece uzak lokasyonlar arasındaki network latency’nin primary workload üzerindeki etkisi azaltılabilir.

Buna karşılık primary sistemde ani bir kayıp yaşanması durumunda secondary henüz tüm transaction’ları almamış olabilir. Bu nedenle forced failover senaryosunda veri kaybı riski bulunabilir.

Microsoft da Availability Group çalışma modlarını high availability ve disaster recovery gereksinimlerine göre synchronous ve asynchronous olarak ayırır.

Availability Group Listener Nedir?

Availability Group Listener, uygulamaların doğrudan belirli bir SQL Server instance adına bağlanması yerine Availability Group’a bağlanmasını sağlayan sanal network adıdır.

Listener genel olarak:

• DNS adı
• Port
• Bir veya daha fazla IP adresi

bileşenlerinden oluşur.

Failover sonrasında uygulama hangi replica’nın primary olduğunu bilmek zorunda kalmadan listener üzerinden yeni primary replica’ya bağlanabilir.

Bu yapı application connection yönetimini önemli ölçüde kolaylaştırır. Microsoft da Availability Group Listener kullanımını uygulamaların replica’nın fiziksel instance adını bilmeden bağlanabilmesi için kullanılan temel mekanizma olarak tanımlar.

Automatic Failover ve Manual Failover

Availability Group yapısında failover davranışı availability mode ve failover mode yapılandırmasına bağlıdır.

Automatic Failover

Automatic failover için primary ve ilgili secondary replica’nın uygun synchronous yapılandırmada bulunması ve secondary replica’nın synchronized durumda olması gerekir.

Primary replica kullanılamaz hale geldiğinde uygun cluster ve replica koşulları sağlanıyorsa secondary replica otomatik olarak primary role geçebilir.

Planned Manual Failover

Planlı bakım, patching veya infrastructure çalışmaları sırasında primary role kontrollü olarak secondary replica’ya geçirilebilir.

Synchronized synchronous replica kullanılması planlı failover sırasında veri kaybı riskini azaltan temel koşullardan biridir.

Forced Failover

Primary replica tamamen erişilemez olduğunda ve synchronized secondary bulunmadığında forced failover gerekebilir.

Bu durumda secondary replica henüz primary üzerindeki tüm transaction’ları almamış olabileceği için veri kaybı oluşabilir.

SQL Server Failover Cluster Instance Nedir?

Failover Cluster Instance, SQL Server instance’ının Windows Server Failover Cluster üzerindeki birden fazla node tarafından barındırılabildiği high availability çözümüdür.

Availability Group veri tabanı seviyesinde koruma sağlarken FCI SQL Server instance seviyesinde koruma sağlar.

FCI yapısında SQL Server instance aynı anda cluster node’larından biri üzerinde aktif çalışır. Aktif node kullanılamaz hale gelirse SQL Server instance başka bir node üzerinde başlatılır.

FCI’nin önemli özelliklerinden biri SQL Server system database’leri, SQL Agent Jobs, logins ve diğer instance-level bileşenlerin de instance ile birlikte korunabilmesidir.

Klasik FCI mimarisi shared storage kullanır. Availability Groups ise veri tabanlarının her replica üzerinde ayrı kopyalarını tuttuğu için aynı shared storage modeline ihtiyaç duymaz.

Availability Groups ve FCI Arasındaki Fark

Microsoft da server-level redundancy gerektiğinde Failover Cluster Instance kullanımını, veri tabanı seviyesindeki yüksek erişilebilirlik ve disaster recovery için ise Availability Groups yaklaşımını ayrı mimari seçenekler olarak ele alır.

SQL Server Standard ve Enterprise Always On Farkı

SQL Server edition seçimi Always On mimarisinin kapsamını doğrudan etkiler.

SQL Server 2025’te Enterprise Edition full Always On Availability Groups özelliklerini destekler.

Standard Edition ise Basic Availability Groups kullanabilir.

Microsoft’un güncel SQL Server 2025 edition karşılaştırmasına göre Basic Availability Group:

• Standard Edition için sunulur
• Tek bir veri tabanını kapsar
• İki replica ile çalışır

Enterprise Edition ise daha gelişmiş Availability Group topolojileri, çoklu secondary replica ve ek high availability özellikleri sağlar.

FCI tarafında hem Standard hem Enterprise destek bulunur; ancak Standard Edition FCI node sayısı açısından Enterprise’a göre daha sınırlıdır.

Güncel edition özellikleri Microsoft’un SQL Server 2025 edition karşılaştırmasından doğrulanmalıdır.

High Availability ile Disaster Recovery Aynı Şey mi?

Hayır. High availability ile disaster recovery birbirini tamamlayan ancak farklı risklere odaklanan yapılardır.

High Availability

High availability temel olarak tek bir sunucu, SQL Server instance veya lokal altyapı bileşeninin arızalanması durumunda hizmet kesintisini azaltmaya odaklanır.

Örneğin aynı veri merkezindeki iki replica arasında synchronous Availability Group kullanılması high availability mimarisinin bir parçası olabilir.

Disaster Recovery

Disaster recovery ise yalnızca tek sunucu arızasını değil, tüm veri merkezi veya lokasyonun kullanılamaz hale gelmesi gibi daha geniş felaket senaryolarını ele alır.

Bu amaçla farklı lokasyonda asynchronous replica, log shipping veya başka DR teknolojileri değerlendirilebilir.

Güçlü bir kurumsal mimaride yalnız HA veya yalnız DR yerine iki hedef birlikte planlanır.

RPO ve RTO Always On Tasarımını Nasıl Etkiler?

Always On tasarımından önce iki temel iş hedefinin belirlenmesi gerekir:

RPO – Recovery Point Objective

RPO, bir kesinti veya felaket durumunda kurumun kabul edebileceği maksimum veri kaybı miktarını ifade eder.

Çok düşük RPO hedefi bulunan sistemlerde replica synchronization yöntemi ve network tasarımı daha kritik hale gelir.

RTO – Recovery Time Objective

RTO, sistemin kesinti sonrasında ne kadar süre içinde yeniden hizmet vermesi gerektiğini ifade eder.

Örneğin birkaç saatlik kesintiyi tolere edebilen bir sistemle saniyeler veya dakikalar içinde devreye dönmesi gereken kritik payment sisteminin HA/DR tasarımı aynı olmaz.

Bu nedenle Always On mimarisinin başlangıç noktası teknoloji seçimi değil, iş birimleriyle birlikte belirlenen RPO ve RTO hedefleri olmalıdır.

SQL Server Always On Quorum Neden Önemlidir?

Windows üzerinde klasik Availability Group mimarilerinde Windows Server Failover Clustering önemli bir rol oynar.

Cluster, hangi node’ların aktif olduğunu ve cluster’ın güvenli şekilde çalışmaya devam edip edemeyeceğini quorum mekanizması üzerinden değerlendirir.

Quorum yapılandırmasının amacı yalnızca “çoğunluğu bulmak” değildir. Network partition gibi durumlarda iki farklı node grubunun aynı anda primary olduğunu düşünmesi sonucu oluşabilecek split-brain riskini önlemek de kritik hedeflerden biridir.

Node sayısı, lokasyon dağılımı ve witness yapısı değerlendirilerek uygun quorum modeli oluşturulmalıdır.

Always On Backup Yerine Geçer mi?

Hayır. High availability ve disaster recovery teknolojileri sağlam bir backup ve restore stratejisinin yerine geçmez.

Örneğin kullanıcı yanlışlıkla veri silerse veya uygulama hatalı bir transaction gerçekleştirirse bu değişiklik Availability Group replica’larına da aktarılabilir.

Aynı şekilde logical corruption, güvenlik olayı veya operasyonel hata yalnızca secondary replica bulunmasıyla çözülemez.

Microsoft da SQL Server availability özelliklerinin iyi tasarlanmış ve test edilmiş bir backup ve restore stratejisinin yerine geçmediğini açıkça belirtmektedir.

Bu nedenle kritik SQL Server ortamlarında Always On ile birlikte:

• Full backup
• Differential backup
• Transaction log backup
• Retention politikası
• Off-site veya immutable backup seçenekleri
• Düzenli restore testleri

ayrıca planlanmalıdır.

SQL Server Always On Lisanslama Nasıl Değerlendirilmeli?

Always On mimarisi planlanırken lisanslama altyapı tasarımından ayrı ele alınmamalıdır.

Primary ve secondary SQL Server workload’larının kullanım şekli, SQL Server edition, Software Assurance veya subscription kapsamı ve secondary replica’nın aktif workload çalıştırıp çalıştırmadığı lisans gereksinimlerini etkileyebilir.

Microsoft’un güncel SQL Server 2025 lisanslama rehberi, uygun Software Assurance veya subscription kapsamındaki lisanslar için high availability ve disaster recovery amaçlı passive failover hakları tanımlar.

Ancak secondary sistem üzerinde aktif reporting, read workload veya farklı üretim işleri çalıştırılması lisanslama değerlendirmesini değiştirebilir.

Bu nedenle Always On mimarisindeki replica sayısı ve rollerinin lisans planıyla birlikte değerlendirilmesi gerekir.

Always On Ortamlarında Neler İzlenmeli?

Always On yapısının kurulması yüksek erişilebilirliğin otomatik olarak sürekli korunacağı anlamına gelmez. Replica ve cluster sağlığının düzenli olarak izlenmesi gerekir.

Monitoring kapsamında özellikle aşağıdaki başlıklar takip edilmelidir:

• Replica health
• Synchronization state
• Synchronization health
• Log send queue
• Redo queue
• Replica connectivity
• Database state
• Cluster node health
• Quorum ve witness durumu
• Listener erişilebilirliği
• Network latency
• Failover readiness

Özellikle asynchronous DR replica’larında log send queue’nun büyümesi secondary sistemin primary’nin gerisinde kaldığını gösterebilir.

Bu nedenle yalnız alarm üretmek değil, replica’ların gerçek failover durumuna hazır olup olmadığını düzenli olarak kontrol etmek gerekir.

SQL Server Always On Mimarisi Nasıl Planlanır?

1. Mevcut Ortam Analizi

SQL Server instance’larını, veri tabanlarını, uygulama bağlantılarını, mevcut cluster yapısını ve altyapı bağımlılıklarını inceliyoruz.

2. RPO ve RTO Hedeflerinin Netleştirilmesi

Kritik uygulamalar için kabul edilebilir veri kaybı ve kesinti sürelerini netleştiriyoruz.

3. HA ve DR Gereksinimlerinin Ayrılması

Aynı veri merkezi içindeki high availability ihtiyacıyla farklı lokasyondaki disaster recovery ihtiyacını ayrı değerlendiriyoruz.

4. Availability Group veya FCI Seçimi

Veri tabanı veya instance-level koruma ihtiyacına göre Availability Groups, FCI veya gerektiğinde iki teknolojinin birlikte kullanılabileceği mimarileri değerlendiriyoruz.

5. Replica ve Synchronization Tasarımı

Replica lokasyonlarını, synchronous ve asynchronous çalışma modellerini, automatic veya manual failover senaryolarını planlıyoruz.

6. Cluster, Quorum ve Listener Tasarımı

WSFC yapısını, quorum modelini, witness kullanımını ve application connectivity için listener tasarımını netleştiriyoruz.

7. Test ve Failover Senaryoları

Primary node kaybı, replica kaybı, network problemi ve disaster recovery senaryoları için test planları oluşturuyoruz.

8. Monitoring ve Operasyon Modeli

Replica health, synchronization, failover readiness ve kritik SQL Server metriklerini düzenli olarak izlenecek şekilde operasyon modeline dahil ediyoruz.

SQL Server Always On Yapısında Sık Yapılan Hatalar

• HA ile DR’ı aynı kavram olarak değerlendirmek
• RPO ve RTO belirlemeden mimari seçmek
• Uzak veri merkezleri arasında network latency’yi ölçmeden synchronous replica planlamak
• Listener kullanmadan uygulamaları doğrudan instance isimlerine bağlamak
• Quorum ve witness tasarımını göz ardı etmek
• Availability Group’un backup ihtiyacını ortadan kaldırdığını düşünmek
• Secondary replica’nın gerçekten synchronized olup olmadığını izlememek
• Failover testlerini yalnız kurulum sırasında yapmak
• SQL Server edition limitlerini mimari tasarımdan sonra değerlendirmek
• Secondary replica workload’larını lisanslama açısından dikkate almamak
• SQL Agent Jobs, logins ve diğer instance-level bağımlılıkları göz ardı etmek

SQL Server Always On Checklist

• İş sistemleri için RPO hedefleri belirlendi mi?
• RTO hedefleri belirlendi mi?
• HA ve DR gereksinimleri ayrı değerlendirildi mi?
• Availability Group mı FCI mı kullanılacağı net mi?
• SQL Server edition özellikleri kontrol edildi mi?
• Synchronous ve asynchronous replica’lar belirlendi mi?
• Network latency ölçüldü mü?
• Automatic failover gereksinimi belirlendi mi?
• WSFC yapısı doğru planlandı mı?
• Quorum ve witness yapılandırıldı mı?
• Availability Group Listener oluşturuldu mu?
• Application connection string’leri kontrol edildi mi?
• Backup ve restore stratejisi ayrıca oluşturuldu mu?
• Failover testleri gerçekleştirildi mi?
• Disaster recovery testi gerçekleştirildi mi?
• Replica health monitoring aktif mi?
• Lisanslama yapısı kontrol edildi mi?
• Runbook ve escalation süreçleri hazır mı?

Sık Sorulan Sorular

SQL Server Always On nedir?

SQL Server Always On, SQL Server ortamlarında high availability ve disaster recovery için kullanılan Availability Groups ve Failover Cluster Instance gibi teknolojileri kapsar.

Always On Availability Group ile FCI arasındaki fark nedir?

Availability Group veri tabanı seviyesinde koruma sağlar ve veri tabanlarının farklı replica’larda ayrı kopyalarını tutar. FCI ise SQL Server instance seviyesinde koruma sağlar ve klasik Windows cluster mimarisinde shared storage kullanır.

SQL Server Standard Edition Always On destekliyor mu?

Evet, ancak Standard Edition full Enterprise Availability Group yerine Basic Availability Groups destekler. SQL Server 2025’te Basic Availability Group tek veri tabanı ve iki replica ile sınırlıdır. Standard Edition ayrıca Failover Cluster Instance desteği de sunar.

Synchronous ve asynchronous replica arasındaki fark nedir?

Synchronous modda primary transaction tamamlanmadan önce secondary replica’nın log kaydını diske yazması beklenir. Asynchronous modda primary secondary’den onay beklemez. Bu nedenle asynchronous yapı uzak DR lokasyonlarında daha uygun olabilir ancak forced failover sırasında veri kaybı riski bulunabilir.

Always On otomatik failover yapar mı?

Uygun synchronous replica ve failover yapılandırmasında automatic failover mümkündür. Asynchronous replica’larda ise automatic failover kullanılmaz ve gerektiğinde manual veya forced failover uygulanır.

Always On kullanıyorsak backup almaya gerek var mı?

Evet. Availability Groups ve FCI backup ve restore stratejisinin yerine geçmez. Kullanıcı hatası, logical corruption, ransomware ve farklı veri kaybı senaryolarına karşı düzenli backup ve restore testleri ayrıca uygulanmalıdır.

SQL Server Always On Mimarisi İş Gereksinimlerine Göre Tasarlanmalı

SQL Server Always On yüksek erişilebilirlik için güçlü seçenekler sunar ancak doğru mimari her kurum için aynı değildir.

Availability Groups ile FCI arasındaki seçim, synchronous ve asynchronous replica yapısı, failover modeli, listener, quorum, backup stratejisi ve disaster recovery tasarımı mevcut SQL Server ortamıyla birlikte değerlendirilmelidir.

Aryasoft olarak SQL Server ortamlarında mevcut mimariyi ve iş sürekliliği gereksinimlerini inceliyor; Availability Groups, Failover Cluster Instance, disaster recovery, backup & recovery ve Managed DBA süreçlerinde teknik destek sağlıyoruz.