SQL Server Always On Nedir? Availability Group ve Failover Cluster Instance Rehberi

“Always On” tek bir özellik değil. Microsoft bu adı iki farklı teknolojinin ortak çatısı olarak kullanıyor: veritabanlarının kopyasını başka sunucularda tutarak koruyan Always On availability groups (AG) ve SQL Server instance’ını bütünüyle cluster node’ları arasında taşıyan Always On failover cluster instance (FCI). İkisi de bir sunucu çöktüğünde uygulamanın çalışmaya devam etmesini sağlar; ancak failover’ı farklı yapar, farklı şeyleri korur ve farklı şekillerde sorun çıkarırlar.

Bu rehberde bir availability group’un veriyi nasıl taşıdığını, commit modlarını ve failover türlerini, listener ile read-only routing’i, secondary replica üzerinde yedeklemeyi, AG’nin sizin yerinize kopyalamadığı nesneleri, FCI’nin çalışma mantığını, SQL Server 2025’te sürüm ve lisans sınırlarını ve bir replica’nın failover’a gerçekten hazır olup olmadığını gösteren sorguları ele alıyoruz. Yüksek erişilebilirlik seçenekleri arasında henüz karar vermediyseniz önce SQL Server high availability rehberimize bakmanızı öneririz. Bu yazı doğrudan Always On’un içine giriyor.

Son doğrulama: 19 Ekim 2026. Microsoft Learn’deki availability group genel bakışı, availability mode’ları, failover ve failover mode’ları, flexible failover policy, veritabanı seviyesinde sağlık algılama, okunabilir secondary’ler, secondary’de backup, basic/contained/distributed availability group’lar, failover cluster instance’lar ve SQL Server 2025 sürümleri sayfalarına karşı kontrol edildi.

Hangisine İhtiyacınız Var? Hızlı Karar Tablosu

Bir Bakışta Availability Group ve FCI

Availability group veritabanı seviyesinde çalışır. Bir grup kullanıcı veritabanı, primary replica’dan secondary replica’ya birlikte geçer. Her replica kendi depolamasına ve verinin kendi kopyasına sahip ayrı bir SQL Server instance’ıdır; primary, transaction log kayıtlarını secondary’lere gönderir.

Failover cluster instance ise instance seviyesinde çalışır. Paylaşımlı depolamada verinin tek bir kopyası ve aynı anda yalnızca bir cluster node’unda çalışan tek bir SQL Server instance’ı vardır. O node çöktüğünde Windows Server Failover Clustering (WSFC) instance’ı başka bir node’da başlatır ve instance kendisine ait her şeyle birlikte geri gelir: sistem veritabanları, login’ler, Agent job’ları, linked server’lar ve sertifikalar.

İkisi birlikte de kullanılabilir: bir FCI, availability group’ta replica olabilir. Sık görülen bir tasarım, lokal yüksek erişilebilirlik için FCI’yi, felaket kurtarma için ise başka bir veri merkezindeki asenkron AG replica’sını kullanır.

Availability Group Veriyi Nasıl Taşır?

Veri akışını anlamak, canlı ortamda karşılaşacağınız AG belirtilerinin neredeyse tamamını açıklar.

1. Primary’deki bir transaction log kaydı üretir. Commit edildiğinde log bloğu primary’nin transaction log dosyasına yazılır.
2. Aynı log bloğu database mirroring endpoint’i (varsayılan TCP 5022) üzerinden her secondary replica’ya gönderilir.
3. Her secondary bloğu kendi log dosyasına yazar (“harden” eder) ve primary’ye onay döner.
4. Secondary’deki redo thread’i log kayıtlarını veri dosyalarına uygular ve secondary’deki kopya güncellenir.

Bu akıştan iki kuyruk çıkar ve bunlar herhangi bir AG’deki en önemli iki sayıdır:

• Log send queue: primary’de olup henüz secondary’ye ulaşmamış log. Primary şu an kaybolursa kaybedeceğiniz veri budur; gerçek RPO‘nuzu ölçer.
• Redo queue: secondary’nin yazdığı ama henüz uygulamadığı log. Failover’da veritabanlarının açılabilmesi için secondary’nin önce redo’yu bitirmesi gerekir; gerçek RTO‘nuzu belirler.

