Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisini detaylı şekilde kurulumu ve yapılandırmasını anlatıyor olacağız. inceleyecek, High Availability (Yüksek Erişebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları ele alacağız.

Daha önceki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 1

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını tamamlamıştık.

Daha sonraki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 2

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Microsoft SQL Server 2025 kurulum ve yapılandırma adımlarını başarıyla tamamlamıştık.

Daha sonraki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 3

W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2025 Always On Availability Group yapılandırması öncesinde, her iki sunucu üzerindeki Microsoft SQL Server 2025 servisleri için gerekli tüm ön yapılandırmaları başarıyla tamamladık.

Microsoft SQL Server 2025 SQL Always On Availability Group mimarisinin kurulum ve yapılandırma adımlarını, Availability Group oluşturma sürecini ve dikkat edilmesi gereken teknik noktaları detaylı olarak ele alıyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz ve karşımıza Connect ekranı geliyor.

Connect ekranında Connection Properties bölümü altında

Server Name bölümünde, bağlantı kurulacak W25SQL25NOD1 isimli sunucumuzun adını giriyoruz. Bu alan, istemci veya yönetim aracının hangi SQL Server instance’ına bağlanacağını belirler.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir. Windows Authentication, parola yönetimi ve merkezi güvenlik politikaları açısından SQL Authentication’a göre daha güvenli ve yönetilebilir bir yaklaşımdır.
Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz. Bu ayar genellikle LAB, TEST ortamlarında veya self-signed sertifika kullanılan senaryolarda tercih edilir. PROD ortamlarda ise güvenilir bir iç CA veya public CA tarafından üretilmiş sertifikalar kullanılması ve bu seçeneğin kapalı bırakılması önerilir.

Connect seçeneği ile W25SQL25NOD1 isimli sunucumuza bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda W25SQL25NOD1 isimli sunucumuza bağlantı sağlamış oluyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde Always On High Availability sekmesine tıkladığımızda, Microsoft SQL Server 2025 Always On Availability Group özelliğinin başarılı bir şekilde etkinleştirildiğini görüyoruz. Yapılan kontroller sırasında herhangi bir hata veya uyarı mesajı ile karşılaşılmaması, SQL Server servislerinin, Windows Server Failover Cluster (WSFC) entegrasyonunun ve Always On bileşenlerinin doğru şekilde yapılandırıldığını göstermektedir. Bu durum, sunucunun Availability Group (AG) yapısında güvenli ve sorunsuz bir şekilde çalışmaya hazır olduğunu teyit eder.

W25SQL25NOD2 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz ve karşımıza Connect ekranı geliyor.

Connect ekranında Connection Properties bölümü altında

Server Name bölümünde, bağlantı kurulacak W25SQL25NOD2 isimli sunucumuzun adını giriyoruz. Bu alan, istemci veya yönetim aracının hangi SQL Server instance’ına bağlanacağını belirler.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir. Windows Authentication, parola yönetimi ve merkezi güvenlik politikaları açısından SQL Authentication’a göre daha güvenli ve yönetilebilir bir yaklaşımdır.
Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz. Bu ayar genellikle LAB, TEST ortamlarında veya self-signed sertifika kullanılan senaryolarda tercih edilir. PROD ortamlarda ise güvenilir bir iç CA veya public CA tarafından üretilmiş sertifikalar kullanılması ve bu seçeneğin kapalı bırakılması önerilir.

Connect seçeneği ile W25SQL25NOD2 isimli sunucumuza bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda W25SQL25NOD1 isimli sunucumuza bağlantı sağlamış oluyoruz.

W25SQL25NOD2 isimli sunucumuz üzerinde Always On High Availability sekmesine tıkladığımızda, Microsoft SQL Server 2025 Always On Availability Group özelliğinin başarılı bir şekilde etkinleştirildiğini görüyoruz. Yapılan kontroller sırasında herhangi bir hata veya uyarı mesajı ile karşılaşılmaması, SQL Server servislerinin, Windows Server Failover Cluster (WSFC) entegrasyonunun ve Always On bileşenlerinin doğru şekilde yapılandırıldığını göstermektedir. Bu durum, sunucunun Availability Group (AG) yapısında güvenli ve sorunsuz bir şekilde çalışmaya hazır olduğunu teyit eder.

Microsoft SQL Server 2025 Always On Availability Group yapılandırmasına geçmeden önce, W25SQL25NOD1 isimli sunucumuz üzerinde en az bir adet Database (Veritabanı) oluşturulması gerekmektedir. Microsoft SQL Server 2025 Always On Availability Group yapısı, herhangi bir veritabanı olmadan yapılandırılamadığı için bu adım zorunludur.

Bu işlem için W25SQL25NOD1 isimli sunucuda Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz.

Databases bölümüne sağ tıklıyoruz ve New Database seçeneğini seçiyoruz ve Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilecek yeni Database (Veritabanı) oluşturuyoruz.

New Database ekranında General sekmesi altında yer alan Database name bölümünde, oluşturacağımız Database (Veritabanı) için bir Name (İsim) belirlememiz gerekmektedir. Bu adımda verilecek Database (Veritabanı) adı, Microsoft SQL Server 2025 Always On Availability Group yapısına eklenecek veritabanının kimliğini oluşturacağı için belirlenen isimlendirme standardına uygun ve anlaşılır olmalıdır.

New Database ekranında General sekmesi altında yer alan Database name bölümünde, BAKICUBUKDB isimli yeni bir Database (Veritabanı) oluşturuyoruz.

Database files bölümünde oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) ait Data (mdf / ndf) ve Transaction Log (ldf) dosyalarının

Logical Name (Mantıksal Ad): SQL Server içerisinde kullanılan dosya adıdır. Fiziksel dosya adından bağımsızdır ve veritabanı işlemlerinde referans olarak kullanılır.
File Type (Dosya Türü): Dosyanın türünü belirtir. ROWS Data (Veri) dosyası ve LOG Transaction Log (İşlem Günlüğü) dosyası
Filegroup (Dosya Grubu): Database (Veritabanı) veri dosyalarının ait olduğu mantıksal grubu ifade eder. Varsayılan olarak PRIMARY filegroup kullanılır.
Initial Size (MB) (Başlangıç Boyutu): Database (Veritabanı) dosyasının oluşturulurken ayrılan ilk disk alanını belirtir. Boyut MB cinsinden tanımlanır.
Autogrowth (Otomatik Büyüme): Dosya boyutu dolduğunda SQL Server’ın dosyayı otomatik olarak ne kadar büyüteceğini belirler. MB veya yüzde (%) bazlı yapılandırılabilir.
Path (Dosya Yolu): Database (Veritabanı) dosyasının disk üzerindeki fiziksel konumunu gösterir. Planlanan disk mimarisi ile uyumlu olması performans ve yönetilebilirlik açısından önemlidir.

gibi yapılandırma bilgilerini görüntülüyoruz. Bu bölüm, Database (Veritabanı) dosya yapısının planlanan disk mimarisi ile uyumlu olduğunun doğrulanması açısından önemlidir.

New Database ekranında General sekmesi altında yer alan Database files bölümünün Path alanında, BAKICUBUKDB isimli Database (Veritabanı) dosyalarının, Microsoft SQL Server 2025 kurulumu sırasında yapılandırmış olduğumuz dizinler üzerinde oluşturulacağını görüyoruz. Bu sayede Database (Veritabanı) dosyalarının planlanan disk mimarisi ile uyumlu şekilde konumlandırıldığı doğrulanmış olur.

