Microsoft SQL Server 2025 Always On Availability Group Node Eklemek 4

bakicubuk

3 saat önce

Merhaba

Bu yazı dizimizde, Microsoft SQL Server 2025 Always On Availability Group mimarisinde Node ekleme sürecinin kurulum ve yapılandırma adımlarını detaylı şekilde ele alacak; High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları inceleyeceğiz.

Daha önceki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Node Eklemek 1

W25SQL25NOD3 isimli Windows Server 2025 sunucumuz üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını başarıyla tamamladık. Bu yapı, High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarının temelini oluşturan kritik bir altyapı bileşenidir.

Daha sonraki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Node Eklemek 2

Daha sonraki yazımızda

Microsoft SQL Server 2025 Always On Availability Group Node Eklemek 3

W25SQL25NOD3 isimli sunucumuz üzerinde Microsoft SQL Server 2025 Always On Availability Group mimarisine geçmeden önce Microsoft SQL Server 2025 servisleri üzerinde yapılması gereken kritik ön hazırlık ve ayarları detaylı şekilde ele aldık. Bu kapsamda servis hesapları, güvenlik yapılandırmaları, Always On ön gereksinimleri ve best practice ayarlarını adım adım tamamladık.

Bu yazımızda da W25SQL25NOD3 isimli sunucumuzu, Microsoft SQL Server 2025 Always On Availability Group mimarisine Secondary Replica (Node) olarak ekleme sürecini ve bu süreçte dikkat edilmesi gereken teknik noktaları detaylı olarak ele alıyoruz.

W25SQL25NOD3 isimli sunucumuzu Availability Group’a dahil etmeden önce, ortamın Windows Server Failover Cluster (WSFC) tarafında sağlıklı çalıştığından emin olmalıyız. Çünkü Always On Availability Group, arka planda Windows Server Failover Cluster (WSFC) bileşenlerini kullanır ve cluster tarafındaki isim çözümleme, ağ erişimi, quorum tasarımı, node üyeliği ve servis hesapları gibi unsurlar doğrudan Availability Group davranışını etkiler. Bu nedenle W25SQL25NOD3’ün Active Directory Domain üye, Windows Server Failover Cluster (WSFC) üyesi, gerekli Windows güncellemeleri uygulanmış, Microsoft SQL Server 2025 kurulumu tamamlanmış ve Always On Availability Groups özelliği SQL Server Configuration Manager üzerinden etkinleştirilmiş olması gerekir. Ayrıca Windows Firewall/Network Security katmanında, replika iletişimi ve listener erişimi için ihtiyaç duyulan portların (özellikle SQL portu ve HADR endpoint portu) doğru şekilde planlanması kritik öneme sahiptir.

Hazırlıklar tamamlandıktan sonra yönetim adımı tarafında Microsoft SQL Server Man,agement Studio (SSMS) üzerinden Primary Replica (Node)’ya bağlanarak, Always On High Availability altında ilgili Availability Group üzerinde Add Replica sihirbazını başlatırız. Bu sihirbaz içerisinde W25SQL25NOD3 isimli sunucusunu Secondary Replica (Node) olarak seçerken; replikasyon modu (Synchronous/Asynchronous), Failover türü (Automatic/Manual), Readable Secondary ayarı (No/Read-intent/Yes) ve Backup tercihi gibi kararları tasarıma uygun şekilde belirleriz. Özellikle üretim senaryolarında, W25SQL25NOD3’ün uzak lokasyon/Disaster Recovery (Felaket Kurtarma) amaçlı eklenmesi durumunda Asynchronous (Asenkron) replikasyon + Manual Failover (Manuel Yük Devretme) yaklaşımı daha doğru olurken; aynı lokasyonda düşük gecikmeli bir yapıda Synchronous (Senkron) replikasyon + Automatic Failover (Otomatik Yük Devretme) tercih edilebilir.

Node ekleme sürecinin en kritik teknik adımlarından biri de endpoint tarafıdır. Availability Group replikaları, Database Mirroring tabanlı HADR endpoint’leri üzerinden haberleşir. Bu nedenle W25SQL25NOD3 isimli sunucumuz üzerinde endpoint’in doğru portta dinlemesi, servis hesabı yetkileri, sertifika/kimlik doğrulama tercihleri ve karşılıklı bağlantının sorunsuz olması gerekir. Bir diğer önemli konu ise seeding yöntemi seçimidir. Eğer Automatic Seeding kullanılacaksa hem network kapasitesi hem de data büyüklüğü değerlendirilmelidir; büyük veritabanlarında seeding işlemi ciddi ağ tüketimine neden olabileceği için kontrollü zamanlama veya manuel seed (backup/restore) yaklaşımı tercih edilebilir.