Send queue’su sıfıra yakın ama redo queue’su birkaç gigabayt olan bir secondary veri kaybettirmez; ancak ona failover etmek saniyeler yerine dakikalar sürebilir.

Senkron ve Asenkron Commit

Her replica’nın bir availability mode’u vardır.

Senkron commit‘te primary, uygulamaya commit onayını vermeden önce secondary’nin log bloğunu diske yazmasını bekler. Commit edilen transaction’lar iki replica’da da bulunur; bu yüzden SYNCHRONIZED durumdaki bir secondary’ye failover hiçbir şey kaybettirmez. Bedeli gecikmedir: her commit bir ağ gidiş-dönüşü ve secondary’de bir log yazması kadar uzar. Bunu primary’de HADR_SYNC_COMMIT bekleme türü olarak görürsünüz.

Asenkron commit‘te primary kendi log yazması biter bitmez commit eder ve log’u secondary’ye arka planda gönderir. Commit’ler mesafeden bağımsız olarak hızlıdır; ama primary kaybolduğunda send queue’da kalan her şey kaybolur.

SQL Server 2017 ile gelen REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ayarı, primary’yi her commit’te belirtilen sayıda senkron secondary’nin log’u yazmasını beklemeye zorlar. Secondary’ler düştükten sonra primary’nin tek başına commit etmeye devam etmesi açığını kapatır.

Failover Türleri

Bir AG’de roller üç şekilde değişebilir ve sonuçları birbirinden çok farklıdır.

Planlı manuel failover her zaman yeni primary olacak secondary üzerinde çalıştırılır:

-- Hedef secondary üzerinde çalıştırın
ALTER AVAILABILITY GROUP [AG_Sales] FAILOVER;

-- Yalnızca felakette: hedefin almadığı her şeyin kaybını kabul eder
ALTER AVAILABILITY GROUP [AG_Sales] FORCE_FAILOVER_ALLOW_DATA_LOSS;

Bir AG’yi asla Failover Cluster Manager’da cluster rolünü taşıyarak failover etmeyin. T-SQL, SSMS ya da PowerShell kullanın; böylece SQL Server geçişten önce senkronizasyon durumunu kontrol eder. Aynı kural yama sırasında da geçerlidir; bunu Always On ortamlarında rolling update rehberimizde anlatıyoruz.

Otomatik failover’ı ne tetikler?

Otomatik failover her hatada tetiklenmez. Kararı üç ayar verir:

• Lease timeout (varsayılan 20 saniye): SQL Server ile cluster resource DLL’i lease’i yenileyemezse replica sağlıksız kabul edilir.
• HEALTH_CHECK_TIMEOUT (varsayılan 30.000 ms): cluster’ın sp_server_diagnostics yanıtını ne kadar bekleyeceği.
• FAILURE_CONDITION_LEVEL (varsayılan 3): hangi durumların arıza sayılacağı; “servis kapalı” (1) seviyesinden “orta düzey sunucu hataları” (5) seviyesine kadar. Seviye 3, orphaned spinlock ve write access violation gibi kritik sunucu hatalarını kapsar.

Veritabanı seviyesinde sağlık algılama (DB_FAILOVER = ON, SQL Server 2016’dan itibaren) bir tetikleyici daha ekler: gruptaki bir veritabanı, örneğin bir veri dosyasının kaybı nedeniyle online olmaktan çıkarsa failover başlar. Varsayılan olarak kapalıdır ve yeni AG’lerin çoğunda açmaya değer. SQL Server 2025’te ayrıca AG kaynağının RestartThreshold değerini 0 yapabilirsiniz; böylece cluster kalıcı bir sağlık sorununda kaynağı önce aynı node’da yeniden başlatmayı denemeden hemen failover eder.

Listener ve Read-Only Routing

