Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisinin kurulumunu inceliyoruz.

Yazı dizisi beş bölümden oluşuyor:

Bölüm 1 – Windows Server Failover Cluster (WSFC) Kurulumu 
Bölüm 2 – Microsoft SQL Server 2025 Kurulumu
Bölüm 3 – SQL Server 2025 Bileşenleri Rehberi (Bu Yazı)
Bölüm 4 – Always On Ön Hazırlık ve Servis Ayarları
Bölüm 5 – Availability Group Kurulumu ve Failover Testi

Bölüm 2‘deki SQL Server 2025 kurulumunda Feature Selection ekranında pek çok bileşen ile karşılaştık. Always On Availability Group için yalnızca Database Engine Services ve SQL Server Replication bileşenlerini seçmiştik.

Ancak Feature Selection ekranında bunların dışında birçok bileşen daha bulunur. Bu yazıda, kurulum ekranında karşınıza çıkan tüm bileşenlerin ne işe yaradığını, hangi senaryolarda kullanıldığını, nasıl çalıştığını ve Always On ile ilişkisini derinlemesine ele alacağız. Her bileşen için mümkün olduğunda gerçek hayattan bir kullanım senaryosu, ilgili T-SQL doğrulama sorguları ve güvenlik/performans açısından dikkat edilmesi gereken noktaları da paylaşacağız.

Bu yazı bir referans (sözlük) niteliğindedir; ihtiyaç duyduğunuzda ilgili bileşene dönüp bakabilirsiniz.

Bileşenlere Genel Bakış

SQL Server kurulumunda karşımıza çıkan bileşenler mimari olarak iki ana grupta toplanır. Bu ayrım yalnızca kurulum ekranında nerede göründükleriyle ilgili değildir; bileşenin nasıl lisanslandığını, nasıl yamalandığını (patch) ve birden fazla instance kurulduğunda nasıl davrandığını da belirler.

• Instance Features: Belirli bir SQL Server instance’ına bağlı çalışan, o instance’a özel bileşenlerdir (Database Engine, Analysis Services vb.). Aynı sunucuya iki farklı instance kurarsanız, her birinin kendi Database Engine kopyası olur; biri yeniden başlatıldığında diğeri etkilenmez.
• Shared Features: Sunucu üzerindeki tüm instance’lar tarafından ortak kullanılan, instance’tan bağımsız bileşenlerdir (Integration Services, yönetim araçları vb.). Sunucuda kaç instance olursa olsun tek bir kopya kurulur ve hepsi tarafından paylaşılır.

Bu ayrımın Always On açısından pratik bir sonucu vardır: Always On yalnızca Database Engine düzeyinde çalışan bir yüksek erişilebilirlik teknolojisidir. Shared Features (SSIS gibi) veya ayrı instance’lar olarak çalışan Analysis Services, Always On Availability Group tarafından korunmaz. Bu bileşenlerin yüksek erişilebilirliği için ayrı stratejiler (WSFC üzerinde ayrı rol, yük dengeleme, yedekli kurulum vb.) gerekir.

Kurulu Bileşenleri Nasıl Görürüm?

Bir sunucuda hangi SQL Server bileşenlerinin kurulu olduğunu görmek için en pratik yöntem, SQL Server Installation Center üzerindeki Discovery Report taracını çalıştırmaktır. Bu rapor, o sunucudaki tüm instance’ları ve kurulu özellikleri (sürüm, edisyon, clustered/standalone bilgisi dahil) tek bir HTML sayfasında listeler.

SQL Server Installation Center açıyoruz. Sol menüden Tools bölümüne geçiyoruz. Tools ekranında Installed SQL Server features discovery report seçeneğine tıklıyoruz. Bu işlem, arka planda kurulum motorunu çalıştırarak sunucudaki tüm SQL Server ürün ve bileşenlerini tarar.

Tarama tamamlandığında, kurulu tüm bileşenleri, sürüm ve edisyon bilgileriyle birlikte gösteren bir rapor açılır. Bu rapor %ProgramFiles%\Microsoft SQL Server\<sürüm>\Setup Bootstrap\Log\ dizinine SqlDiscoveryReport.htm adıyla da kaydedilir.

Alternatif olarak, bir T-SQL oturumundan mevcut instance hakkında hızlı bilgi almak için:

Alternatif olarak, bir T-SQL oturumundan mevcut instance hakkında hızlı bilgi almak için:

