Kısaca: SQL Server yüksek erişilebilirlik, veritabanı sunucusu arızalandığında hizmetin hazırda bekleyen ikinci bir kopyaya devredilerek ERP ve diğer uygulamaların kısa kesintiyle çalışmaya devam etmesini sağlar. KOBİ’ler için doğru çözüm; kabul edilebilir kesinti süresine, göze alınabilecek veri kaybına ve kullanılan SQL Server sürümüne göre seçilir. Standard sürümde tek veritabanı için temel kullanılabilirlik grubu, birden çok veritabanını birlikte korumak için Enterprise sürümde Always On kullanılabilirlik grupları, daha esnek hedeflerde ise log shipping öne çıkar.
Birçok KOBİ’de ERP, e-fatura entegrasyonu ve raporlama aynı SQL Server üzerinde çalışır. O sunucunun diski, anakartı veya işletim sistemi çöktüğünde sipariş girişi, sevkiyat ve faturalama birlikte durur. Yedek varsa veriler kurtarılır; ancak yeni sunucuyu hazırlayıp yedeği geri yüklemek saatler sürebilir. Yüksek erişilebilirlik bu bekleme süresini kısaltmak için kurulur.
SQL Server yüksek erişilebilirlik nedir?
SQL Server yüksek erişilebilirlik (high availability, HA; Microsoft belgelerinde “yüksek kullanılabilirlik”), bir veritabanı sunucusu veya örneği arızalandığında hizmetin önceden hazırlanmış ikinci bir sunucuya devredilmesini (failover) sağlayan mimaridir.
Yüksek erişilebilirlik ile yedekleme aynı şey değildir. HA, donanım veya sunucu arızasında hizmeti ayakta tutar; yanlışlıkla silinen bir kaydı ya da fidye yazılımının şifrelediği veriyi ise çoğu zaman ikinci kopyaya da taşır. Microsoft da SQL Server iş sürekliliği belgesinde kullanılabilirlik özelliklerinin sağlam ve test edilmiş bir yedekleme ve geri yükleme stratejisinin yerini tutmadığını vurguluyor. Bu nedenle HA planı, SQL veritabanı yedekleme stratejisinin üzerine kurulmalıdır.
Önce iki soruyu cevaplayın: Ne kadar kesinti, ne kadar veri kaybı?
Teknoloji seçmeden önce her veritabanı için iki hedefi yazılı hale getirin:
- RTO (Recovery Time Objective): Arızadan sonra sistemin en geç ne kadar sürede yeniden çalışması gerektiği.
- RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybının kabul edilebileceği.
ERP veritabanı için “birkaç dakika kesinti, veri kaybı yok” hedefi gerçekçi bir talep olabilir; aylık raporların tutulduğu bir arşiv veritabanı için ise birkaç saat kesinti sorun yaratmayabilir. Hedefleri iş birimleriyle birlikte belirleyin; tüm veritabanlarına en pahalı çözümü uygulamak bütçeyi gereksiz yere büyütür. Bu hedefler şirketin genel felaket kurtarma planı ile de uyumlu olmalıdır.
SQL Server yüksek erişilebilirlik seçenekleri: karşılaştırma
SQL Server’ın yerleşik seçenekleri ve sanallaştırma katmanındaki koruma aşağıdaki gibi karşılaştırılabilir. Sürüm bilgileri Microsoft’un SQL Server 2022 sürüm karşılaştırmasına dayanır:
| Çözüm | Neyi korur? | Devretme | Gereken altyapı | Sürüm | Dikkat edilecek nokta |
|---|---|---|---|---|---|
| Temel kullanılabilirlik grubu (Basic AG) | Tek veritabanı | Senkron modda otomatik veya elle | İki sunucu, Windows Server yük devretme kümesi (WSFC) veya Linux’ta Pacemaker | Standard | Yalnızca iki kopya; ikincil kopya okunamaz, üzerinde yedek alınamaz |
| Always On kullanılabilirlik grubu | Grup içindeki birden çok veritabanı | Otomatik veya elle, genellikle saniyeler içinde | Küme ve her kopya için ayrı depolama | Enterprise | Login, SQL Server Agent işleri ve bağlı sunucular ayrıca eşitlenmelidir |
| Yük devretme kümesi örneği (FCI) | Tüm SQL Server örneği: veritabanları, işler, login’ler | Otomatik; örnek diğer düğümde yeniden başlar | Küme ve ortak depolama | Standard, Enterprise | Ortak depolama tek arıza noktasıdır; kurtarma süresi AG’ye göre genellikle daha uzundur |
| Log shipping | Veritabanı bazında | Her zaman elle | İkinci sunucu, paylaşılan yedek klasörü, SQL Server Agent işleri | Enterprise, Standard, Web | Uygulamaların yeni sunucuya yönlendirilmesi ayrıca planlanmalıdır |
| Sanallaştırma katmanında HA | Sanal makinenin kendisi | Sanal makine başka fiziksel sunucuda yeniden başlar | Hipervizör kümesi ve ortak depolama | SQL Server sürümünden bağımsız | SQL Server servisindeki veya veritabanındaki sorunları tek başına çözmez |
Kullanılabilirlik gruplarında uygulamalar, birincil sunucunun adını bilmeden dinleyici (listener) adı üzerinden bağlanır; devretmeden sonra bağlantı yeni birincil sunucuya yönlenir. Log shipping’de böyle bir katman yoktur.
Hangi çözüm hangi KOBİ’ye uyar?
Tek ERP veritabanı ve Standard sürüm: Temel kullanılabilirlik grubu çoğu zaman en dengeli seçenektir. İkinci sunucu yalnızca bekler; raporlama için kullanılamaz ve yedekler birincil sunucudan alınır.
Birbirine bağlı birden çok veritabanı: ERP, entegrasyon ve web siparişi veritabanları birlikte çalışıyorsa Standard sürümde her biri için ayrı temel grup kurmanız gerekir ve bu gruplar ayrı ayrı devredilir. Veritabanlarının tek grupta birlikte taşınması önemliyse Enterprise sürümdeki Always On kullanılabilirlik grupları değerlendirilmelidir.
Raporları ana sunucudan ayırmak istiyorsanız: Okunabilir ikincil kopya yalnızca Enterprise sürümde vardır ve okunabilir kopyayı barındıran her sunucu için lisans gerekir.
Esnek hedefler, sınırlı bütçe: Son işlem günlüğü yedeğinden sonraki verinin kaybını ve elle geçişi kabul edebiliyorsanız log shipping basit ve sağlam bir seçenektir. İşlem günlüğü yedeklerinin geri yüklenmesini bilinçli olarak geciktirebildiğiniz için, örneğin WHERE koşulu unutulmuş bir UPDATE komutunun etkisinden de korunmanıza yardımcı olur.
Tüm örneğin korunması gerekiyorsa: Çok sayıda SQL Server Agent işi ve bağlı sunucu kullanan ortamlarda FCI bu nesneleri de birlikte taşır; ancak ortak depolamayı ayrıca korumanız gerekir.
Kurulumdan önce adım adım plan
- Veritabanlarını ve hedefleri listeleyin: Her veritabanının RTO ve RPO hedefini, hangi uygulamaların ona bağlandığını ve bakım pencerelerini yazın.
- Sürümü ve lisansı netleştirin: Mevcut sürümünüzün hangi seçenekleri desteklediğini ve ikinci sunucunun lisans durumunu lisans iş ortağınızla doğrulayın. Eski bir sürümdeyseniz önce SQL Server sürüm yükseltme planını ele alın.
- İkinci sunucuyu gerçekten ayrı kurun: İki kopya aynı fiziksel sunucuda veya aynı depolamada durursa tek bir arıza ikisini birden etkiler. Sürüm ve güncelleme düzeyleri aynı olmalı, aradaki ağ bağlantısı senkron çoğaltmayı taşıyabilmelidir.
- Kümeyi ve tanık (witness) yapılandırmasını kurun: İki düğümlü kümelerde dosya paylaşımı veya bulut tanığı, iki sunucunun aynı anda birincil olmaya çalışmasını önler.
- Uygulamaları dinleyiciye bağlayın: ERP, entegrasyon servisleri ve raporlama araçlarının bağlantı ayarlarında sunucu adı yerine dinleyici adını kullanın ve her birini test edin.
- Sunucu düzeyindeki nesneleri eşitleyin: Login’ler, SQL Server Agent işleri ve bağlı sunucular veritabanıyla birlikte taşınmaz. SQL Server 2022’deki kapsanan (contained) kullanılabilirlik grupları bu nesnelerin bir kısmını grup düzeyinde yönetmeyi sağlar.
- Yedekleme işlerini yeniden düzenleyin: Devretmeden sonra yedek işlerinin yeni birincil sunucuda da çalıştığını ve yedeklerin farklı bir konuma alındığını doğrulayın.
- Devretmeyi test edin ve belgeleyin: Planlı bir bakım saatinde elle devretme yapın, uygulamaların davranışını gözleyin ve adımları kısa bir çalışma talimatına yazın.
- İzlemeyi kurun: Senkronizasyon durumu, kopyalar arasındaki gecikme, küme olayları ve disk doluluğu için alarm tanımlayın.
Sık yapılan hatalar
- Yüksek erişilebilirlik kurulunca yedeklemeyi ikinci plana atmak.
- İki sanal sunucuyu aynı fiziksel sunucuda veya aynı depolamada çalıştırmak.
- Uygulamaları dinleyici yerine doğrudan sunucu adına bağlamak.
- Login’leri ve zamanlanmış işleri ikinci sunucuya taşımayı unutmak.
- Devretmeyi hiç denemeden canlıya almak; ilk test gerçek arızada yapılmış olur.
Mevcut sunucu, depolama ve ağ yapınızın bu adımlara hazır olup olmadığını görmek için BT altyapı denetimi iyi bir başlangıç noktasıdır.
Özet ve kontrol listesi
- Her veritabanı için RTO ve RPO hedefi yazıldı.
- Sürüm ve lisans durumu doğrulandı; Standard ile Enterprise farkı netleşti.
- İkinci sunucu ayrı fiziksel donanımda ve ayrı depolamada.
- Uygulamalar dinleyici adıyla bağlanıyor.
- Login’ler, işler ve bağlı sunucular eşitlendi.
- Yedekleme devretmeden sonra da çalışıyor ve geri yükleme test edildi.
- Devretme testi yapıldı, çalışma talimatı ve izleme hazır.
Doğru kurulan SQL Server yüksek erişilebilirlik çözümü, tek bir sunucu arızasını saatlerce süren bir duruştan kısa bir kesintiye dönüştürür. ÇAP Teknoloji, SQL danışmanlığı kapsamında veritabanlarınızın hedeflerini birlikte belirler, sürümünüze ve bütçenize uygun mimariyi tasarlar ve devretme testlerini sizinle birlikte yürütür. Bizimle iletişime geçin.
Sıkça Sorulan Sorular
Yüksek erişilebilirlik yedeklemenin yerini tutar mı?
Hayır. Yüksek erişilebilirlik donanım veya sunucu arızasında hizmeti ayakta tutar; yanlışlıkla silinen ya da şifrelenen veri ise genellikle ikinci kopyaya da yansır. Düzenli yedek ve geri yükleme testi her durumda gereklidir.
SQL Server Standard sürümle yüksek erişilebilirlik kurulabilir mi?
Evet. Standard sürümde tek veritabanını iki sunucu arasında koruyan temel kullanılabilirlik grubu, yük devretme kümesi örneği (FCI) ve log shipping kullanılabilir. Birden çok veritabanını tek grupta korumak ve okunabilir ikincil kopya için Enterprise sürüm gerekir.
Always On kullanılabilirlik grubu ile failover cluster arasındaki fark nedir?
Kullanılabilirlik grubu veritabanlarını ayrı depolamadaki kopyalara çoğaltır ve uygulamalar dinleyici adıyla bağlanır. Failover cluster ise tüm SQL Server örneğini ortak depolama üzerinden diğer düğümde yeniden başlatır; ortak depolama tek arıza noktası olarak kalır.
Yük devretme ne kadar sürer?
Microsoft’a göre kullanılabilirlik gruplarında devretme genellikle saniyeler içinde gerçekleşir; failover cluster’da örneğin yeniden başlaması ve kurtarma süreci nedeniyle süre genellikle daha uzundur. Log shipping’de geçiş elle yapılır. Gerçek süreyi kendi ortamınızda test ederek ölçün.