Uygulamalar hiçbir zaman bir replica’nın instance adına bağlanmamalı. Availability group listener, her subnet için kendi IP adresi olan ve her zaman mevcut primary’yi gösteren sanal bir ağ adıdır.

Uygulamaların bir failover’ı ne kadar iyi atlatacağını connection string’deki üç ayar belirler:

• MultiSubnetFailover=True: istemci listener IP’lerini sırayla değil, paralel dener. Tek subnet’te bile tüm modern sürücülerde kullanın; yeniden bağlanma süresini kısaltır.
• ApplicationIntent=ReadOnly: listener’a bu oturumun yalnızca okuma yapacağını bildirir; böylece oturum okunabilir bir secondary’ye yönlendirilebilir.
• Yeniden deneme (retry) mantığı: her failover’da o an açık olan transaction’lar hata alır. Uygulamanın yeniden bağlanıp işlemi tekrar denemesi gerekir.

Okunabilir secondary’ler

Enterprise sürümde bir secondary salt okunur bağlantı kabul edebilir (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)). Bir routing listesi tanımlandığında, ApplicationIntent=ReadOnly bildirip listener üzerinden bağlanan oturumlar otomatik olarak bir secondary’ye gönderilir.

Raporları secondary’ye taşımak faydalıdır, ancak yan etkileri vardır:

• Secondary’deki sorgular, hangi izolasyon seviyesini isterse istesin snapshot isolation altında çalışır. Satır versiyonları secondary’nin tempdb’sinde tutulur.
• Okunabilir secondary’yi açmak, row versioning için primary’de değişen satırlara 14 bayt ekler.
• Secondary’de uzun süren raporlar primary’deki ghost cleanup’ı geciktirebilir ve secondary’nin tempdb’sini büyütebilir.
• Secondary’de oluşturulan istatistikler eskiden geçiciydi ve yeniden başlatmada kayboluyordu. SQL Server 2025, okunabilir secondary’ler için kalıcı istatistik getiriyor; secondary replica’lar için Query Store da artık varsayılan olarak açık.
• Okunabilir secondary pasif replica değildir; tam olarak lisanslanması gerekir.

Raporlama tarafındaki ödünleşimleri ve lisans hesabını raporlama sunucusu eklemenin maliyeti yazımızda ele alıyoruz.

Secondary Replica Üzerinde Yedekleme

Yedeklemeyi primary’den almak, AG’nin en pratik faydalarından biridir.

• SQL Server 2022’ye kadar: secondary’ler copy-only full backup ve normal log backup’ı destekler. Differential backup yalnızca primary’de alınabilir.
• SQL Server 2025: copy-only backup’a ek olarak artık herhangi bir secondary replica üzerinde full ve differential backup da alınabiliyor.
• Hangi replica’da alınırsa alınsın log backup’lar tek bir log zinciri oluşturur. Restore için nerede alındıklarından bağımsız olarak hepsine ihtiyaç vardır.
• Secondary SYNCHRONIZED ya da SYNCHRONIZING durumda olmalıdır. Geride kalan bir asenkron secondary’de alınan yedek, ancak o secondary kadar günceldir.

AG’nin AUTOMATED_BACKUP_PREFERENCE ayarı (PRIMARY, SECONDARY_ONLY, SECONDARY veya NONE) ve backup priority değerleri yalnızca bir tercihi ifade eder. Yedek job’larınız her replica’da çalışmalı ve tercih edilen replica’da olup olmadıklarını SQL Server’a sormalıdır:

IF sys.fn_hadr_backup_is_preferred_replica(N'SalesDB') = 1
BEGIN
    BACKUP LOG [SalesDB]
    TO DISK = N'\\backupshare\sql\SalesDB\SalesDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
END

Yedekleme tarafı için SQL Server backup planı rehberimize göz atabilirsiniz.

Availability Group’un Kopyalamadıkları

AG yalnızca gruptaki kullanıcı veritabanlarını çoğaltır, başka hiçbir şeyi değil. master ve msdb’de tutulan her şey oluşturulduğu instance’ta kalır. Failover’dan sonra “uygulama eski primary’de çalışıyordu ama yenisinde çalışmıyor” durumunun olağan sebepleri şunlardır:

• Login’ler: SQL login’leri her replica’da aynı SID ile bulunmalıdır; aksi halde failover’dan sonra veritabanı kullanıcıları orphaned olur. Login’leri CREATE LOGIN ... WITH SID = ... ile oluşturun.
• SQL Server Agent job’ları, operator’lar ve alert’ler. Her job’ın ayrıca primary’de çalışıp çalışmadığını kontrol etmesi gerekir; örneğin sys.fn_hadr_is_primary_replica ile.
• Linked server’lar, credential’lar ve proxy’ler.
• Sertifikalar ve anahtarlar: TDE ile şifrelenmiş bir veritabanı, sertifikası olmayan bir replica’da açılamaz.
• Instance ayarları: max server memory, MAXDOP, cost threshold, trace flag’ler ve Database Mail.
• SSISDB’deki SSIS paketleri (SSISDB’nin kendisi gruba dahil değilse).

-- Agent job adımında: secondary'de hiçbir şey yapma
IF sys.fn_hadr_is_primary_replica(N'SalesDB') <> 1
    RETURN;

-- Replica'lar arasında login ve SID karşılaştırması
SELECT name, sid, type_desc, is_disabled
FROM sys.server_principals
WHERE type IN ('S', 'U', 'G')
  AND name NOT LIKE '##%'
ORDER BY name;

Contained availability group‘lar (SQL Server 2022 ve sonrası, Enterprise sürüm) bu sorunların çoğunu çözer. Contained AG’nin kendisiyle birlikte failover eden ayrı bir master ve msdb’si vardır; listener üzerinden oluşturulan login’ler, yetkiler ve Agent job’ları grupla birlikte taşınır. SQL Server 2025 ayrıca iki contained AG arasında distributed AG kurulmasına izin veriyor.

Diğer Availability Group Topolojileri

• Distributed availability group (2016+): her biri kendi cluster’ında çalışan iki AG’den oluşan bir AG. Tek bir cluster’ı lokasyonlar arasına germeden bölgeler arası DR için ve kısa geçiş penceresiyle yeni donanıma ya da yeni sürüme taşınmak için kullanılır.
• Read-scale / cluster’sız AG (CLUSTER_TYPE = NONE, 2017+): cluster yok, otomatik failover yok. Okuma ölçekleme ve migration için uygundur, yüksek erişilebilirlik için değil.
• Linux üzerinde SQL Server: AG’ler WSFC yerine Pacemaker ile yönetilir (CLUSTER_TYPE = EXTERNAL).
• Basic availability group: Standard sürümdeki varyant; aşağıdaki sürüm bölümünde anlatılıyor.

Failover Cluster Instance Nasıl Çalışır?

FCI, cluster rolü olarak kurulmuş tek bir SQL Server instance’ıdır. Veri ve log dosyaları her node’un erişebildiği depolamada durur: SAN, Storage Spaces Direct, cluster shared volume’lar veya SMB 3 dosya paylaşımı. tempdb her node’un hızlı lokal diskinde olabilir.

Aktif node çöktüğünde cluster rolü durdurur, depolamayı ve ağ adını taşır ve SQL Server’ı başka bir node’da başlatır. Bu bir servis başlatma olduğu için her veritabanı crash recovery’den geçer: commit edilmiş transaction’lar ileri sarılır, commit edilmemişler geri alınır. Bu nedenle failover süresini recovery süresi belirler ve uzun süredir açık transaction’lar bu süreyi uzatır. Accelerated database recovery bu süreyi belirgin şekilde kısaltır.

FCI’nin güçlü yanı, depolamanın üstündeki her şeyde sadeliktir. Senkron tutulacak login, AG’ye uyumlu hale getirilecek job, ayrıca lisanslanacak ya da farklı yamalanacak ikinci bir kopya yoktur. Koruyamadığı şey ise depolama arızası ve bozulmadır: verinin tek bir kopyası vardır. Bu yüzden kritik FCI’ler genellikle ayrı depolamada duran bir AG replica’sı, log shipping ya da yedekleme stratejisiyle birlikte kullanılır.