SELECT SERVERPROPERTY('MachineName') AS Sunucu, 
SERVERPROPERTY('InstanceName') AS Instance, 
SERVERPROPERTY('ProductVersion') AS Surum, 
SERVERPROPERTY('Edition') AS Edisyon, 
SERVERPROPERTY('IsHadrEnabled') AS AlwaysOn_Aktif;

Instance Adı NULL Dönüyorsa

Yukarıdaki sorguyu çalıştırdığınızda InstanceName sütununun NULL döndüğünü görebilirsiniz. Bu bir hata değildir: SQL Server’ın default instance (varsayılan örnek) olarak kurulduğu anlamına gelir. SERVERPROPERTY('InstanceName') yalnızca named instance’larda (örneğin SQLEXPRESS>) bir değer döndürür; default instance’ta ise NULL döner.

Default instance’ın gerçek servis adı MSSQLSERVER‘dır. Her iki durumda da anlamlı bir sonuç almak için sorguya ISNULL ekleyebilirsiniz:

SELECT
    SERVERPROPERTY('MachineName')       AS Sunucu,
    ISNULL(CAST(SERVERPROPERTY('InstanceName') AS nvarchar(128)), 'MSSQLSERVER') AS Instance,
    @@SERVERNAME                        AS TamAd,
    SERVERPROPERTY('ProductVersion')    AS Surum,
    SERVERPROPERTY('Edition')           AS Edisyon,
    SERVERPROPERTY('IsHadrEnabled')     AS AlwaysOn_Aktif;

• ISNULL(..., 'MSSQLSERVER') ifadesi, default instance için gerçek servis adı olan MSSQLSERVER değerini döndürür.
• @@SERVERNAME default instance’ta yalnızca makine adını, named instance’ta ise MAKINE\INSTANCE formatını verir.

Database Engine Services

SQL Server’ın çekirdek bileşenidir ve kurulumda seçilmesi zorunludur. Veritabanlarının oluşturulması, yönetilmesi ve çalıştırılmasından sorumludur. Yazının geri kalanında anlatılan tüm bileşenler ya bu motorun üzerine kurulur ya da onunla konuşur; Database Engine olmadan hiçbiri anlam ifade etmez.

Sorumlu olduğu temel işlevler:

• Sorgu işleme ve transaction yönetimi
• Kilitleme (locking) ve eşzamanlılık kontrolü (concurrency)
• Loglama, güvenlik ve yetkilendirme
• Backup ve restore işlemleri
• Yüksek erişilebilirlik mekanizmaları (Failover Cluster, Always On)

Always On ile İlişkisi Neden Bu Kadar Temel?

Always On Availability Group, aslında Database Engine’in transaction log kayıtlarını bir replikadan diğerine göndermesi prensibine dayanır. Birincil replikada (primary) bir işlem gerçekleştiğinde, o işlemin log kayıtları ikincil replikalara (secondary) aktarılır ve orada yeniden uygulanır (redo). Bu mekanizmanın tamamı Database Engine içindeki şu bileşenler tarafından yürütülür:

• Log Capture / Log Send: Birincil replikada log kayıtlarını yakalayıp ağ üzerinden gönderen iş parçacıkları
• Log Receive / Redo: İkincil replikada gelen logları alıp veritabanına uygulayan iş parçacıkları
• Database Mirroring Endpoint: Replikalar arası iletişimin gerçekleştiği, varsayılan olarak TCP 5022 portunu kullanan uç nokta

Yani “Always On kuruyoruz” dediğimizde, aslında Database Engine’in halihazırda sahip olduğu bu yetenekleri yapılandırıyoruz. Bu nedenle Feature Selection ekranında Always On diye ayrı bir kutucuk yoktur çünkü o, Database Engine’in bir özelliğidir, ayrı bir bileşen değildir.

SQL Server Replication

Seçilen veritabanı, tablo veya nesnelerin farklı SQL Server instance’larına çoğaltılmasını sağlayan teknolojidir. Raporlama sunucuları, uzak lokasyon senaryoları, yük dengeleme ve dağıtık veri mimarilerinde kullanılır.

Replikasyonun Always On’dan en temel farkı granülerliktir: Always On bir veritabanının tamamını bir bütün olarak korurken, Replication tek tek tabloları, hatta bir tablonun belirli sütunlarını veya satırlarını (filtered replication) hedefe taşıyabilir. Bu esneklik, onu farklı bir problem sınıfının çözümü yapar.

Replikasyon Türleri