Son olarak, W25SQL25NOD3 isimli sunucumuz eklendikten sonra Availability Group Dashboard üzerinden synchronization state, synchronization health, redo queue / send queue gibi metrikler kontrol edilmelidir. Listener erişimi, uygulama bağlantı cümleleri, DNS kaydı ve client routing gibi bileşenler de test edilerek W25SQL25NOD3 isimli sunucumuz mimariye sorunsuz şekilde entegre olduğu doğrulanmalıdır. Bu kontroller, eklenen node’un yalnızca “listede görünüyor” olmasından öte, gerçekten beklenen RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) hedefleri doğrultusunda çalıştığını güvence altına alır.

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 Domain ü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.

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ı 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 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 sunucumuzu Primary Replica (Node), W25SQL25NOD2 isimli sunucumuzu ise Secondary Replica (Node) 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 yapısına 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 SQL25HAG 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.

Microsoft SQL Server Management Studio (SSMS) konsolunda Always On High Availability bölümü altında yer alan Availability Groups sekmesine geldiğimizde, SQL25HAG ismiyle yapılandırılmış olan Availability Group yapısını görüntülüyoruz.

Mevcut SQL25HAG Availability Group yapısına yeni bir Secondary Replica (Node) eklemek amacıyla, ilgili Availability Group üzerinde sağ tuş tıklıyoruz ve açılan menüden Add Replica seçeneğini seçiyoruz.

Bu işlem ile birlikte, hali hazırda çalışan SQL25HAG Always On Availability Group mimarisine ek bir Secondary Replica dahil etmek üzere Add Replica to Availability Group Wizard sihirbazı başlatılmış olur. Bu sihirbaz, yeni eklenecek replikaya ait bağlantı, senkronizasyon, failover ve erişim ayarlarının adım adım yapılandırılmasını sağlar.

Add Replica to Availability Group – SQL25HAG ekranı geliyor karşımıza.

Introduction ekranı Add Replica to Availability Group sihirbazının ilk adımıdır ve tamamen bilgilendirme amaçlıdır.

Introduction ekranında mevcut Availability Group yapısına yeni bir Availability Replica ekleme sürecinde izlenecek adımlar özetlenir. Sihirbazın ilerleyen aşamalarında hangi işlemlerin gerçekleştirileceği açık bir şekilde belirtilerek kullanıcıya yol gösterilir.

Introduction ekranında özetle;

Mevcut Availability Group’a bir veya birden fazla replica eklenebileceği,
Eklenecek yeni replika için ilgili SQL Server instance’ına bağlantı kurulacağı,
Başlangıç veri senkronizasyon yönteminin seçileceği,
Yapılandırma öncesinde validasyon kontrollerinin çalıştırılacağı,
Son adımda tüm seçimlerin özetlenip gözden geçirileceği

bilgileri paylaşılır.

Introduction ekranında herhangi bir yapılandırma veya seçim yapılmaz. Ekran yalnızca sürece dair bilgilendirme sağlar.

Introduction ekranında gerekli kontrolleri ve açıklamaları inceledikten sonra Next seçeneğine tıklayarak sihirbazın Connect to Replicas adımına geçiyoruz.

Connect to Existing Secondary Replicas ekranında, Server Instance bölümünde W25SQL25NOD2 isimli sunucunun listelendiğini görüyoruz. Bu aşamada Connected As alanının Not Connected olarak görüntülenmesi, ilgili Secondary Replica (Node) ile henüz aktif bir bağlantı kurulmadığını ifade etmektedir.

W25SQL25NOD2 isimli sunucumuza bağlantıyı sağlamak için Connect seçeneğine tıklıyoruz.

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ı görüyoruz.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory Domain ü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.

Connect to Existing Secondary Replicas ekranında Server Instance bölümünde W25SQL25NOD2 isimli sunucunun listelendiğini görüyoruz. Connected As alanının BAKICUBUK\administrator olarak görüntülenmesi, ilgili Secondary Replica (Node) ile bağlantının başarıyla kurulduğunu ve işlemlerin yetkili bir domain hesabı üzerinden gerçekleştirildiğini doğrulamaktadır.