Quorum: Tasarımların En Çok Yanıldığı Yer

Windows üzerindeki AG’ler de FCI’ler de WSFC quorum’una bağlıdır. Cluster, oyların çoğunluğu birbirini görebildiği sürece çalışır. Bu, bölünmüş bir cluster’ın iki yarısının da primary’nin kendisinde olduğunu düşündüğü split brain durumunu engeller.

• Tek sayıda oy kullanın; node sayısı çiftse bir witness ekleyin (disk, file share veya cloud witness).
• Dynamic quorum ve dynamic witness (Windows Server 2012 R2 ve sonrası), node’lar düştükçe oyları ayarlar ve cluster’ın ardışık arızalarda ayakta kalmasını sağlar.
• DR lokasyonundaki node’lara genellikle NodeWeight = 0 verilir; böylece bir WAN kesintisi üretim lokasyonundaki cluster’ı düşüremez.
• Witness, node’lardan biriyle aynı odada değil; üçüncü bir lokasyonda ya da cloud witness olarak Azure’da durmalıdır.

Klasik hata, iki lokasyonlu bir cluster’da primary lokasyonun kısa bir WAN aksaklığında oy çoğunluğunu kaybetmesi ve sağlıklı primary dahil tüm cluster’ın offline olmasıdır. Bu tuzağı asenkron database mirroring ile asenkron availability group karşılaştırmasında ayrıntılı anlatıyoruz.

SQL Server 2025’te Sürümlere Göre Always On

Standard sürümdeki bir sunucu, her biri tek veritabanlı birden fazla basic AG barındırabilir; ancak bunlar birbirinden bağımsız failover eder. Bir uygulama birlikte kalması gereken üç veritabanı kullanıyorsa basic AG bunu garanti edemez; FCI ya da Enterprise sürüm daha doğru seçim olabilir. Express sürüm ne AG’yi ne de FCI’yi destekler.

Always On Lisanslaması

Software Assurance veya abonelik lisanslamasıyla SQL Server 2025, failover için ücretsiz pasif replica hakkı verir: bir yüksek erişilebilirlik, bir felaket kurtarma ve bir de Azure’da DR için. Pasif replica üzerinde yalnızca veritabanı tutarlılık kontrolleri, log backup, full backup ve kaynak izleme yapılabilir.

Bir secondary okuma, rapor ya da başka bir üretim işi üstlendiği anda pasif olmaktan çıkar ve primary ile aynı sürümde kendi lisansına ihtiyaç duyar. Dolayısıyla raporlama için kullanılan okunabilir bir secondary, ikinci bir primary kadar lisans maliyeti getirir. Kuralları ve çekirdek hesabını SQL Server 2025 lisanslama rehberimizde anlatıyoruz.

İzleme: Secondary Gerçekten Hazır mı?

SSMS’teki yeşil bir pano kanıt değildir. Şu an failover yapsanız her veritabanı ve replica için ne kadar veri kaybedeceğinizi ve recovery’nin ne kadar süreceğini görmek için bu sorguyu primary’de çalıştırın:

SELECT
    ag.name                              AS ag_name,
    ar.replica_server_name,
    ar.availability_mode_desc,
    DB_NAME(drs.database_id)             AS database_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size              AS log_send_queue_kb,
    drs.redo_queue_size                  AS redo_queue_kb,
    drs.redo_rate                        AS redo_kb_per_sec,
    drs.last_commit_time,
    drs.is_suspended,
    drs.suspend_reason_desc
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups   AS ag ON ag.group_id   = drs.group_id
ORDER BY ag.name, ar.replica_server_name, database_name;

Alarm üretilmesi gereken durumlar:

• Senkron bir replica’da SYNCHRONIZED olmayan ya da herhangi bir yerde suspended durumdaki her veritabanı.
• Sürekli büyüyen bir log send queue. Asenkron DR replica’larında bu, veri kaybı riskinizdir.
• Redo queue’nun redo rate’e bölümünün RTO hedefinizi aşması.
• Primary ve secondary’deki last_commit_time arasındaki fark; yani saniye cinsinden gecikme.
• Cluster olayları: quorum kaybı, düşen node, SQL Server error log’daki lease timeout’lar.
• Bir secondary yetişemediği için AG veritabanlarının transaction log’unun büyümesi. Log, herhangi bir replica’nın hâlâ ihtiyaç duyduğu noktanın ötesine truncate edilemez.

Failover’ı yalnızca canlıya geçişte değil, düzenli olarak test edin. Her çeyrekte yapılan ve diğer taraftaki login’lerin, job’ların ve linked server’ların çalıştığını da doğrulayan bir failover tatbikatı, secondary’nin kullanılabilir olduğunu bilmenin tek güvenilir yoludur.

Always On’da Sık Yapılan Hatalar

• AG’yi yedek yerine koymak ve restore testlerini atlamak.
• Yüksek gecikmeli bir WAN üzerinden senkron commit kullanıp her insert’in neden yavaşladığını merak etmek.
• Uygulamaların listener yerine instance adlarına ya da MultiSubnetFailover ve retry mantığı olmadan bağlanması.
• Her replica’da farklı SID’li login’ler; ilk failover’da kullanıcıların orphaned kalması.
• Her replica’da ya da yalnızca ilk primary’de çalışan Agent job’ları.
• Witness’sız iki node’lu bir cluster ya da node’lardan biriyle aynı lokasyondaki bir witness.
• Yama sırasında AG rolünü Failover Cluster Manager’dan taşımak.
• Raporlar için okunabilir secondary’yi lisanslamadan kullanmak.
• Redo queue’yu hiç ölçmemek ve “senkronize” bir failover’ın on dakika sürmesi.
• Veritabanları birlikte failover etmesi gereken bir uygulama için basic AG seçmek.

Always On Kontrol Listesi

• Her uygulama için RPO ve RTO iş birimleriyle mutabık kalınarak belirlendi.
• Doğru koruma seviyesi için AG veya FCI seçildi; DR ayrıca planlandı.
• Senkron replica’lar düşük gecikmeli ağda, DR replica’ları asenkron.
• Quorum, witness konumu ve node ağırlıkları dokümante edildi.
• Listener kullanılıyor; uygulamada MultiSubnetFailover ve retry mantığı var.
• Login’ler (aynı SID’lerle), job’lar, linked server’lar, sertifikalar ve instance ayarları her replica’da mevcut.
• Agent job’ları primary’de çalışıp çalışmadığını kontrol ediyor.
• Yedek job’ları her replica’da çalışıyor ve backup tercihine uyuyor; restore’lar test ediliyor.
• Send queue, redo queue, senkronizasyon durumu ve gecikme alarmlarla izleniyor.
• Failover, uygulama tarafı dahil düzenli olarak test ediliyor.
• Lisanslama, her secondary’nin gerçek kullanımını yansıtıyor.

Sürüm ve Edisyon Notları

Resmi Davranış, Aryasoft Saha Notları ve Bizim Önerimiz

Kaynaklar (Microsoft Learn)

Bu rehberdeki teknik iddialar 19 Ekim 2026 tarihinde aşağıdaki birincil kaynaklara karşı kontrol edildi. Microsoft dokümantasyonu her an değişebilir; üretimde değişiklik yapmadan önce sürüme özel ayrıntıları yeniden doğrulayın.

• What is an Always On availability group? (İngilizce)
• Always On failover cluster instances (İngilizce)
• Availability modes (İngilizce)
• Failover and failover modes (İngilizce)
• Flexible automatic failover policy (İngilizce)
• Database-level health detection (İngilizce)
• Readable secondary replicas (İngilizce)
• Backups on secondary replicas (İngilizce)
• Basic availability groups (İngilizce)
• Contained availability groups (İngilizce)
• Distributed availability groups (İngilizce)
• Editions and supported features of SQL Server 2025 (İngilizce)