• Snapshot Replication: Verinin belirli bir andaki tam kopyasını (anlık görüntü) hedefe aktarır. Küçük ve seyrek değişen veri kümeleri için uygundur. Örneğin günde bir kez güncellenen bir ürün kataloğu veya döviz kuru tablosu için idealdir; her senkronizasyonda verinin tamamı yeniden yazılır.
• Transactional Replication: Kaynak veritabanındaki değişiklikleri (INSERT, UPDATE, DELETE) neredeyse gerçek zamanlı olarak hedefe aktarır. Yüksek tutarlılık gerektiren senaryolarda kullanılır. Klasik kullanım örneği, üretim (OLTP) veritabanı üzerindeki raporlama yükünü ayrı bir sunucuya taşımaktır: raporlar replikadan çalışır, ana sunucu yalnızca işlem yüküyle ilgilenir.
• Merge Replication: Hem kaynak hem de hedef tarafında yapılan değişikliklerin çift yönlü olarak birleştirilmesini sağlar. Bağlantının kesintili olduğu, çevrimdışı çalışılan senaryolar için uygundur. Örneğin sahada tablet ile çalışan satış ekiplerinin verileri, cihaz internete bağlandığında merkez veritabanıyla çift yönlü birleştirilir. Çakışma çözümleme (conflict resolution) mekanizması bu türe özgüdür.

Gerçek Hayat Senaryosu

Bir e-ticaret şirketini düşünün. Sipariş ve stok işlemleri Always On ile korunan bir OLTP veritabanında tutuluyor. Ancak yöneticiler, ağır raporlama sorgularının bu kritik veritabanını yavaşlatmasını istemiyor. Çözüm: sipariş tablolarını Transactional Replication ile ayrı bir raporlama sunucusuna kopyalamak. Böylece Always On veritabanın erişilebilirliğini, Replication ise raporlama yükünün ayrıştırılmasını sağlar. İki teknoloji birbirinin rakibi değil, tamamlayıcısıdır.

Machine Learning Services (In-Database)

SQL Server içerisinde Python ve R dillerini çalıştırarak, veritabanı motoru üzerinde doğrudan makine öğrenmesi ve istatistiksel analiz yapılmasını sağlar. Buradaki kilit fikir, veriyi modele değil, modeli veriye götürmektir: veri, SQL Server dışına (örneğin ayrı bir Python sunucusuna) hiç çıkarılmadan, motorun içinde analiz edilir.

Kullanım senaryoları:

• Öngörücü modelleme (predictive modeling) örneğin müşteri kaybı (churn) tahmini
• İstatistiksel analiz ve veri bilimi çalışmaları
• Veritabanı içinde model eğitimi ve skorlama (in-database scoring)

Python, günümüzde veri bilimi ve makine öğrenmesi alanında en yaygın kullanılan dillerden biridir. R ise istatistiksel hesaplama ve grafik üretimi için geliştirilmiş, akademik ve analitik çevrelerde tercih edilen bir dildir.

Neden Veriyi Dışarı Çıkarmamak Önemli?

Büyük veri kümelerinde, milyonlarca satırı bir uygulama sunucusuna çekip orada işlemek hem ağ bant genişliğini tüketir hem de veri güvenliği açısından risk oluşturur (veri, korunan sınırın dışına çıkar). Machine Learning Services, skorlama işlemini verinin bulunduğu yerde yaptığı için bu iki sorunu da ortadan kaldırır. Örneğin bir bankada kredi risk skoru, müşteri verisi hiç veritabanından çıkmadan hesaplanabilir bu, veri yönetişimi (data governance) açısından ciddi bir avantajdır.

Bu bileşeni kullanmak için kurulumdan sonra sp_configure ile harici script çalıştırmanın etkinleştirilmesi gerekir:

EXEC sp_configure 'external scripts enabled', 1;
RECONFIGURE;

Full-Text and Semantic Extractions for Search

Metin tabanlı verilerde gelişmiş arama yapılmasını sağlayan bileşendir. Standart LIKE sorgularının ötesinde, dil bilgisel analiz ve anlamsal arama yetenekleri sunar.

LIKE '%kelime%' ile yapılan aramaların iki büyük sorunu vardır: index kullanamadıkları için büyük tablolarda çok yavaştırlar ve dilbilgisinden habersizdirler (“koştu”, “koşuyor”, “koşmak” kelimelerini birbiriyle ilişkilendiremezler). Full-Text Search bu iki sorunu da çözer.