Bu aşamada, mevcut Secondary Replica (Node) erişimin doğrulanmış olması; replikasyon ayarlarının yapılandırılabilmesi, validasyon kontrollerinin sağlıklı çalışması ve sonraki adımlarda herhangi bir yetki veya bağlantı hatasıyla karşılaşılmaması açısından kritik öneme sahiptir.

Connect to Existing Secondary Replicas ekranında gerekli kontrolleri ve yapılandırmayı tamamladıktan sonra Next seçeneğine tıklayarak Add Replica to Availability Group sihirbazında bir sonraki adıma geçiyoruz.

Specify Replicas ekranında Replicas sekmesinde, Availability Group yapısında yer alan replikaların rol dağılımlarını görüntülüyoruz.

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 mimarisi içerisinde aktif olarak çalışan ana SQL Server rolünü üstlenir. Veritabanı üzerindeki okuma ve yazma (read/write) işlemleri varsayılan olarak bu Primary Replica (Node) üzerinden gerçekleştirilir.

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 (Node), Primary Replica (Node) üzerinde gerçekleşen transaction’ları Synchronous (Senkron) veya Asynchronous (Asenkron) olarak alarak veritabanı kopyasını güncel tutar. Bu yapı, High Availability (Yüksek Erişilebilirlik) gereksinimlerini karşılayarak olası bir Primary Replica (Node) arızasında veri sürekliliğinin korunmasını sağlar.

Specify Replicas ekranı, Always On Availability Group mimarisinde replikaların rollerinin, çalışma modlarının ve failover davranışlarının belirlendiği en kritik yapılandırma adımlarından biridir.

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

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

Server Name bölümünde, bağlantı kurulacak W25SQL25NOD3 isimli sunucumuzun adını görüyoruz.
Authentication bölümünde Windows Authentication seçeneğini tercih ediyoruz. Bu yöntemle kimlik doğrulama, Active Directory Domain ü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 W25SQL25NOD3 isimli sunucumuza bağlantı sağlıyoruz.

Specify Replicas ekranında Replicas sekmesinde