Microsoft SQL Server 2025 Failover Cluster Instance (FCI) yapısında Data, Log, Temp ve Backup dizinleri Cluster Volume Diskler üzerinde tutulur ve bu diskler Cluster Node’ları arasında ortak olarak kullanılır.

Buna karşılık, Microsoft SQL Server 2025 Always On Availability Group mimarisinde Data, Log, Temp ve Backup dizinleri her bir sunucunun kendi yerel diskleri üzerinde tutulur. Bu yaklaşım, paylaşımlı disk ihtiyacını ortadan kaldırarak replikasyon tabanlı bir High Availability (Yüksek Erişebilirlik) ve Disaster Recovery (Felaket Kurtarma) mimarisi sunar.

New Database ekranında Options sekmesine geçtiğimizde, oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) için gerekli yapılandırma seçeneklerini görüyoruz.

New Database ekranında Options sekmesinde yer alan Recovery model bölümünün Full olması gerekmektedir. Microsoft SQL Server 2025 Always On Availability Group yapısı için bu ayarın bu şekilde yapılandırılması zorunludur.

New Database ekranında Options sekmesinde, Recovery model bölümünde Full, Simple ve Bulk-Logged olmak üzere üç farklı seçenek bulunmaktadır.

Simple Recovery: Simple Recovery Model kullanılan veritabanlarında, transaction log kayıtları checkpoint işleminden sonra otomatik olarak silinir. Bu nedenle Simple Recovery Model’de transaction log dosyalarının sürekli büyümesi söz konusu değildir. Ancak burada sıkça yanlış anlaşılan bir noktaya değinmek gerekir. Simple Recovery Model dâhil olmak üzere tüm recovery modellerinde transaction log tutulur. Simple Recovery Model’i diğerlerinden ayıran fark, transaction log kayıtlarının checkpoint sonrasında otomatik olarak temizlenmesidir. Simple Recovery Model’de log yönetimi kolaydır; ancak geriye dönük transaction log kayıtları silindiği için transaction log yedekleri alınamaz ve dolayısıyla nokta atışı restore işlemleri mümkün değildir. Bu durumda herhangi bir felaket senaryosunda veritabanı en iyi ihtimalle son alınan Full veya Differential backup’a kadar geri döndürülebilir. Bu nedenle veri kaybı riski yüksektir ve Simple Recovery Model production ortamlarında tercih edilmemelidir.

Full Recovery: Full Recovery Model kullanılan veritabanlarında gerçekleştirilen tüm işlemler transaction log dosyasına kaydedilir ve manuel olarak müdahale edilmedikçe silinmez. Bu sayede veritabanı belirli bir zamana veya belirli bir işlem öncesine kadar restore edilebilir. Full Recovery Model, Always On Availability Group mimarisi ile uyumlu ve en güvenilir recovery modelidir. Full Recovery Model’de transaction log yönetimi yöneticinin sorumluluğundadır. Bu nedenle transaction log dosyalarının kontrolsüz büyümemesi için belirli aralıklarla transaction log backup alınması gerekmektedir. Alternatif bir yöntem olarak transaction log dosyaları shrink edilebilir; ancak SQL Server 2005 ve sonrası sürümlerde shrink işlemi için veritabanının recovery modelinin geçici olarak Simple yapılması, işlem tamamlandıktan sonra tekrar Full olarak ayarlanması gerekir. Bu yöntem rutin kullanım için önerilmez. Full Recovery Model’de insert, delete ve update gibi DML işlemlerinin yanı sıra index oluşturma, rebuild işlemleri, bcp ve bulk insert gibi işlemler de transaction log dosyasına yazılır. Bu tür işlemler sırasında transaction log dosyaları hızlı büyüyebilir ve işlemler kısmen yavaşlayabilir.

Bulk-Logged Recovery: Bulk-Logged Recovery Model, Full Recovery Model’e benzer şekilde çalışır; ancak bulk işlemler sırasında her işlem için ayrı ayrı log kaydı oluşturmak yerine, işlem için tek bir toplu kayıt transaction log dosyasına yazılır. Bu sayede bulk işlemler Full Recovery Model’e kıyasla daha hızlı gerçekleştirilir. Ancak Bulk-Logged Recovery Model kullanıldığında, bulk işlem içeren bir zaman aralığına nokta atışı restore işlemi yapılamaz. Bu nedenle Bulk-Logged Recovery Model production ortamları için kalıcı bir çözüm değildir. En doğru kullanım senaryosu; bulk işlem öncesinde transaction log backup alınması, recovery modelinin geçici olarak Bulk-Logged yapılması, işlem tamamlandıktan sonra tekrar Full Recovery Model’e dönülmesidir. Bulk işlem olarak değerlendirilen bazı işlemler; index oluşturma ve rebuild, select into, bulk insert, bcp ile yapılan veri aktarımları ve büyük ölçekli delete işlemleridir.

New Database ekranında oluşturacağımız BAKICUBUKDB isimli Database (Veritabanı) için gerekli yapılandırmaları tamamladıktan sonra OK seçeneğine tıklayarak veritabanı oluşturma işlemini başlatıyoruz.

Not: Options sekmesinde yapılacak yapılandırmalar, oluşturulacak veritabanını kullanacak olan yazılım ve uygulamalara göre farklılık gösterebilir. Logo Tiger, Logo Bordro, Nebim, Mikro gibi ticari uygulamalar için üretici dokümantasyonları mutlaka dikkate alınmalıdır.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında, BAKICUBUKDB isimli Database (Veritabanı)’nin W25SQL25NOD1 isimli sunucumuz üzerinde başarıyla oluşturulduğunu görüyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolu üzerinde W25SQL25NOD1 isimli sunucuda oluşturmuş olduğumuz BAKICUBUKDB isimli Database (Veritabanı) için, Microsoft SQL Server 2025 Always On Availability Group yapılandırmasına geçmeden önce Full Backup alıyoruz.

Always On Availability Group yapılandırması öncesinde Full Backup alınmaması durumunda, Database (Veritabanı) Availability Group (AG)’a eklenemez ve yapılandırma sırasında Full backup is required hatası ile karşılaşılabilir. Bu nedenle Full Backup işlemi, Always On Availability Group yapılandırmasının zorunlu ve kritik bir ön koşuludur.

New Availability Group ekranında Select Databases adımına geldiğimizde, Select user databases for the availability group bölümü altında Status sütununda Full backup is required hatasını görüyoruz.

Bu hata, ilgili veritabanı için Always On Availability Group yapılandırmasına geçmeden önce Full Backup (Tam Yedek) alınmadığını ifade eder. Always On Availability Group mimarisinde bir Database (Veritabanı) Availability Group (AG)’a eklenebilmesi için, ilk senkronizasyonun sağlıklı şekilde başlatılabilmesi amacıyla mutlaka en az bir kez Full Backup alınmış olması gerekir.

Gerekli Full Backup işlemi tamamlandıktan sonra bu hata ortadan kalkacak ve Database (Veritabanı) Availability Group (AG) yapılandırması için seçilebilir duruma gelecektir.

BAKICUBUKDB isimli Database (Veritabanı) üzerinde sağ tuşa tıklıyoruz. Tasks menüsüne giriyoruz ve Back Up… seçeneğini seçiyoruz.

