SQL SERVER ALWAYS ON NEDİR? YÜKSEK ERİŞİLEBİLİRLİK TEMELLERİ VE TASARIM NOTLARI

Üretim ortamlarında “veritabanı kesintisi” çoğu zaman tek bir teknik sorun değil, zincirleme bir iş etkisidir: sipariş akışı durur, raporlar gecikir, entegrasyonlar kuyrukta birikir. Bu yüzden SQL Server tarafında yüksek erişilebilirlik yaklaşımı, sadece “failover çalışsın” hedefinden ibaret değildir; tasarım, test ve operasyon disiplininin birleşimidir.

SQL Server Always On, doğru kurgulandığında planlı bakım pencerelerini kısaltır, arıza anında servis sürekliliğini artırır ve felaket kurtarma senaryolarını daha öngörülebilir hale getirir. Ancak yanlış beklentiyle kurulduğunda “karmaşık ama kırılgan” bir yapıya dönüşebilir. Bu yazıda Always On’un temel kavramlarını, mimari seçeneklerini ve pratik tasarım notlarını adım adım ele alacağız.

Odak noktamız; Availability Group (AG) ve Failover Cluster Instance (FCI) gibi yapıların nerede konumlandığı, RPO/RTO hedeflerine göre hangi kararların alındığı ve işletim sırasında en sık kaçırılan kontrollerin neler olduğudur.

SQL Server Always On kavramı ve temel bileşenleri

“Always On” ifadesi pratikte iki ana teknolojiyi kapsar: Failover Cluster Instance (FCI) ve Always On Availability Groups (AG). İkisi de yüksek erişilebilirlik hedefler, fakat çalışma mantıkları ve korudukları kapsam farklıdır. FCI daha çok “instance seviyesinde” süreklilik sağlarken, AG veritabanı seviyesinde çoğaltma ve failover sunar.

AG mimarisinde her veritabanı, birincil replikadan ikincil replikaya sürekli olarak log bazlı şekilde taşınır. Bu sayede aynı anda birden fazla ikincil replika ile okuma ölçekleme, raporlama veya DR senaryoları mümkün olur. Yine de burada kritik nokta, AG’nin bir “mucize kutu” değil; ağ, disk, güvenlik ve işletim pratikleriyle birlikte değerlendirilmesi gereken bir platform olmasıdır.

FCI mi AG mi: Doğru aracı seçmek

FCI, paylaşımlı depolama (SAN/Storage Spaces Direct gibi) üstünde instance’ı taşıyarak çalışır. Uygulama tarafında bağlantı çoğunlukla tek bir ağ ismi üzerinden devam eder. AG ise her replikanın kendi depolamasına sahip olduğu, verinin replikalar arasında taşındığı bir modeldir. Seçim yaparken şu soruları netleştirmek gerekir:

• Kesinti toleransı nedir, hedeflenen RTO kaç dakikadır?
• Veri kaybı toleransı nedir, hedeflenen RPO sıfır mı, saniyeler mi?
• Okuma ölçekleme ihtiyacı var mı, raporlama yükü nereye taşınacak?
• Depolama mimarisi paylaşımlı mı, yerel disk + replikasyon mu?

WSFC rolü: Kalp atışı, quorum ve karar mekanizması

Always On’un omurgası çoğu senaryoda Windows Server Failover Clustering (WSFC) bileşenidir. WSFC, düğümlerin sağlığını izler, “kim birincil olacak” kararını quorum üzerinden verir ve failover tetiklediğinde rol değişimini yönetir. Tasarım aşamasında quorum modeli ve tanık (witness) seçimi, beklenmedik “split brain” riskini azaltan en kritik kararlardan biridir.

RPO/RTO odaklı mimari tasarım kararları