Specify Replicas ekranında Server Instance bölümünde yer alan W25SQL25NOD3 isimli sunucunun ise Initial role alanında Secondary olarak yapılandırıldığını görüyoruz. Secondary Replica (Node), Primary Replica (Node) ile senkronize çalışarak High Availability (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 W25SQL25NOD1 isimli Primary Replica (Node) üzerinde bir sorun oluşması durumunda W25SQL25NOD3 isimli Secondary Replica (Node) üzerine Automatic Failover (Otomatik Yük Devretme) işlemini otomatik olarak gerçekleştirecektir.

Automatic Failover (Up to 5) ayarı, High Availability (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 Replica (Node) ve Secondary Replica (Node) arasındaki veri senkronizasyonunun nasıl gerçekleştirileceğini belirler.

Asynchronous commit: Asynchronous modunda Primary Replica (Node) transaction log kayıtlarını Secondary Replica (Node) 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 Replica (Node) işlemi tamamlamadan önce Secondary Replica (Node) 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 Replica (Node) 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 High Availability (Yüksek Erişilebilirlik) veya Disaster Recovery (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 Replica (Node) üzerinden alınarak sistem performansı artırılabilir.
Read-intent only: Bu seçenek eçeneğinde ise, Secondary Replica (Node) 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 Replica (Node) işlemleri Secondary Replica (Node) 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 Replica (Node) işlemi tamamlamadan önce Secondary Replica (Node) 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 Replica (Node) senkronize olup onay vermesi gerektiğini belirleyen ayardır.

Bu ayar etkinleştirildiğinde, Primary Replica (Node) bir işlemi tamamlamadan önce belirlenen sayıda Secondary Replica (Node) commit onayı bekler. Gerekli sayıda senkronize Secondary Replica (Node) 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,
High Availability (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 Replica (Node) varsa otomatik yedekleme işlemleri öncelikli olarak Secondary Replica (Node) sunucu üzerinden gerçekleştirilir. Ortamda kullanılabilir bir Secondary replika bulunmaması durumunda ise yedekleme işlemleri Primary Replica (Node) üzerinden devam eder.
Secondary only seçeneği ile, Availability Group yapısındaki tüm otomatik yedeklemelerin yalnızca Secondary Replica (Node) üzerinden alınması zorunlu hale getirilir. Bu ayar, Primary Replica (Node) ü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 Replica (Node) üzerinden gerçekleştirilir.
Any Replica seçeneği ise, yedekleme işlemlerinin hem Primary Replica (Node) hem de Secondary Replica (Node) ü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 Replica (Node) ve Secondary Replica (Node) 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 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ı kontrol ediyoruz.

Listener Nedir: Availability Group yapısında birden fazla SQL Server bulunur ve veritabanı o anda hangi sunucuda aktif (Primary Replica (Node)) 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, Availability Group yapısına W25SQL25NOD3 isimli sunucuyu Secondary Replica (Node) olarak eklemeyeceğimiz için Listener tarafında herhangi bir yapılandırma yapmıyoruz.

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 Replica (Node) yönlendirilmesini sağlayan bir mekanizmadır. Bu yapı sayesinde raporlama, sorgulama ve analiz gibi okuma ağırlıklı iş yükleri, Primary Replica (Node) yerine Secondary Replica (Node) üzerinden çalıştırılabilir. Böylece Primary Replica (Node) ü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 Replica (Node) üzerine otomatik olarak yönlendirir.

Kısaca özetlemek gerekirse, Read-Only Routing, okuma trafiğini yöneterek hem performans hem de High Availability (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 Replica (Node) veritabanlarının ilk kez nasıl senkronize edileceğinin belirlendiği adımdır. Select Initial Data Synchronization ekranında verinin Secondary Replica (Node) üzerine hangi yöntemle aktarılacağı seçilir.

Automatic seeding seçeneği tercih edildiğinde, Secondary Replica (Node) 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 Replica (Node) 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 Replica (Node) ve Secondary Replica (Node) 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 Replica (Node) 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 Replica (Node) 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 Replica (Node) 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 Replica (Node) üzerine veritabanı senkronizasyonunun otomatik olarak gerçekleştirilmesi için Automatic seeding seçeneğini seçiyoruz.

Automatic seeding seçeneğini ile, veritabanlarının Primary Replica (Node) üzerinden Secondary Replica (Node)’lara ilk senkronizasyonu SQL Server tarafından otomatik olarak yapılacaktır. Herhangi bir File Share tanımlamasına veya manuel backup / restore işlemine ihtiyaç duyulmadan yapılandırma süreci hızlı ve pratik şekilde ilerler.

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. Validation ekranında 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.

Checking the listener configuration adımında Warning olarak görüyoruz. Checking the listener configuration adımında görülen Warning uyarısı, mevcut SQL Always On Availability Group yapısına yeni bir Secondary Replica (Node) eklenmesi sırasında alınmaktadır. Warning uyarısına tıklayarak detayını görebilirsiniz.

Checking the listener configuration adımında görülen Warning uyarısı, mevcut SQL Always On Availability Group yapısına yeni bir Secondary Replica (Node) eklenmesi sırasında alınmaktadır.

Bu işlem sırasında Listener yapılandırması değiştirilmediği veya yeniden oluşturulmadığı için, sihirbaz Listener tarafında herhangi bir konfigürasyon tespit edemez ve bu durumu bilgilendirme amaçlı bir Warning olarak raporlar. Bu uyarı, Node ekleme (Add Replica) işleminin doğal bir sonucudur ve bir hata durumu değildir.

Söz konusu Warning;

Availability Group yapısının çalışmasını etkilemez
Replikalar arası senkronizasyonu bozmaz
Failover mekanizmasının sağlıklı çalışmasına engel olmaz

Listener yapılandırması daha önce oluşturulmuşsa veya işlem sonrasında manuel olarak eklenmişse, bu uyarı otomatik olarak ortadan kalkacaktır.

Checking the listener configuration adımında görülen Warning uyarısı, mevcut SQL Always On Availability Group yapısına yeni bir Secondary Replica (Node) eklenmesi sırasında alınmaktadır.

Checking the listener configuration adımında görülen Warning uyarıs herhangi bir sorun teşkil etmediği ve Validation ekranında yapılandırmayı engelleyen bir hata 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ına eklenecek olan W25SQL25NOD3 isimli sunucu 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ına eklenecek olan W25SQL25NOD3 isimli sunucu için gerekli olan tüm yapılandırma özetini inceledikten 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ı gerçekleştirmek, dokümantasyon oluşturmak veya yapılandırmayı yeniden uygulamak amacıyla kullanılabilir.

Progress ekranında, Availability Group yapısına eklenecek olan W25SQL25NOD3 isimli sunucu için gerekli yapılandırmanın başlatıldığını 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örsel olarak takip etmemizi sağlar.

Results ekranında, Availability Group yapısına W25SQL25NOD3 isimli sunucunun başarıyla eklendiğini görüyoruz. Bu ekran, Always On Availability Group yapılandırmasının sorunsuz bir şekilde tamamlandığını doğrular.

Availability Group yapısına W25SQL25NOD3 isimli sunucunun eklenme işlemi sorunsuz şekilde tamamlandıktan sonra, Close seçeneğine tıklayarak Add Replica to Availability Group – SQL25HAG Wizard ekranını kapatı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 yapısını görüyoruz.

Bu yapı altında, Availability Replicas bölümünde W25SQL25NOD1 isimli sunucunun Primary Replica (Node), W25SQL25NOD2 isimli sunucunun ise Secondary Replica (Node) olarak yapılandırıldığını görüyoruz. Ayrıca Availability Replicas bölümünde W25SQL25NOD3 isimli sunucunun da Secondary Replica (Node) olarak başarıyla eklendiğini doğruluyoruz.

W25SQL25NOD3 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 W25SQL25NOD3 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 Domain ü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 W25SQL25NOD3 isimli sunucumuza bağlantı sağlıyoruz.

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

W25SQL25NOD3 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 Replica (Node) ve Secondary Replica (Node) arasında senkronize çalıştığını ve yapının sağlıklı olduğunu gösterir.

Bu yapı altında, Availability Databases bölümünde BAKICUBUKDB isimli Database (Veritabanı)’nın Availability Group’a yapısına 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 Replica (Node) ve Secondary Replica (Node) 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.

Failover Cluster Manager konsolunda Roles (Roller) menüsünde User Manager Group yapılandırmasının yer aldığını görüyoruz.

User Manager Group: Windows Server Failover Cluster (WSFC) yapısı içerisinde tanımlı olan bir Cluster rolüdür ve uygulama veya servislerin High Availability (Yüksek Erişilebilir) şekilde çalışmasını sağlamak amacıyla kullanılır. Bu rol; belirli bir uygulama ya da servis grubunun hangi node üzerinde aktif olduğunu, hangi cluster kaynaklarına (IP adresi, Ağ adı, Servisler vb.) bağlı çalıştığını ve failover durumunda bu kaynakların nasıl taşınacağını yönetir. User Manager Group, tek başına bir kullanıcı grubu değildir. Aksine, birden fazla Cluster kaynağını mantıksal olarak bir araya getirerek bunların birlikte hareket etmesini sağlayan bir rol yapısıdır. Olası bir Node arızası veya Servis kesintisi durumunda, bu gruba bağlı tüm kaynaklar otomatik olarak başka bir Node’a taşınır ve uygulamanın kesintisiz çalışması sağlanır.

SQL Server Always On Availability Group mimarisinde ise User Manager Group doğrudan SQL bileşenlerini temsil etmez. SQL Server Always On yapılarında High Availability (Yüksek Erişilebilirlik); Availability Group, Availability Replica ve SQL Listener gibi ayrı Cluster kaynakları üzerinden yönetilir. SQL Listener, Failover Cluster üzerinde bağımsız bir rol olarak tanımlanır ve istemci bağlantıları bu rol üzerinden yönlendirilir. Bu nedenle User Manager Group, SQL Always On yapılarında genellikle SQL dışı uygulamalar, özel servisler veya üçüncü parti yazılımlar için kullanılır. Ancak SQL Always On ile aynı Windows Server Failover Cluster (WSFC) altyapısını paylaştığı için, Quorum yapısı, Ağ yapılandırması ve Cluster sağlığı gibi temel bileşenlerden dolaylı olarak etkilenir. Bu sebeple Windows Server Failover Cluster (WSFC)üzerinde tanımlanan tüm roller gibi User Manager Group’un da doğru yapılandırılması, genel cluster stabilitesi açısından önem taşır.

Failover Cluster Manager konsolunda, Roles (Roller) menüsü altında SQL25HAG 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.

Failover Cluster Manager konsolunda Nodes menüsünde, W25SQL25NOD3 isimli sunucumuzun Status bölümünde Up durumda olduğunu görüyoruz.

Bu yazı dizimizde, Microsoft SQL Server 2025 Always On Availability Group mimarisine Secondary Replica (Node) ekleme işlemlerini adım adım kurulum ve yapılandırma detaylarıyla ele aldık. Ayrıca High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayarak, üretim ortamları için gerekli olan tüm ön koşulları ve kritik yapılandırma noktalarını kapsamlı şekilde inceledik.

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