Full-Text Search: Büyük metin alanlarında kelime ve ifade bazlı hızlı arama sağlar. Kelime kökü analizi (stemming), eş anlamlı kelime desteği (thesaurus) ve yakınlık aramaları (proximity search) yapılabilir. Örneğin CONTAINS operatörüyle “veritabanı” ararken, arka planda kelimenin çekimli hallerini de kapsayacak biçimde sorgulanabilir:

SELECT baslik, icerik
FROM Makaleler
WHERE CONTAINS(icerik, 'FORMSOF(INFLECTIONAL, "kurulum")');

Semantic Search: Belgeler arasındaki anlamsal benzerlikleri tespit eder. Örneğin bir belge kütüphanesinde benzer içerikli dokümanların bulunması veya CV/özgeçmiş havuzunda benzer profillerin eşleştirilmesi gibi senaryolarda kullanılır. Full-Text “hangi belgede bu kelime geçiyor” sorusunu yanıtlarken, Semantic Search “hangi belgeler birbirine konu olarak benziyor” sorusunu yanıtlar.

PolyBase Query Service for External Data

PolyBase, SQL Server’ın harici veri kaynaklarına T-SQL ile erişmesini sağlayan bileşendir. Farklı platformlardaki verileri, sanki yerel bir tablodaymış gibi sorgulama imkanı sunar. Buradaki temel yaklaşım Data Virtualization‘dır: veriyi kopyalamadan (ETL yapmadan), bulunduğu yerde sorgulamak.

Erişilebilen harici kaynaklar:

• Hadoop (HDFS)
• Azure Blob Storage
• Azure Data Lake
• Diğer SQL Server, Oracle, Teradata, MongoDB gibi kaynaklar

Sağladığı avantajlar:

• Veriyi taşımadan (ETL yapmadan) yerinde sorgulama
• Farklı kaynaklardaki verileri tek bir T-SQL sorgusunda birleştirme
• Büyük veri (Big Data) platformlarıyla entegrasyon

Gerçek Hayat Senaryosu

Bir lojistik firması, geçmiş sensör verilerini maliyet nedeniyle bir Azure Blob Storage’da parquet dosyaları olarak saklıyor; güncel operasyonel verilerse SQL Server’da. Analistlerin “bu ayki teslimatları geçen yılın aynı ayıyla karşılaştır” sorusunu yanıtlamak için normalde iki ayrı sistemden veri çekip birleştirmek gerekir. PolyBase ile analist, Blob Storage’daki eski veriyi harici tablo (external table) olarak tanımlar ve tek bir JOIN sorgusuyla iki kaynağı birleştirir veriyi hiç taşımadan.

Harici tablo, yerel tabloyla aynı sorguda birleştirilebilir

SELECT g.SiparisNo, g.Tutar, e.EskiTeslimatSuresi
FROM GuncelSiparisler AS g
JOIN dbo.ArsivTeslimatlar_External AS e
    ON g.MusteriID = e.MusteriID;

Analysis Services (SSAS)

Kurumsal iş zekası (Business Intelligence) ve çok boyutlu analiz çözümüdür. Büyük veri kümeleri üzerinde hızlı analitik sorgular çalıştırmak için tasarlanmıştır. Burada kritik nokta şudur: SSAS, Database Engine’den ayrı bir instance olarak kurulur ve çalışır. Yani teknik olarak “SQL Server” başlığı altında olsa da, kendi servisine, kendi bellek yönetimine ve kendi yedekleme mantığına sahip bağımsız bir üründür.

Sunduğu modeller:

• Multidimensional (OLAP): Klasik küp (cube) tabanlı analiz modeli. Önceden hesaplanmış toplulaştırmalarla (pre-aggregated) çok büyük veri kümelerinde bile milisaniyeler içinde yanıt verir.
• Tabular: Bellek içi (in-memory) tablo tabanlı modern analiz modeli. Power BI’ın da altında yatan VertiPaq motorunu kullanır; geliştirmesi daha kolaydır ve çoğu modern senaryo için önerilir.

Kullanım senaryoları:

• Çok boyutlu raporlama ve analiz (satışları ürün × bölge × zaman kırılımında anında görmek)
• Öngörücü modelleme ve veri madenciliği
• Kar-zarar analizleri, satış trendleri, bütçe/gerçekleşme karşılaştırmaları

OLAP ve OLTP Farkı