Always On tasarımına başlamadan önce, “ne zaman, ne kadar kayıp kabul edilebilir” sorusu yanıtlanmalıdır. RPO (Recovery Point Objective) veri kaybı toleransını, RTO (Recovery Time Objective) ise servis geri dönüş süresini tanımlar. Bu hedefler net değilse, senkron/asenkron seçiminden network kapasitesine kadar birçok karar havada kalır.

Senkron ve asenkron commit: Performans ile güven arasında denge

Synchronous commit modunda birincil replika, ikincil replikadan onay almadan commit’i tamamlamaz. Bu, doğru yapılandırıldığında veri kaybını minimize eder; fakat gecikme (latency) arttığında uygulama performansı etkilenebilir. Asynchronous commit ise daha gevşek bir model sunar; commit birincilde tamamlanır, loglar arkadan taşınır. Bu yaklaşım özellikle uzak veri merkezi (DR) için kullanılır, ancak arıza anında veri kaybı ihtimali vardır.

Quorum ve witness seçimi: Dayanıklılık ve sürpriz kesinti riskleri

İki düğümlü senaryolarda tanık (file share witness veya cloud witness) çoğu zaman şarttır. Amaç, ağ bölünmesi gibi durumlarda kümenin “çoğunluğu kimde” sorusuna doğru cevap verebilmesidir. Witness konumunu seçerken şu pratikler faydalıdır:

1. Witness’ı mümkünse üçüncü bir hata alanına yerleştirmek
2. Tanığın erişilebilirliğini ve DNS/SMB bağımlılıklarını test etmek
3. Güvenlik tarafında minimum yetki prensibiyle paylaşımları yönetmek

Availability Group mimarisi: Replika tipleri ve trafik akışları

Availability Group içinde replikalar “primary” ve “secondary” olarak konumlanır. Secondary replika okuma için kullanılabilir (readable secondary), yedekleme tercihleri (backup preference) belirlenebilir ve failover modları (automatic/manual) tanımlanabilir. Burada amaç, sadece süreklilik değil; aynı zamanda yük dağıtımı ve operasyonel sadeleşme sağlamaktır.

Listener tasarımı: Uygulama bağlantı stratejisi

AG Listener, uygulamalar için tek bir bağlantı noktası sağlar. Failover olduğunda listener IP/hostname üzerinden yeni primary replika yönlendirilir. Tasarım notları:

• Listener adı, DNS ve IP planı ile birlikte ele alınmalı
• Port standardizasyonu yapılmalı, güvenlik duvarı kuralları önceden tanımlanmalı
• Uygulama connection string içinde MultiSubnetFailover gibi seçenekler senaryoya göre değerlendirilmeli

Read-only routing: Raporlama ve sorgu yükünü ikincile taşımak

Okuma ölçekleme hedefleniyorsa read-only routing kurallarıyla belirli bağlantıların ikincil replikalara yönlenmesi sağlanabilir. Bu sayede raporlama, dashboard veya analitik sorgular primary üzerinde baskı oluşturmaz. Ancak burada “hangi sorgu hangi replika” ayrımı kadar, indeks ve istatistik bakımının replika davranışlarıyla uyumu da önemlidir.

Kurulum ön koşulları ve adım adım kurgu

Kurulum adımlarının sırası ve bağımlılıkları çoğu zaman hataların kaynağıdır. Yetki eksikliği, endpoint uyuşmazlığı, backup/restore hazırlığı veya yanlış recovery model gibi basit sebepler günlerce vakit kaybettirebilir. Bu yüzden kurulumdan önce bir kontrol listesi oluşturmak iyi bir pratiktir.

Ön kontroller: Altyapı, hesaplar ve güvenlik

AG kurulumu için sık karşılaşılan ön koşullar:

• Düğümler arası saat senkronizasyonu ve DNS çözümlemesi
• SQL Server servis hesaplarının endpoint ve cluster kaynaklarına erişimi
• Veritabanlarının FULL recovery model’de olması
• Gerekli portların (örn. mirroring endpoint portu) açık ve izlenebilir olması