Bu adım ile Microsoft SQL Server 2025 Always On Availability Group yapılandırması öncesinde BAKICUBUKDB isimli Database (Veritabanı) üzerinde Full Backup (Tam Yedek) işlemini başlatmış oluyoruz.

Back Up Database – BAKICUBUKDB ekranında Backup Type bölümünü Full olarak seçiyoruz. Ardından Destination alanında Back up to seçeneğini Disk olarak belirliyoruz. Bu yapılandırma ile veritabanının Full Backup (Tam Yedek) disk üzerine alınacağını belirtmiş oluyoruz.

Destination bölümünde, yedekleme işleminin gerçekleştirileceği dizinin H:\BACKUP olarak yapılandırıldığını görüyoruz. Bu dizin, Microsoft SQL Server 2025 Always On Availability Group kurulumu sırasında daha önce belirlemiş olduğumuz varsayılan Backup klasörüdür.

Back Up Database – BAKICUBUKDB ekranında gerekli kontrolleri tamamladıktan sonra OK seçeneğine tıklayarak Full Backup (Tam Yedek) işlemini başlatıyoruz.

BAKICUBUKDB isimli Database (Veritabanı) üzerinde Full Backup (Tam Yedek) işleminin başarıyla tamamlandığını görüyoruz.

Full Backup (Tam Yedek) işlemin sorunsuz şekilde tamamlanmasının ardından OK seçeneğine tıklayarak Back Up Database – BAKICUBUKDB ekranını kapatıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolu üzerinde Always On High Availability bölümüne sağ tuş tıklıyoruz ve New Availability Group Wizard seçeneğini seçerek Availability Group oluşturma sihirbazını başlatıyoruz.

New Availability Group Wizard, Microsoft SQL Server üzerinde Always On Availability Group mimarisini oluşturmak ve yapılandırmak için kullanılan, SSMS (SQL Server Management Studio) içerisinde yer alan bir yapılandırma sihirbazıdır.

Bu sihirbaz, bir Availability Group oluşturma sürecini adım adım yönlendirerek; Primary ve Secondary replikaların tanımlanmasını, senkronizasyon ayarlarının yapılmasını ve gerekli bileşenlerin otomatik olarak yapılandırılmasını sağlar.

New Availability Group Wizard ile gerçekleştirilen temel işlemler şunlardır: Primary Replica olarak görev alacak SQL Server instance’ı belirlenir ve Availability Group’a eklenecek Secondary Replica’lar tanımlanır. Her bir replica için Synchronous (Senkron) veya Asynchronous (Asenkron) veri senkronizasyonu, Automatic Failover (Otomatik Yük Devretme) ya da Manual Failover (Manuel Yük Devretme) seçenekleri ve Read-only erişim ayarları yapılandırılır. Ayrıca istemci bağlantıları için Availability Group Listener oluşturulabilir ve veritabanlarının başlangıç senkronizasyon yöntemi Full, Join Only veya Skip Initial Data Synchronization olarak seçilebilir.

Sihirbaz, yapılandırma süreci boyunca Windows Server Failover Cluster (WSFC) durumunu ve Always On için gerekli ön gereksinimleri kontrol ederek olası yapılandırma hatalarının önceden tespit edilmesine yardımcı olur. Bu kontroller sayesinde Always On mimarisi, manuel yapılandırmaya kıyasla daha hızlı, tutarlı ve hatasız bir şekilde devreye alınabilir.

Introduction ekranında Microsoft SQL Server 2025 Always On Availability Group yapısının oluşturulması için gerekli olan genel bilgilendirme ve yapılandırma adımlarına ait özet bilgileri görüyoruz. Bu ekran, Availability Group oluşturma sürecinde izlenecek aşamaları ve dikkat edilmesi gereken temel gereksinimler To create an availability group, you will need to: başlığı altında sıralanmaktadır.

Specify an availability group name and other options: Bu adımda oluşturulacak Availability Group için benzersiz bir isim belirlenir. Ayrıca Automatic Failover (Otomatik Yük Devretme), Database Health Detection gibi Always On’a ait temel davranış seçenekleri yapılandırılır. Bu isim, mimarinin yönetimi ve izlenmesi açısından kritik öneme sahiptir.
Select one or more user databases on this instance of SQL Server: Availability Group’a dahil edilecek kullanıcı veritabanları bu aşamada seçilir. Seçilecek veritabanlarının Full Recovery Model’de olması ve daha önce Full Backup alınmış olması gerekir. Sistem veritabanları bu yapıya dahil edilemez.
Specify one or more instances of SQL Server to host secondary availability replicas: Primary replica’ya ek olarak, verilerin kopyalanacağı Secondary Replica’ların yer alacağı SQL Server instance’ları bu adımda belirlenir. Bu instance’lar aynı Windows Server Failover Cluster (WSFC) yapısına üye olmalıdır.
Specify your availability group listener preference: İstemci bağlantılarının hangi adres üzerinden yapılacağını belirleyen Availability Group Listener bu aşamada yapılandırılır. Listener, uygulamaların aktif olan Primary Replica’ya otomatik olarak yönlendirilmesini sağlar ve High Availability (Yüksek Erişilebilirlik) açısından kritik bir bileşendir.
Select your initial data synchronization preference: Primary ve Secondary replica’lar arasındaki ilk veri eşitleme yönteminin belirlendiği adımdır. Burada Full, Join Only veya Skip Initial Data Synchronization seçeneklerinden biri tercih edilir. Seçim, ortamın ağ yapısına, veritabanı boyutuna ve operasyonel tercihlere göre yapılır.
Check the validation results of availability group creation: Sihirbaz, yapılandırma öncesinde Windows Server Failover Cluster (WSFC), servis hesapları, ağ ayarları ve Always On ön gereksinimlerini kontrol eder. Olası uyumsuzluklar veya hatalar bu aşamada raporlanır.
Review your selections: Yapılandırma tamamlanmadan önce yapılan tüm seçimler özetlenir. Bu ekran, yanlış veya eksik bir ayar olup olmadığını son kez kontrol etmek için kullanılır.

Introduction ekranında incelemelerimizi tamamladıktan sonra Next seçeneğine tıklayarak yapılandırma adımlarına geçiyoruz.

Specify Availability Group Options ekranında Availability Group için Availability Group name alanına benzersiz ve anlamlı bir Name (İsim) belirlememiz gerekmektedir. Bu isim, oluşturulacak Availability Group’un yönetimi, izlenmesi ve diğer Always On bileşenleri ile ilişkilendirilmesi açısından önemlidir. İsimlendirme işlemini tamamladıktan sonra yapılandırma adımlarına devam edilir.

Specify Availability Group Options ekranında Availability Group için Cluster type bölümü altında Windows Server Failover Cluster, EXTERNAL ve NONE seçeneklerini görüyoruz. Bu seçenekler, Always On Availability Group mimarisinde kullanılacak Cluster (Kümeleme) yapısının türünü belirlemek için kullanılır.

