SQL Server'da yüksek erişilebilirlik: Always On seçenekleri

Önce iki sayı: RPO ve RTO

RPO (Recovery Point Objective): kabul edilebilir veri kaybı. “En fazla 5 saniyelik işlem kaybolabilir” gibi.

RTO (Recovery Time Objective): kabul edilebilir kesinti süresi. “Hizmet 60 saniye içinde geri gelmeli” gibi.

Bu iki değer netleşmeden HA tartışması eksik kalır; her çözümün maliyeti ve karmaşıklığı bu hedeflere göre değerlendirilmelidir.

Failover Cluster Instance (FCI)

Paylaşımlı depolama üzerinde çalışan, örnek (instance) seviyesinde yük devretme. Bütün veritabanları birlikte taşınır; istemci aynı sanal ağ adına bağlanır.

• Artı: uygulama için şeffaf, örnek düzeyi nesneler (login, job, linked server) tek yerde.
• Eksi: paylaşımlı depolama tek arıza noktası olabilir; yük devretmede birkaç on saniyelik kesinti; okuma ölçekleme yok.
• Uygun: orta seviye RTO, düşük RPO; “bütün örnek tek parça taşınsın” ihtiyacı.

Always On Availability Groups (AG)

Veritabanı grubu düzeyinde replikasyon. Her replika kendi depolamasına sahiptir; senkron ya da asenkron kopyalama seçilebilir.

• Senkron + otomatik failover: düşük RPO (sıfıra yakın) ve düşük RTO; genelde 2–3 senkron replika ve bir quorum tanığı.
• Asenkron replika: uzak bölgeye felaket kurtarma; ağ gecikmesi birincil performansını etkilemez ama RPO > 0.
• Okunabilir ikincil: raporlama ve yedek alma yükünü birincilden alır.
• Listener: uygulama tek bir ada bağlanır; yönlendirme otomatik yapılır.
• Eksi: örnek düzeyi nesneler her replikada elle senkron tutulmalı; lisans ve işletim karmaşıklığı daha yüksek.

Log shipping ve yedek tabanlı DR

Belirli aralıklarla transaction log yedeğinin ikinci sunucuya taşınıp uygulanması. Basit, ucuz ve dayanıklıdır; ancak RPO yedek aralığı kadardır ve failover manueldir. Modern kurulumlarda genelde AG'nin asenkron replikasına ek bir güvenlik katmanı olarak konumlanır.

Karşılaştırma özeti

Çözüm	Tipik RPO	Tipik RTO	Okuma ölçekleme
FCI	≈ 0	15–60 sn	Hayır
AG (senkron, oto failover)	≈ 0	5–30 sn	Evet
AG (asenkron)	saniyeler–dakikalar	manuel: dakikalar	Evet
Log shipping	yedek aralığı	manuel: dakikalar–saat	Sınırlı

Değerler ortam ve yapılandırmaya göre değişir; kendi donanımınızda tatbikatla ölçmek şarttır.

HA, tatbikat edilmeden HA değildir

En sık gördüğümüz hata: kurulum yapılır, dokümante edilmez ve hiç denenmez. Öneriler:

• Planlı ve plansız failover senaryolarını en az çeyrekte bir çalıştırın; gerçek RTO'yu kaydedin.
• Uygulama tarafında bağlantı yeniden deneme, kısa timeout ve idempotent yazma olsun.
• Listener/DNS TTL, quorum yapılandırması ve tanık (witness) yerleşimini gözden geçirin.
• Runbook'u güncel tutun: kim, hangi komutu, hangi sırayla çalıştırıyor?

HA/DR mimarinizi birlikte tasarlayıp tatbikatlarla kanıtlayabiliriz — Yönetilen Veritabanı hizmetimize bakın.