Veritabanı hazırlığı: Tam yedek, log zinciri ve restore stratejisi

Secondary replika üzerinde veritabanları “RESTORING” modunda hazır beklemelidir. Bu, tam yedek + log yedekleri ile restore edilerek sağlanır. Log zinciri bozulursa (ör. yanlışlıkla SIMPLE’a geçmek) seed/join süreci sorun çıkarabilir. Kurulum öncesinde yedekleme politikasının AG sonrası nasıl işleyeceği de netleşmelidir.

Aşağıdaki örnek, bir AG için endpoint ve temel yapılandırma adımlarına dair sadeleştirilmiş bir çerçeve sunar. Ortamınıza göre isim, port ve yetkileri uyarlayın.

-- 1) Database prerequisites (primary)
ALTER DATABASE SalesDB SET RECOVERY FULL;
BACKUP DATABASE SalesDB TO DISK = 'D:\Backup\SalesDB_full.bak' WITH INIT, COMPRESSION;
BACKUP LOG SalesDB TO DISK = 'D:\Backup\SalesDB_log.trn' WITH INIT, COMPRESSION;

-- 2) Restore on secondary (run on secondary)
RESTORE DATABASE SalesDB FROM DISK = 'D:\Backup\SalesDB_full.bak' WITH NORECOVERY, REPLACE;
RESTORE LOG SalesDB FROM DISK = 'D:\Backup\SalesDB_log.trn' WITH NORECOVERY;

-- 3) Create a database mirroring endpoint (run on each replica)
CREATE ENDPOINT [Hadr_endpoint]
STATE = STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = REQUIRED ALGORITHM AES);

-- 4) Create Availability Group (primary)
CREATE AVAILABILITY GROUP [AG_Sales]
WITH (DB_FAILOVER = ON, DTC_SUPPORT = NONE)
FOR DATABASE [SalesDB]
REPLICA ON
N'SQLNODE01' WITH (
  ENDPOINT_URL = N'TCP://SQLNODE01.domain.local:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  SEEDING_MODE = AUTOMATIC,
  SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)
),
N'SQLNODE02' WITH (
  ENDPOINT_URL = N'TCP://SQLNODE02.domain.local:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  SEEDING_MODE = AUTOMATIC,
  SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)
);

-- 5) Join secondary to AG (secondary)
ALTER AVAILABILITY GROUP [AG_Sales] JOIN;
ALTER DATABASE [SalesDB] SET HADR AVAILABILITY GROUP = [AG_Sales];

Örnek senaryoda otomatik seeding seçilmiş olsa bile, büyük veritabanlarında ağ ve disk performansına göre geleneksel backup/restore yaklaşımı daha kontrollü olabilir. Ayrıca failover mode seçimini, gerçek RTO hedefi ve uygulama davranışıyla birlikte düşünmek gerekir.

Operasyonel tasarım notları: Bakım, yedekleme ve performans

Always On devreye alındıktan sonra en çok unutulan kısım “günlük işletim”tir. İndeks bakımı, istatistik güncellemeleri, yedekleme tercihleri, job’ların hangi replika üzerinde çalışacağı gibi konular net değilse, yüksek erişilebilirlik hedefi zamanla zayıflar.

Backup preference ve job yerleşimi

AG, yedeklerin hangi replika üzerinde alınacağını yönetmek için “backup preference” sunar. Buna rağmen SQL Agent job’larının koşul ifadeleriyle replika rolüne göre çalıştırılması çoğu ortamda hayat kurtarır. Örneğin yalnızca primary üzerinde çalışması gereken bakım işleri ile secondary üzerinde çalıştırılacak raporlama job’ları ayrıştırılmalıdır.

İndeks ve istatistik bakımında dikkat edilecek noktalar