Windows Server Failover Cluster (WSFC): Microsoft SQL Server Always On’un klasik ve en yaygın kullanım şeklidir. Windows işletim sistemi üzerinde çalışan SQL Server kurulumlarında High Availability (Yüksek Erişilebilirlik), Automatic Failover (Otomatik Devralma), Health Monitoring (Sağlık İzleme) ve Resource Management (Kaynak Yönetimi) Windows Server Failover Cluster (WSFC) tarafından sağlanır. Ayrıca host edilen uygulamaların yapılandırmalarının yönetilmesi, Node’lar üzerindeki değişikliklerin algılanması ve bu değişikliklerin Cluster geneline yayılması gibi kritik görevleri de üstlenir. Bu nedenle Windows ortamlarında Windows Server Failover Cluster (WSFC), Always On Availability Group mimarisinin temel yapı taşıdır.

Microsoft SQL Server 2017 ile birlikte SQL Server, Linux işletim sistemi üzerinde de çalışabilir hale gelmiştir. Bu sürümle birlikte, Windows Server Failover Cluster (WSFC)’a ihtiyaç duymadan Always On Availability Group kurulumu ve yapılandırması mümkün olmuştur. Linux ortamlarında kümeleme ve failover yetenekleri Pacemaker üzerinden sağlanır.

Linux üzerinde Microsoft SQL Server 2025 Always On Availability Group, iki farklı Cluster türü ile kullanılabilir:

EXTERNAL: Bu seçenek, Pacemaker kullanılarak yapılandırılır. Bu yapı, Automatic Failover (Otomatik Yük Devretme) sağlamak ve sistem sürekliliğini artırmak amacıyla tercih edilir. Failover kararları ve kaynak yönetimi Pacemaker tarafından kontrol edilir.
NONE: Bu seçenekte ise Pacemaker kullanılmaz. Bu yapılandırma, Read Scale senaryoları ve Manual Failover gereksinimleri için uygundur. Automatic Failover (Otomatik Yük Devretme) desteği bulunmaz ve yönetim tamamen manuel olarak gerçekleştirilir.

Specify Availability Group Options ekranında

Microsoft SQL Server 2025 ile birlikte Always On Availability Group mimarisi, önceki sürümlerde sunulan High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) yeteneklerini daha kararlı, gözlemlenebilir ve operasyonel olarak yönetilebilir hale getirmiştir. Özellikle veritabanı sağlık farkındalığı, failover karar mekanizmaları ve sistem nesnelerinin tutarlılığı konularında önemli iyileştirmeler sunulmaktadır.

Database level health detection: Database level health detection özelliği, SQL Server 2025 ile birlikte daha gelişmiş bir sağlık izleme yaklaşımı sunar. Veritabanı seviyesinde oluşan bozulmalar artık daha erken tespit edilerek failover kararları daha doğru ve hızlı bir şekilde alınabilmektedir. Bu sayede yalnızca sunucu kaynaklı problemler değil, veritabanı bütünlüğünü etkileyen mantıksal ve fiziksel hatalar da Automatic Failover (Otomatik Yük Devretme) süreçlerine dahil edilir.
Per Database DTC Support: SQL Server 2025 mimarisinde dağıtık ve yüksek trafikli sistemler için daha stabil bir yapı sunar. Failover sonrasında dağıtık işlemlerin tutarlılığı korunur ve uygulama tarafında kesinti yaşanmadan işlem devamlılığı sağlanır. Bu özellik, mikroservis mimarileri ve çok katmanlı uygulamalar için özellikle kritik hale gelmiştir.
Contained: Contained yaklaşımı, SQL Server 2025 ile birlikte kurumsal mimarilerde çok daha anlamlı bir noktaya taşınmıştır. Failover sonrasında yalnızca veritabanlarının değil, aynı zamanda SQL Server Agent Jobs, logins ve msdb bağımlılıklarının da senkronize edilmesi sayesinde, yeni Primary Replica üzerinde manuel müdahale ihtiyacı büyük ölçüde ortadan kaldırılmıştır. Bu da Always On mimarisini gerçek anlamda application-aware bir High Availability (Yüksek Erişilebilirlik) çözümü haline getirir.

Specify Availability Group Options ekranında Always On Availability Group yapısına ait temel ayarları yapılandırıyoruz.

Availability Group name alanında, ortam standartlarına uygun ve kolay ayırt edilebilir bir Availability Group adı belirliyoruz. Bu isim, SQL Server Management Studio (SSMS) ve Failover Cluster Manager üzerinde görüntüleneceği için anlamlı ve düzenli bir isimlendirme tercih edilmelidir.

Cluster type bölümünde Windows Server Failover Cluster (WSFC) seçeneğini seçiyoruz. Bu yapılandırma, Always On Availability Group mimarisinin Windows Server Failover Cluster (WSFC) altyapısı üzerinde çalışmasını ve Automatic Failover (Otomatik Yük Devretme) mekanizmasının aktif olmasını sağlar.

Specify Availability Group Options ekranında gerekli yapılandırmayı tamamladıktan sonra Next seçeneğine tıklayarak yapılandırma adımına devam ediyoruz.

Select Databases ekranında Availability Group yapısına dahil edilecek veritabanlarını seçmemiz gerekmektedir. Bu ekranda listelenen her veritabanı için Status sütunu, Availability Group ön koşullarının sağlanıp sağlanmadığını gösterir.

Availability Group’a eklenecek veritabanının Status alanında Meets prerequisites ifadesinin görülmesi gerekir. Bu ifade, veritabanının Always On Availability Group gereksinimlerini karşıladığını ve sorunsuz şekilde Availability Group’a eklenebileceğini gösterir.

Status bölümünde Full recovery mode is required hatası ile karşılaşırsanız, ilgili veritabanının Recovery model ayarının Full olarak yapılandırılmadığı anlamına gelir. Bu durumda, veritabanı özelliklerinden Recovery model seçeneğini Full olarak değiştirmeniz gerekir.

Status bölümünde Full backup is required hatası alınması durumunda ise, veritabanı üzerinde henüz Full Backup alınmadığı anlaşılır. Always On Availability Group mimarisinde, Database (Veritabanı)’in Availability Group’a eklenmeden önce en az bir kez Full Backup alınmış olması zorunludur. Aksi halde, Database (Veritabanı)’i Availability Group yapısına dahil edilemez.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz Database (Veritabanı)’in Status bölümünde yer alan Meets prerequisites ifadesine tıkladığımızda, ilgili Database (Veritabanı)’in Always On Availability Group gereksinimlerini karşıladığına dair detaylı bilgilendirme ekranını görüyoruz.

Bu bilgi, Database (Veritabanı)’in Full Recovery Model ile yapılandırıldığını, gerekli Full Backup işlemlerinin tamamlandığını ve Availability Group yapısına sorunsuz şekilde dahil edilebilecek durumda olduğunu doğrular.

Microsoft SQL Server Management Studio ekranında OK seçeneğine tıklıyoruz.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz BAKICUBUKDB isimli Database (Veritabanı) seçiyoruz.

Select Databases ekranında gerekli ön koşulların sağlandığını doğruladıktan sonra Next seçeneğine tıklayarak yapılandırma adımlarına devam ediyoruz.

Specify Replicas ekranında Replicas sekmesine geçtiğimizde Server Instance bölümünde W25SQL25NOD1 isimli sunucumuzu görüyoruz. Bu sunucu, Initial role alanında Primary olarak tanımlanmıştır ve Availability Group yapısında aktif olarak çalışan ana SQL Server rolünü üstlenir.