Database Engine bir OLTP (Online Transaction Processing) sistemidir: çok sayıda küçük, hızlı işlemi (bir sipariş eklemek, bir stok güncellemek) yönetmek için optimize edilmiştir. SSAS ise bir OLAP (Online Analytical Processing) sistemidir: az sayıda ama devasa, çok boyutlu sorguyu (üç yıllık satışın bölgesel dağılımı) hızlıca yanıtlamak için optimize edilmiştir. İkisi farklı problemleri çözer; bu yüzden ayrı motorlardır.

Integration Services (SSIS)

SQL Server Integration Services (SSIS), veri entegrasyonu ve ETL (Extract, Transform, Load) işlemleri için kullanılan platformdur. Farklı kaynaklardan veri çekme, dönüştürme ve hedefe yükleme süreçlerini yönetir.

Temel yetenekleri:

• Farklı kaynaklardan (Excel, CSV, XML, diğer veritabanları) veri okuma
• Veri temizleme, dönüştürme ve zenginleştirme
• Zamanlanmış veri aktarım işleri (data pipeline)
• Veri ambarı (Data Warehouse) yükleme süreçleri

Gerçek Hayat Senaryosu

Bir perakende zinciri, her gece 200 mağazadan gelen satış dosyalarını (kimi Excel, kimi CSV) merkezi veri ambarına yüklemek istiyor. SSIS ile kurulan bir paket (package): dosyaları klasörden okur, tarih formatlarını standartlaştırır, hatalı satırları ayıklayıp bir hata tablosuna yazar, geçerli satırları ambara yükler ve işlem bittiğinde bir e-posta raporu gönderir. Bu paket, SQL Server Agent ile her gece 02:00’de otomatik tetiklenir. Bu tür tekrar eden, çok kaynaklı veri akışları SSIS’in klasik kullanım alanıdır.

Scale Out Mimarisi

SSIS, büyük ölçekli ETL iş yüklerini dağıtmak için Scale Out mimarisini destekler:

• Scale Out Master: İş yükünü koordine eden ve dağıtan ana bileşen
• Scale Out Worker: İşleri fiilen çalıştıran işçi düğümler

Bu yapı sayesinde büyük ETL işleri birden fazla sunucuya dağıtılarak paralel çalıştırılabilir; tek bir sunucunun kapasitesiyle sınırlı kalmazsınız.

Reporting Services (SSRS)

SQL Server Reporting Services (SSRS), kurumsal raporlama çözümüdür. Veritabanındaki verileri kullanarak tablo, grafik ve pano (dashboard) biçiminde raporlar oluşturur, yayınlar ve yönetir.

Sağladığı imkanlar:

• Sayfalanmış (paginated) raporlar oluşturma, özellikle yazdırılmaya uygun, sabit düzenli raporlar (fatura, bordro, resmi form)
• Web tabanlı rapor portalı üzerinden yayınlama
• Zamanlanmış rapor üretimi ve e-posta ile dağıtım (subscription)
• Farklı formatlarda dışa aktarma (PDF, Excel, Word)

SSRS’in güçlü olduğu alan, Power BI’ın aksine piksel-hassas, sayfalanmış raporlardır. Bir faturanın her sayfada aynı düzende görünmesi, alt toplamların doğru yerde çıkması gereken senaryolarda hala tercih edilir.

Önemli: SSRS Artık Ayrı Kurulur

SQL Server 2016 sürümünden itibaren SSRS (SQL Server Reporting Services), SQL Server ana kurulum paketinden ayrılmıştır. Reporting Services kullanmak istiyorsanız Microsoft’un resmi sitesinden ayrı bir kurulum paketi (Microsoft SQL Server Reporting Services) olarak indirip kurmanız gerekir. Bu yüzden Feature Selection ekranında artık bir SSRS kutucuğu göremezsiniz. Aynı ayrılma durumu SQL Server Management Studio (SSMS) için de geçerlidir.

Management Tools (Yönetim Araçları)

SQL Server’ı yönetmek için kullanılan araçlar da artık ana kurulum paketinden ayrı olarak dağıtılmaktadır:

• SQL Server Management Studio (SSMS): SQL Server’ı yönetmek için kullanılan temel grafik arayüzlü araçtır. Ayrı olarak indirilip kurulur. Availability Group oluşturma, izleme ve failover işlemlerinin büyük kısmını bu arayüzden yapacağız.
• Azure Data Studio: Çapraz platform (Windows, macOS, Linux) çalışabilen, modern ve hafif bir veritabanı yönetim aracıdır. Notebook desteği ve eklenti mimarisiyle özellikle geliştiriciler arasında yaygındır.