Bakım penceresinde planlı failover yapılacaksa, bakım işlerinin “hangi düğümde ve hangi sırayla” çalışacağı tanımlanmalıdır. Bazı ekipler, yoğun bakım işlerini secondary üzerinde yapıp sonra kontrollü failover ile primary rolünü değiştirir. Bu yaklaşım, doğru test edilirse kullanıcı etkisini azaltabilir; ancak yanlış eş zamanlama durumunda beklenmedik kilitlenmelere yol açabilir.

Always On mimarisini daha derin ve pratik senaryolarla öğrenmek isterseniz SQL Server DBA Eğitimi sayfasına göz atabilirsiniz.

İzleme, test ve arıza senaryoları

AG kurulduktan sonra “çalışıyor gibi” görünmesi yeterli değildir. Failover testi yapılmamış bir Always On tasarımı, gerçek kesinti anında sürprizlerle dolu olabilir. Bu yüzden düzenli test, izleme ve kapasite değerlendirmesi operasyonun bir parçası olmalıdır.

Failover test planı: Kontrollü senaryolarla doğrulama

Test planında yalnızca “failover oldu” kontrolü değil, aşağıdaki maddeler de yer almalıdır:

• Uygulamanın yeniden bağlanma davranışı ve bağlantı havuzu tepkisi
• Listener DNS güncellemesi ve çoklu alt ağ senaryolarında süre
• Job’ların doğru replika üzerinde devreye girmesi
• RPO/RTO hedeflerinin ölçülmesi ve raporlanması

DMV sorguları ile sağlık kontrolü

Aşağıdaki DMV sorgusu, replikaların rolü, senkronizasyon durumu ve gecikmeye dair hızlı bir fotoğraf verir. Bu tip kontrolleri bir izleme paneline taşımak, alarm üretimini kolaylaştırır.

SELECT
  ag.name AS ag_name,
  ar.replica_server_name,
  rs.role_desc,
  rs.connected_state_desc,
  rs.synchronization_state_desc,
  rs.synchronization_health_desc,
  rs.last_connect_error_description,
  rs.last_connect_error_timestamp
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar
  ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states rs
  ON ar.replica_id = rs.replica_id
ORDER BY ag.name, ar.replica_server_name;

DMV çıktılarında “connected” ve “healthy” durumlarının yanı sıra, bağlantı hatalarının zaman damgaları ve açıklamaları da önemlidir. Sık tekrarlayan kısa kopmalar, ağ tarafında paket kaybı veya güvenlik duvarı zaman aşımı gibi sorunların habercisi olabilir.

Tasarımda sık yapılan hatalar ve pratik öneriler

Always On projelerinde hataların önemli kısmı teknik karmaşıklıktan değil, sınırların yanlış çizilmesinden doğar. Örneğin AG’nin “tek başına” felaket kurtarma çözümü olduğu varsayımı, uygulama katmanındaki bağımlılıkları gözden kaçırabilir. Aynı şekilde quorum/witness tasarımının ihmal edilmesi, küçük bir ağ sorununun büyük bir kesintiye dönüşmesine neden olabilir.

Pratik öneriler:

• RPO/RTO hedeflerini yazılı hale getirip tasarım kararlarını buna bağlamak
• İki düğümlü ortamlarda witness konumunu ve erişimini düzenli test etmek
• Listener ve connection string davranışını uygulama ekibiyle birlikte doğrulamak
• Bakım, yedekleme ve job’lar için “rol farkındalığı” olan standartlar belirlemek
• Failover tatbikatlarını takvime bağlayıp ölçümleri raporlamak

Özetle SQL Server Always On, yüksek erişilebilirlik hedefini destekleyen güçlü bir platformdur; ancak tasarım disiplini, operasyonel netlik ve düzenli test olmadan sürdürülebilir olmaz. Doğru kurgu ile hem planlı bakımlarda hem de beklenmeyen arızalarda daha öngörülebilir bir veritabanı servis sürekliliği elde edebilirsiniz.