Specify Replicas ekranında W25SQL25NOD2 isimli sunucumuzu ise Secondary olarak yapılandıracağız. Secondary replica, Primary sunucu üzerindeki verilerin senkronize kopyasını tutarak High Availability (Yüksek Erişebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarında kesintisiz hizmet sağlanmasına katkı sağlar.

Specify Replicas ekranında Replicas sekmesinde yer alan Add Replica seçeneğine tıklayarak Availability Group yapısına W25SQL25NOD2 isimli sunucumuzu ise Secondary olarak ekleme işlemine başlıyoruz.

Required synchronized secondaries to commit

Connect to Server ekranında Login bölümü altında

Server Name bölümünde, bağlantı kurulacak W25SQL25NOD2 isimli sunucumuzun adını giriyoruz.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory üzerindeki kullanıcı veya servis hesabı bilgileri kullanılarak gerçekleştirilir.
Encrypt bölümünde, SQL Server ile istemci arasındaki bağlantının hangi şifreleme düzeyinde kurulacağını yapılandırıyoruz. Varsayılan olarak Mandatory (Zorunlu) seçeneği aktif gelir ve bu ayar, tüm istemci bağlantılarının TLS üzerinden şifrelenmesini zorunlu kılar. Böylece ağ üzerinde taşınan veriler düz metin olarak iletilmez ve olası dinleme (sniffing) saldırılarına karşı korunur.
Trust Server Certificate seçeneğini işaretleyerek, istemcinin SQL Server tarafından sunulan sertifikayı doğrulama zincirini kontrol etmeden kabul etmesini sağlıyoruz.

Connect seçeneği ile W25SQL25NOD2 isimli sunucumuza bağlantı sağlıyoruz.

Specify Replicas ekranında Replicas sekmesine geçtiğimizde Server Instance bölümünde W25SQL25NOD1 isimli sunucunun Initial role alanında Primary olarak tanımlandığını görüyoruz. Bu sunucu, Availability Group yapısında aktif olarak çalışan ana SQL Server rolünü üstlenir.

Aynı ekranda, Server Instance bölümünde yer alan W25SQL25NOD2 isimli sunucunun ise Initial role alanında Secondary olarak yapılandırıldığını görüyoruz. Secondary replica, Primary sunucu ile senkronize çalışarak yüksek erişilebilirlik ve veri sürekliliği sağlar.

Specify Replicas ekranında Replicas sekmesinde yer alan Automatic Failover (Up to 5) seçeneğini işaretliyoruz. Bu yapılandırma ile Always On Availability Group yapısında W25SQL25NOD2 isimli Primary replika üzerinde bir sorun oluşması durumunda W25SQL25NOD2 isimli Secondary replika üzerine Automatic Failover (Otomatik Yük Devretme) işlemini otomatik olarak gerçekleştirecektir.

Automatic Failover (Up to 5) ayarı, yüksek erişilebilirlik senaryolarında kesinti süresinin minimuma indirilmesini sağlar ve sistemin sürekli erişilebilir olmasına katkı sunar.

Specify Replicas ekranında Replicas sekmesinde yer alan Availability mode bölümünde Asynchronous commit ve Synchronous commit seçenekleri bulunmaktadır. Bu ayarlar, Primary ve Secondary replikalar arasındaki veri senkronizasyonunun nasıl gerçekleştirileceğini belirler.

Asynchronous commit: Asynchronous modunda Primary replika transaction log kayıtlarını Secondary replikaya gönderir ancak işlemin tamamlanması için karşı taraftan onay beklemez. Bu yapı, ağ gecikmesinin yüksek olduğu uzak lokasyonlarda tercih edilir ve genellikle Disaster Recovery (Felaket Kurtarma) senaryoları için uygundur.
Synchronous commit: Synchronous modunda ise, Primary replika işlemi tamamlamadan önce Secondary replikadan onay bekler. Onay alındıktan sonra SQL Server Always On işlemi istemciye başarılı olarak döner. Bu yapılandırma, veri kaybını önlemeyi hedefleyen High Availability (Yüksek Erişilebilirlik) senaryolarında tercih edilir.

Specify Replicas ekranında Replicas sekmesinde yer alan Readable Secondary bölümünde No, Yes ve Read-intent only seçenekleri bulunmaktadır. Bu ayar, Secondary replikanın okuma amaçlı bağlantılara açık olup olmayacağını belirler.

No: Bu seçenek tercih edildiğinde, Secondary replika yalnızca senkronizasyon amacıyla kullanılır ve okuma bağlantılarını kabul etmez. Bu yapı, sadece yüksek erişilebilirlik veya felaket kurtarma senaryoları için kullanılan replikalar için uygundur.
Yes: Bu seçenek seçildiğinde, Secondary replika hem normal okuma bağlantılarını hem de raporlama amaçlı sorguları kabul eder. Bu sayede raporlama ve sorgu yükü Primary sunucu üzerinden alınarak sistem performansı artırılabilir.
Read-intent only: Bu seçenek eçeneğinde ise, Secondary replika yalnızca ApplicationIntent=ReadOnly parametresi ile gelen bağlantıları kabul eder. Bu yapı, uygulama tarafında okuma ve yazma iş yüklerinin ayrıştırılmasını sağlar ve Always On Listener üzerinden yönlendirilen okuma trafiği için en çok tercih edilen senaryodur.

Not: Availability mode olarak Asynchronous commit seçeneği, Primary replikanın işlemleri Secondary replikanın onayını beklemeden tamamlamasını sağlar ve genellikle Disaster Recovery (Felaket Kurtarma) senaryolarında kullanılır. Synchronous commit seçeneğinde ise, Primary replika işlemi tamamlamadan önce Secondary replikanın onayını bekler. Onay alındıktan sonra Microsoft SQL Server, işlemi istemciye başarılı olarak döner ve veri kaybı riski minimize edilir.

Specify Replicas ekranında Replicas sekmesinde yer alan Required synchronized secondaries to commit seçeneği, SQL Server Always On Availability Group mimarisinde, Synchronous Commit modunda çalışan işlemlerin tamamlanabilmesi için kaç adet Secondary replikanın senkronize olup onay vermesi gerektiğini belirleyen ayardır.

Bu ayar etkinleştirildiğinde, Primary replika bir işlemi tamamlamadan önce belirlenen sayıda Secondary replikadan commit onayı bekler. Gerekli sayıda senkronize Secondary onayı alınmadan işlem istemciye başarılı olarak dönmez. Bu mekanizma, veri tutarlılığını ve sıfıra yakın veri kaybını garanti altına almak amacıyla kullanılır.

Required synchronized secondaries to commit ayarı;

Veri kaybı riskini azaltır,
Senkronize çalışan Secondary replikaların gerçekten güncel kalmasını sağlar,
Yüksek erişilebilirlik senaryolarında veri bütünlüğünü ön planda tutar.

Specify Replicas ekranında Replicas sekmesinde gerekli yapılandırmaları tamamladıktan sonra Endpoints sekmesine geçerek, Availability Group replikaları arasında veri iletişimini sağlayacak endpoint ayarlarını yapılandırma adımına devam ediyoruz.

Specify Replicas ekranında Endpoints sekmesine geçtiğimizde default olarak gelen ayarlarda herhangi bir değişiklik yapmıyoruz. Varsayılan yapılandırma, tek instance kullanılan ortamlarda Always On Availability Group iletişimi için yeterlidir.

Ancak dikkat edilmesi gereken önemli bir nokta vardır. Eğer sunucularınız üzerinde birden fazla SQL Server Instance çalışıyorsa, her instance için farklı bir Endpoint Port Number kullanılması zorunludur. Örneğin, ilk instance için Availability Group yapılandırması sırasında varsayılan olarak 5022 portu kullanılabilir. Aynı sunucu üzerindeki ikinci instance için yeni bir Availability Group yapılandırırken, Endpoint Port Number mutlaka değiştirilmelidir.

Bu senaryoda, ikinci instance için 5023 gibi farklı bir port kullanılması önerilir. Bu yapılandırma, endpoint çakışmalarını önler ve Always On replikaları arasındaki iletişimin sorunsuz şekilde çalışmasını sağlar.

Endpoint Name: Availability Group yapısında, replikalar arasındaki veri iletişimini sağlayan Database Mirroring Endpoint için tanımlanan isimdir. Varsayılan olarak otomatik oluşturulur ve çoğu senaryoda değiştirilmesi gerekmez. Ortamda birden fazla instance veya özel standartlar varsa, ayırt edici bir endpoint adı tercih edilebilir.
Encrypt Data: Replikalar arasında taşınan verinin şifrelenmesini sağlar. Bu seçenek etkin olduğunda, Always On trafiği ağ üzerinde güvenli bir şekilde iletilir. Varsayılan ve önerilen ayar Encrypt Data = Yes şeklindedir ve güvenlik açısından kapatılması tavsiye edilmez.
SQL Server Service Account: Endpoint’in hangi SQL Server servis hesabı ile çalışacağını belirtir. Availability Group replikaları arasındaki iletişim bu servis hesabı üzerinden sağlanır. Tüm replikalarda SQL Server servis hesabının doğru yetkilere sahip olması ve karşılıklı olarak endpoint erişim izinlerinin bulunması gerekir. Bu yapılandırma, Always On mimarisinin güvenli ve sağlıklı çalışması açısından kritik öneme sahiptir.

Specify Replicas ekranında Endpoints sekmesinde gerekli yapılandırmaları tamamladıktan sonra Backup Preferences sekmesine geçerek, Availability Group ortamında yedekleme işlemlerinin hangi replika üzerinden gerçekleştirileceğini belirleme adımına devam ediyoruz.

Specify Replicas ekranında Backup Preferences bölümünde Prefer Secondary, Secondary only, Primary ve Any Replica seçenekleri bulunmaktadır. Bu seçenekler, Availability Group yapısında yedekleme işlemlerinin hangi replika üzerinden gerçekleştirileceğini belirler.

Prefer Secondary seçeneğinde, Availability Group içinde aktif bir Secondary replika varsa otomatik yedekleme işlemleri öncelikli olarak Secondary sunucu üzerinden gerçekleştirilir. Ortamda kullanılabilir bir Secondary replika bulunmaması durumunda ise yedekleme işlemleri Primary sunucu üzerinden devam eder.
Secondary only seçeneği ile, Availability Group yapısındaki tüm otomatik yedeklemelerin yalnızca Secondary replika üzerinden alınması zorunlu hale getirilir. Bu ayar, Primary sunucu üzerindeki işlem ve I/O yükünü azaltmak amacıyla tercih edilir.
Primary seçeneği seçildiğinde, Availability Group ortamındaki tüm otomatik yedekleme işlemleri yalnızca Primary replika üzerinden gerçekleştirilir.
Any Replica seçeneği ise, yedekleme işlemlerinin hem Primary hem de Secondary replikalar üzerinden alınabilmesine olanak tanır. Bu yapılandırma, yedekleme süreçlerinde esneklik sağlamak isteyen ortamlarda kullanılabilir.

Specify Replicas ekranında Backup Preferences sekmesinde Server Instance, Backup Priority ve Exclude Replica alanları yer almaktadır. Bu alanlar, Availability Group yapısında yedekleme davranışının daha detaylı ve kontrollü şekilde yönetilmesini sağlar.

Server Instance: Availability Group’a dahil olan Primary ve Secondary SQL Server replikalarının listelendiği bölümdür. Yedekleme tercihleri ve öncelikler, her bir Server Instance için ayrı ayrı yapılandırılabilir.
Backup Priority: Yedekleme işlemlerinde hangi replikanın öncelikli olarak kullanılacağını belirler. Daha yüksek değer, daha yüksek öncelik anlamına gelir. SQL Server, Backup Preferences kurallarına uygun olarak, en yüksek Backup Priority değerine sahip uygun replikayı yedekleme için tercih eder.
Exclude Replica: İlgili replikanın otomatik yedekleme işlemlerinden tamamen hariç tutulmasını sağlar. Bu seçenek işaretlendiğinde, söz konusu replika Availability Group içinde bulunsa bile yedekleme işlemleri için kullanılmaz. Genellikle performans, bakım veya özel senaryolar nedeniyle belirli replikaların yedekleme sürecine dahil edilmemesi istendiğinde tercih edilir.

Specify Replicas ekranında Backup Preferences sekmesinde gerekli yapılandırmayı Any Replica olarak seçiyoruz.

Specify Replicas ekranında gerekli ayarları tamamladıktan sonra Listener sekmesine geçerek, Availability Group için istemci bağlantılarını yönetecek Always On Listener yapılandırmasına devam ediyoruz.

Specify Replicas ekranında Listener sekmesinde Availability Group yapısı için Always On Listener yapılandırmasını gerçekleştiriyoruz.

Listener Nedir: Availability Group yapısında birden fazla SQL Server bulunur ve veritabanı o anda hangi sunucuda aktif (Primary) olarak çalışıyor olursa olsun, uygulamalar veritabanına tek bir bağlantı noktası üzerinden erişir. Bu bağlantı noktası Listener olarak adlandırılır. Listener; bir Listener DNS Name (Dinleyici DNS İsmi) ve buna karşılık gelen bir Listener IP Address (Dinleyici IP Adresi) içerir. Uygulamalar (Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi) doğrudan SQL Server sunucularının IP adreslerini veya sunucu isimlerini bilmez; bağlantılarını yalnızca Listener üzerinden gerçekleştirir. Failover durumunda, Listener otomatik olarak aktif olan SQL Server’a yönlendirme yapar ve uygulama tarafında herhangi bir değişiklik gerekmez.

Specify Replicas ekranında Listener sekmesinde Availability Group yapısı için listener yapılandırma seçenekleri

Do not create an availability group listener now: Bu seçenek ile Listener yapılandırmasını, Microsoft SQL Server 2025 Always On Availability Group kurulumu tamamlandıktan sonra manuel olarak gerçekleştirebilirsiniz.
Create an availability group listener: Bu seçenek ile Listener yapılandırmasını bu sihirbaz sırasında oluşturarak Always On yapılandırmasını tek adımda tamamlayabilirsiniz.

Specify Replicas ekranında Listener sekmesinde Create an availability group listener seçeneğini işaretleyerek Listener yapılandırmasını gerçekleştiriyoruz.

Listener DNS Name alanında, Availability Group yapısı için kullanılacak bir DNS adı belirliyoruz. Bu isim, uygulamaların veritabanına bağlanırken kullanacağı tek ve sabit bağlantı noktasıdır.
Port bölümünde, uygulamalarımızın (Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi) veritabanına bağlanacağı SQL Server portunu tanımlıyoruz. Tüm istemci bağlantıları bu port üzerinden Listener’a yönlendirilir.
Network Mode alanında ise Static IP seçeneğini yapılandırıyoruz. Availability Group mimarisinde uygulamalar, veritabanı bağlantıları için Listener IP Address (Dinleyici IP Adresi) kullanır. Statik IP yapılandırması sayesinde, failover senaryolarında IP adresi değişmeden aktif olan SQL Server’a otomatik yönlendirme sağlanır ve uygulama tarafında ek bir yapılandırmaya gerek kalmaz.

Specify Replicas ekranında Listener sekmesinde Network Mode bölümünde Availability Group yapısı için Static IP (Statik IP) yapılandırmasını kullanmamız gerekmektedir. Bu yapılandırma sayesinde uygulamalarımız (Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi) veritabanı bağlantılarını doğrudan Listener IP Address (Dinleyici IP Adresi) üzerinden gerçekleştirir.

Network Mode alanını Static IP olarak seçtikten sonra Add seçeneğine tıklayarak Listener IP Address yapılandırma adımına geçiyoruz. Bu işlem, failover senaryolarında IP adresi değişmeden aktif olan SQL Server’a otomatik yönlendirme yapılmasını sağlar ve uygulama tarafında ek bir ayara ihtiyaç bırakmaz.

Add IP Address ekranında Listener için yer alan Subnet bölümü; tanımlanacak Listener IP Address (Dinleyici IP Adresi)’in hangi Subnet (Ağ Segmenti ) üzerinde çalışacağını belirtir.

Subnet bölümü; SQL Server replikalarının ve Windows Server Failover Cluster yapısının bağlı olduğu subnet seçilmelidir. Doğru subnet yapılandırması, Listener’ın cluster üzerinde sorunsuz şekilde ayağa kalkmasını ve uygulamaların veritabanına kesintisiz erişimini sağlar.

Add IP Address ekranında Listener için yer alan Subnet bölümünde 192.168.1.0/24 ve 192.168.2.0/24 ağlarını görüyoruz.

Bu alan, Availability Group Listener için tanımlanacak IP adresinin hangi subnet üzerinde konumlanacağını gösterir. Ortam mimarinize ve SQL Server replikalarının bağlı olduğu ağa göre, Listener IP Address için uygun subnet seçimi bu bölümden yapılır.

192.168.2.0/24 subneti, Failover Cluster yapısında Cluster Only olarak tanımlanmış ağdır. Bu ağ, yalnızca node’lar arası cluster iletişimi için kullanılır. Heartbeat trafiği ve cluster durum bilgileri bu ağ üzerinden taşınır; istemci erişimine kapalıdır ve SQL Listener gibi servisler bu subnet üzerinden yayınlanmaz.
192.168.1.0/24 subneti ise Failover Cluster yapısında Cluster and Client olarak yapılandırılmıştır. Bu ağ hem cluster içi iletişim hem de istemci bağlantıları için kullanılır. Uygulama, servis ve SQL Server Always On Listener erişimleri bu subnet üzerinden sağlanır.

Add IP Address ekranında Listener için yer alan IPv4 Address bölümü; Availability Group Listener’a atanacak statik IPv4 adresinin tanımlandığı alandır.

Bu alanda, seçilen subnet’e uygun, ağ üzerinde kullanılmayan (boşta) bir IP adresi girilmelidir. Tanımlanan bu IPv4 adresi, uygulamaların veritabanına bağlanırken kullanacağı Listener IP Address (Dinleyici IP Adresi) olacaktır. Doğru yapılandırılmış bir IPv4 Address, failover senaryolarında bağlantının kesintisiz devam etmesini sağlar.

Add IP Address ekranında Listener için yer alan Subnet Mask bölümü; tanımlanan IPv4 Address’in hangi ağ aralığına ait olduğunu belirleyen ağ maskesinin girildiği alandır. Bu alan, Subnet seçimi yapıldıktan sonra otomatik olarak doldurulur ve ek bir manuel yapılandırma gerektirmez.

Add IP Address ekranında Listener için gerekli IP Address (IP Adresi) yapılandırmasını tamamladıktan sonra OK seçeneğine tıklıyoruz.

Not: Bu aşamada tanımlanan Listener IP Address (Dinleyici IP Adresi)’nin ortamınızda herhangi bir sunucu, cihaz veya servis tarafından kullanılmıyor olmasına özellikle dikkat edilmelidir. Aksi durumda IP çakışması yaşanabilir ve Availability Group Listener doğru şekilde çalışmayabilir.

Specify Replicas ekranında Listener sekmesinde Network Mode bölümünün Static IP (Statik IP) olarak gerekli şekilde yapılandırıldığını görüyoruz.

Specify Replicas ekranında Listener sekmesinde listener yapılandırmasını tamamladıktan sonra Read-Only Routing sekmesine geçerek, okuma amaçlı bağlantıların Availability Group replikaları arasında nasıl yönlendirileceğini belirleme adımına devam ediyoruz.

Specify Replicas ekranında Read-Only Routing sekmesinde herhangi bir değişiklik yapmıyoruz ve varsayılan ayarlarla yapılandırmaya devam ediyoruz.

Read-Only Routing: SQL Server Always On Availability Group mimarisinde okuma amaçlı (read-only) bağlantıların otomatik olarak uygun Secondary replikalara yönlendirilmesini sağlayan bir mekanizmadır. Bu yapı sayesinde raporlama, sorgulama ve analiz gibi okuma ağırlıklı iş yükleri, Primary sunucu yerine Secondary replikalar üzerinden çalıştırılabilir. Böylece Primary replika üzerindeki yük azalır ve sistem performansı artırılır. Read-Only Routing, genellikle Always On Listener ile birlikte çalışır. Uygulamalar bağlantı sırasında ApplicationIntent=ReadOnly parametresi kullandığında, SQL Server bu bağlantıları tanımlanan yönlendirme kurallarına göre uygun Secondary replika üzerine otomatik olarak yönlendirir.

Kısaca özetlemek gerekirse, Read-Only Routing, okuma trafiğini yöneterek hem performans hem de yüksek erişilebilirlik hedeflerine katkı sağlayan kritik bir Always On özelliğidir.

Specify Replicas ekranında gerekli yapılandırmayı tamamladıktan sonra Next seçeneğine tıklayarak yapılandırma adımına devam ediyoruz.

Select Initial Data Synchronization ekranında Availability Group yapısında Secondary sunucuya veritabanlarının ilk kez nasıl senkronize edileceğinin belirlendiği adımdır. Bu ekranda, verinin Secondary replika üzerine hangi yöntemle aktarılacağı seçilir.

Automatic seeding seçeneği tercih edildiğinde, Secondary sunucuya veritabanı senkronizasyonu için gerekli tüm işlemler otomatik olarak gerçekleştirilir. Bu yöntemde ek bir paylaşım alanına veya manuel bir işleme ihtiyaç duyulmaz ve yapılandırma süreci hızlı şekilde tamamlanır.
Full database and log backup seçeneği ile devam edildiğinde ise, her bir veritabanının Full Backup ve Transaction Log Backup dosyaları, önceden yapılandırılmış bir Share (Paylaşım) üzerinden alınarak Secondary sunucuya otomatik olarak aktarılır. Bu yöntemin çalışabilmesi için SQL Server servis hesaplarının ilgili paylaşım üzerinde Read (Okuma) ve Write (Yazma) yetkilerine sahip olması gerekir. Ayrıca, paylaşım alanında veritabanı yedeklerinin sığabileceği yeterli disk alanı bulunmalıdır.
Specify the file share path in Windows format: Availability Group yapılandırması sırasında Full database and log backup yöntemi seçildiğinde kullanılan ekrandır. Bu alanda, Primary ve Secondary sunucular tarafından erişilebilen bir Windows File Share (UNC Path) tanımlanır (örneğin \\SERVERNAME\SQLBackup). Belirtilen paylaşım yolu, Full Backup ve Transaction Log Backup dosyalarının geçici olarak oluşturulacağı ve Secondary sunucuya aktarılacağı konumdur. Paylaşım üzerinde, her iki sunucudaki SQL Server Service Account’larının Read (Okuma) ve Write (Yazma) yetkilerine sahip olması ve paylaşım alanında yedek dosyaları için yeterli disk alanının bulunması gerekmektedir.

Specify the file share location in Linux format bölümü altında yer alan senkronizasyon seçenekleri:

Join only seçeneğinde, Availability Group’a eklenecek her bir veritabanı için Full Backup ve Transaction Log Backup işlemlerinin manuel olarak alınmış olması gerekir. Bu yedeklerin, bu adıma geçilmeden önce manuel olarak Secondary sunucuya kopyalanmış ve veritabanlarının RESTORING durumunda hazır hale getirilmiş olması zorunludur.
Skip initial data synchronization seçeneğinde ise, yine veritabanlarının Full Backup ve Transaction Log Backup işlemleri manuel olarak alınır ve Secondary sunucuya manuel olarak kopyalanır. Ancak Join only seçeneğinden farklı olarak, bu işlemlerin daha sonra yapılmasına izin verilir. Bu yöntem, ilk kurulum sırasında senkronizasyonu ertelemek isteyen ortamlarda tercih edilir.

Select Initial Data Synchronization ekranında Secondary sunucu üzerine veritabanı senkronizasyonunun otomatik olarak gerçekleştirilmesi için Automatic seeding seçeneğini seçiyoruz.

Select Initial Data Synchronization ekranında gerekli yapılandırmayı tamamladıktan sonra Next seçeneğine tıklayarak yapılandırma adımına devam ediyoruz.

Validation ekranında Availability Group yapısının kurulumu için gerekli tüm kontroller otomatik olarak gerçekleştirilir. Bu ekranda, yapılandırmaya ait tüm adımların Success olarak görünmesi, Always On Availability Group kurulumunun sorunsuz şekilde ilerleyebileceğini gösterir.

Eğer yapılandırmada herhangi bir problem olsaydı, ilgili adımlar Error olarak görüntülenirdi. Bu durumda Previous seçeneği ile geri dönerek hatalı yapılandırmayı düzeltebilir ve ardından Re-run validation ile kontrolleri yeniden çalıştırabilirsiniz.

Validation ekranında herhangi bir sorun tespit edilmediği için Next seçeneğine tıklayarak yapılandırma adımına devam ediyoruz.

Summary ekranında Availability Group yapısının kurulması için gerçekleştirilen tüm yapılandırma adımlarının özet bilgilerini görüyoruz. Bu ekran, kurulum öncesinde yapılan ayarların son kez kontrol edilmesini sağlar.

Summary ekranında Availability Group yapısının kurulması için gerekli olan tüm yapılandırma özetini kontrol ettikten sonra Finish seçeneğine tıklayarak kurulum işlemini başlatıyoruz.

Ayrıca Summary ekranında yer alan Script bölümünden, Availability Group için oluşturduğumuz yapılandırmayı Script (Senaryo) olarak alabiliriz. Bu script, ileride benzer kurulumlar yapmak, dokümantasyon oluşturmak veya yapılandırmayı yeniden uygulamak için kullanılabilir.

Progress ekranında Availability Group yapısının kurulduğunu görüyoruz. Bu ekran, Always On Availability Group yapılandırması sırasında gerçekleştirilen tüm adımların ilerleme durumunu ve işlemlerin başarıyla tamamlandığını gösterir.

Results ekranında Availability Group yapısının başarılı bir şekilde kurulduğunu görüyoruz. Bu ekran, Always On Availability Group yapılandırmasının sorunsuz tamamlandığını doğrular.

Always On Availability Group yapılandırmasının sorunsuz tamamlandıktan sonra Close seçeneğine tıklayarak New Availability Group Wizard ekranını kapatıyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında BAKICUBUKDB isimli veritabanının BAKICUBUKDB (Synchronized) durumunda olduğunu görüyoruz. Bu ifade, veritabanının Always On Availability Group kapsamında Primary ve Secondary replikalar arasında senkronize çalıştığını ve yapının sağlıklı olduğunu gösterir.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmında, SQL25HAG ismiyle yapılandırmış olduğumuz Availability Group yapısının başarıyla oluşturulduğunu görüyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmında BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapısını görüyoruz.

Bu yapı altında, Availability Replicas bölümünde W25SQL25NOD1 isimli sunucunun Primary, W25SQL25NOD2 isimli sunucunun ise Secondary replika olarak yapılandırıldığını görüyoruz.

Bu yapı altında, Availability Databases bölümünde BAKICUBUKDB isimli Database (Veritabanı)’nın Availability Group’a başarıyla dahil edildiğini görüyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups bölümünde BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapısını görüyoruz.

Bu yapı altında, Availability Listeners bölümünde SQL25ALWAYSON isimli Listener DNS Name (Dinleyici DNS Name)’in başarıyla oluşturulduğunu görüyoruz.

Failover Cluster Manager konsolunda, Roles (Roller) menüsü altında SQL25ALWAYSON ismi ile yapılandırmış olduğumuz Availability Group yapısının başarıyla oluşturulduğunu ve Cluster rolü olarak eklendiğini görüyoruz.

W25SQL25NOD2 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz.

Bu yapı altında, Availability Databases bölümünde BAKICUBUKDB isimli Database (Veritabanı)’nın Availability Group’a başarıyla dahil edildiğini görüyoruz.

Bu yapı altında, Availability Listeners bölümünde SQL25ALWAYSON isimli Listener DNS Name (Dinleyici DNS Name)’in başarıyla oluşturulduğunu görüyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups kısmında SQL25HAG ismiyle yapılandırmış olduğumuz Availability Group üzerinde sağ tuşa tıklayarak Show Dashboard seçeneğini seçiyoruz.

Show Dashboard seçeneğine tıkladığınızda, Availability Group Dashboard ekranı açılır.

Bu ekran, Always On Availability Group yapısının anlık sağlık durumunu ve çalışma durumunu tek bir yerden izlemenizi sağlar.

Availability Group Dashboard ekranında özetle şunları görürsünüz:

Primary ve Secondary replikaların durumu (Online, Synchronized, Synchronizing vb.)
Veritabanlarının senkronizasyon durumu
Automatic Failover ve Availability Mode bilgileri
Listener durumu ve erişilebilirliği
Olası uyarılar ve hatalar

Bu ekran, Always On Availability Group yapısının sağlıklı çalışıp çalışmadığını hızlıca kontrol etmek ve olası sorunları erken tespit etmek için kullanılan en önemli izleme ekranıdır.

Başka bir yazımızda görüşmek dileğiyle…

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

bakicubuk

Bir yanıt yazın Yanıtı iptal et

Üst veri

Archives

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

bakicubuk

Bir yanıt yazın Yanıtı iptal et

Related Posts