Kurulum yazıları:

• SQL Server Management Studio 22 kurulumu için: Microsoft SQL Server Management Studio 22 Kurulumu
• SQL Server Management Studio 22 Çevrimdışı (Offline) Kurulumu için: SQL Server Management Studio 22 Çevrimdışı (Offline) Kurulumu
• SQL Server Management Studio 22 Sessiz Kurulum (Silent Install) ile Dağıtmak için: SQL Server Management Studio 22 Sessiz Kurulum (Silent Install) ile Dağıtmak
• SQL Server Management Studio 22.8.x Güncellemesi için: SQL Server Management Studio 22.8.x Güncellemesi

Hangi Bileşenleri Kurmalıyım?

Karar verirken şu ilkeyi izleyin: İhtiyaç duymadığınız hiçbir bileşeni kurmayın. Bu yalnızca bir düzen tercihi değil, temel bir güvenlik ve işletme prensibidir.

Neden “Az Bileşen” Bir Güvenlik Prensibidir?

Kurduğunuz her bileşen, sistemde çalışan yeni bir servis, dinlenen yeni bir port veya yürütülen yeni bir kod yolu demektir. Bunların her biri:

• Saldırı yüzeyini genişletir: Kullanmadığınız PolyBase’in Data Movement servisi bile, açık kaldığında potansiyel bir hedeftir.
• Yama yükü getirir: Her bileşen ayrı güvenlik güncellemeleri alır. Kurduğunuz ama kullanmadığınız bir bileşen, yamasız kaldığında bilinen bir zafiyeti barındırmaya devam eder.
• Kaynak tüketir: Her servis CPU, RAM ve bazen disk G/Ç tüketir; bu, asıl iş yükünüzden (Always On veritabanınız) çalınan kaynaktır.
• Karmaşıklığı artırır: Sorun giderme sırasında incelenecek her ek bileşen, kök neden analizini zorlaştırır.

Kurulum Sonrası Hızlı Doğrulama

Bileşen tercihlerinizi yaptıktan ve kurulumu tamamladıktan sonra, instance’ın beklediğiniz gibi yapılandığını tek bir sorgu ile doğrulayabilirsiniz:

Instance genel durumu

SELECT
    SERVERPROPERTY('MachineName')     AS Sunucu,
    SERVERPROPERTY('InstanceName')    AS Instance,
    SERVERPROPERTY('ProductVersion')  AS Surum,
    SERVERPROPERTY('Edition')         AS Edisyon,
    SERVERPROPERTY('IsHadrEnabled')   AS AlwaysOn_Aktif;

Kurulu servisleri işletim sistemi tarafından görmek için PowerShell’den:

Get-Service | Where-Object { $_.DisplayName -like "*SQL*" } |
    Select-Object DisplayName, Status, StartType

Bu iki kontrol, hem hangi bileşenlerin fiilen çalıştığını hem de Always On’a geçişe hazır olup olmadığınızı hızlıca gösterir.

Sonuç

Bu yazıda SQL Server 2025 Feature Selection ekranında karşımıza çıkan tüm bileşenleri; ne işe yaradıklarını, hangi gerçek senaryolarda kullanıldıklarını ve Always On ile ilişkilerini inceledik. Temel çıkarım nettir: Always On Availability Group mimarisi için yalnızca Database Engine Services bileşeni zorunludur. Diğer bileşenler güçlü yeteneklere sahiptir, ancak yalnızca gerçek bir ihtiyaç karşılığında kurulmalıdır, aksi halde güvenlik, performans ve bakım açısından bedel öderiz.

Bir başka önemli nokta da şudur: Analysis Services gibi ayrı instance olarak çalışan veya SSIS gibi Shared Feature olan bileşenler, Always On Availability Group tarafından doğrudan korunmaz; bunların yüksek erişilebilirliği ayrı planlanmalıdır. Buna karşılık Full-Text catalog, SSISDB ve SSRS veritabanları gibi Database Engine üzerinde duran yapılar, ilgili veritabanı Always On’a alındığında birlikte korunabilir.

Bir sonraki yazımızda, Always On mimarisine geçmeden önce SQL Server servisleri üzerinde yapılması gereken kritik ön hazırlıkları Enable Always On Availability Groups ayarını, servis hesaplarını ve protokol yapılandırmalarını ele alacağız.

Bölüm 4 – Always On Ön Hazırlık ve Servis Ayarları

Bir sonraki yazımızda görüşmek dileğiyle…