Microsoft SQL Server 2025 Always On Availability Group Kurulumu 5

Merhaba

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

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

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

Bu son yazımızda Always On Availability Group mimarisinin kurulum ve yapılandırma adımlarını, Availability Group oluşturma sürecini, Listener yapılandırmasını ve failover testlerini ele alıyoruz.

Ön Kontrol

Always On Availability Group yapılandırmasına geçmeden önce, her iki sunucumuzda da Always On bileşenlerinin sorunsuz çalıştığını doğruluyoruz.

W25SQL25NOD1 sunucumuz üzerinde SSMS ile Always On High Availability sekmesine tıkladığımızda herhangi bir hata almadığımızı görüyoruz. Bu durum, SQL Server servislerinin, WSFC (Windows Server Failover Cluster) entegrasyonunun ve Always On bileşenlerinin doğru yapılandırıldığını gösterir.

W25SQL25NOD1 üzerinde Always On High Availability menüsünün alt bileşenlerine eriştiğimizde de yapının hatasız açıldığını doğruluyoruz.

Aynı kontrolü ikinci sunucumuz üzerinde de yapıyoruz. W25SQL25NOD2 sunucumuz üzerinde SSMS ile Always On High Availability sekmesine tıkladığımızda burada da herhangi bir hata almadığımızı görüyoruz.

W25SQL25NOD2 tarafında da Always On bileşenleri hatasız açılıyor; böylece her iki node’un da Availability Group kurulumuna hazır olduğunu teyit etmiş oluyoruz.

Test Veritabanı Oluşturma

Always On Availability Group yapılandırmasına geçmeden önce, W25SQL25NOD1 sunucumuz üzerinde en az bir adet veritabanı oluşturulması gerekmektedir. Always On yapısı, herhangi bir veritabanı olmadan yapılandırılamaz.

Databases bölümüne sağ tıklıyoruz ve New Database seçeneğini seçiyoruz.

Database name bölümünde BAKICUBUKDB isimli yeni bir veritabanı oluşturuyoruz.

Database files bölümünde veritabanına ait dosyaların yapılandırma bilgilerini görüyoruz:

• Logical Name: SQL Server içerisinde kullanılan dosya adıdır; fiziksel dosya adından bağımsızdır
• File Type: ROWS (Data dosyası) veya LOG (Transaction Log dosyası)
• Filegroup: Veri dosyalarının ait olduğu mantıksal grup. Varsayılan olarak PRIMARY kullanılır
• Initial Size (MB): Dosya oluşturulurken ayrılan ilk disk alanı
• Autogrowth: Dosya boyutu dolduğunda SQL Server’ın dosyayı ne kadar büyüteceği
• Path: Dosyanın disk üzerindeki fiziksel konumu

Path alanında veritabanı dosyalarının Bölüm 2‘de yapılandırdığımız dizinler üzerinde oluşturulacağını görüyoruz.

Data ve Log dosyalarının yollarını ayrı ayrı kontrol ederek her birinin doğru yerel disk üzerinde konumlandığını doğruluyoruz:

Recovery Model – Full (Zorunlu)

Options sekmesinde Recovery model bölümünün Full olması zorunludur. Always On Availability Group yapısı yalnızca Full Recovery Model ile çalışır.

Neden Full Recovery Model Zorunlu?

Bu zorunluluk, Always On’un temelde nasıl çalıştığıyla doğrudan ilgilidir. Always On Availability Group, veritabanını ikincil replikalara kopyalamak için transaction log kayıtlarını kullanır: birincil replikada yapılan her değişiklik önce log’a yazılır, bu log kayıtları ikincil replikalara gönderilir ve orada yeniden uygulanır (redo). Yani senkronizasyonun taşıyıcısı, veritabanının transaction log zinciridir.

Full Recovery Model’in kritik özelliği, tüm işlemleri eksiksiz biçimde log’a kaydetmesi ve bu kayıtların yalnızca transaction log backup alındığında temizlenmesidir. Böylece log zinciri kesintisiz kalır ve Always On, ikincil replikaya göndermesi gereken hiçbir kaydı kaybetmez.

Buna karşılık Simple Recovery Model‘de transaction log kayıtları her checkpoint sonrası otomatik olarak silinir. Bu durumda gönderilmeyi bekleyen log kayıtları ortadan kalkabileceği için ikincil replikayı birincil ile tutarlı halde tutmak imkansız hale gelir. İşte bu nedenle Always On, Simple veya Bulk-Logged model ile çalışamaz; kesintisiz bir log zinciri sağlayan tek model Full Recovery’dir.

Recovery Model Türleri

• Simple Recovery: Transaction log kayıtları checkpoint işleminden sonra otomatik olarak silinir. Log yönetimi kolaydır ancak transaction log yedekleri alınamaz ve point-in-time restore mümkün değildir. Bir felaket senaryosunda veritabanı en iyi ihtimalle son Full veya Differential backup’a kadar geri döndürülebilir. Always On için kullanılamaz.
• Full Recovery: Gerçekleştirilen tüm işlemler transaction log dosyasına kaydedilir ve manuel müdahale edilmedikçe silinmez. Veritabanı belirli bir zamana kadar restore edilebilir. Always On Availability Group mimarisi ile uyumlu tek recovery modelidir. Full Recovery Model’de transaction log yönetimi yöneticinin sorumluluğundadır. Log dosyalarının kontrolsüz büyümemesi için düzenli aralıklarla transaction log backup alınması gerekmektedir.
• Bulk-Logged Recovery: Full Recovery’ye benzer çalışır; ancak bulk işlemler sırasında her işlem için ayrı log kaydı oluşturmak yerine tek bir toplu kayıt yazılır. Bulk işlem içeren zaman aralığına point-in-time restore yapılamaz. Kalıcı bir çözüm değildir; yalnızca bulk işlem öncesi geçici olarak kullanılıp sonrasında Full’e dönülmelidir.

OK seçeneğine tıklayarak veritabanı oluşturma işlemini başlatıyoruz.

BAKICUBUKDB veritabanın oluşturulduğunu görüyoruz.

Full Backup (Zorunlu Ön Koşul)

Always On Availability Group yapılandırması öncesinde veritabanının Full Backup‘ının alınması zorunludur. Aksi halde veritabanı Availability Group’a eklenemez ve Full backup is required hatası alınır.

Bunun nedeni, Always On’un ikincil replikayı birincil ile aynı noktadan başlatabilmesi için veritabanının kesintisiz bir kurtarma zincirine (recovery chain) ihtiyaç duymasıdır. Bu zincir yalnızca veritabanının en az bir kez Full Backup’ı alındığında başlar; henüz hiç yedeği alınmamış bir veritabanının zinciri başlamadığı için Availability Group’ye dahil edilemez. (Bu mekanizmayı birazdan Veritabanı Seçimi bölümünde daha ayrıntılı ele alacağız.)

Aşağıdaki ekranda, henüz yedeği alınmamış BAKICUBUKDB veritabanı için sihirbazın Status sütununda bu uyarının nasıl göründüğünü görüyoruz:

Status mesajının üzerine geldiğimizde, uyarının ayrıntısında veritabanının Availability Group’ye eklenebilmesi için önce tam bir yedeğinin alınması gerektiği belirtilir.

Bu ön koşul sağlanmadığı sürece Next ile bir sonraki adıma geçemeyiz; bu nedenle önce Full Backup işlemini gerçekleştireceğiz.

BAKICUBUKDB veritabanı üzerinde sağ tıklayıp Tasks → Back Up… seçeneğini seçiyoruz.

Back Up Database ekranında:

• Backup Type: Full
• Back up to: Disk
• Destination: H:\BACKUP (Bölüm 2‘de yapılandırdığımız varsayılan backup dizini)

OK ile Full Backup işlemini başlatıyoruz.

Full Backup işleminin başarıyla tamamlandığını görüyoruz.

T-SQL alternatifi:

BACKUP DATABASE [BAKICUBUKDB]
TO DISK = N'H:\BACKUP\BAKICUBUKDB_Full.bak'
WITH INIT, COMPRESSION, STATS = 10;
GO

Automatic Seeding İzni

Automatic Seeding yöntemi, secondary replica’daki veritabanlarını manuel backup/restore işlemine gerek kalmadan, ağ üzerinden otomatik olarak oluşturur. Bunu yapabilmesi için Availability Group’un, secondary replica üzerinde veritabanı oluşturma iznine sahip olması gerekir. Bu izin verilmezse seeding Failed durumunda kalır, veritabanı secondary üzerinde hiç oluşmaz ve tipik olarak "The connection to the primary replica is not active" benzeri bir hata alınır.

Bu nedenle, Availability Group oluşturulduktan hemen sonra aşağıdaki izni her iki node üzerinde veriyoruz:

AG oluşturulduktan SONRA, her iki node üzerinde çalıştırılır:

ALTER AVAILABILITY GROUP [SQL25HAG]
GRANT CREATE ANY DATABASE;
GO

Seeding tamamlandıktan sonra, güvenlik açısından bu izin geri alınabilir:

ALTER AVAILABILITY GROUP [SQL25HAG]
DENY CREATE ANY DATABASE;
GO

Seeding Durumunu İzleme

SELECT
    ag.name AS AG_Name,
    ar.replica_server_name,
    DB_NAME(dbcs.database_id) AS DatabaseName,
    dbcs.synchronization_state_desc,
    phs.internal_state_desc,
    phs.failure_state_desc
FROM sys.dm_hadr_automatic_seeding phs
JOIN sys.availability_groups ag ON phs.ag_id = ag.group_id
JOIN sys.availability_replicas ar ON phs.ag_remote_replica_id = ar.replica_id
LEFT JOIN sys.dm_hadr_database_replica_cluster_states dbcs
    ON dbcs.group_database_id = phs.ag_db_id;

Servis Hesabı Endpoint İzni

Always On Availability Group’ta replikalar birbirleriyle database mirroring endpoint’i (Hadr_endpoint) üzerinden haberleşir. Senkronizasyon trafiğinin akabilmesi için, her node’un SQL Server servis hesabının karşı node’un endpoint’ine bağlanabilmesi gerekir. Bu nedenle her sunucuda, karşı node’un servis hesabı için bir login oluşturup bu endpoint’e CONNECT izni veririz.

Örneğin Node1 üzerinde, Node2’nin servis hesabı (sqlsvc_nod2) için aşağıdaki komutları çalıştırırız:

CREATE LOGIN [BAKICUBUK\sqlsvc_nod2] FROM WINDOWS;
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [BAKICUBUK\sqlsvc_nod2];
GO

Komutların yaptığı işi adım adım açıklayalım:

• CREATE LOGIN [BAKICUBUK\sqlsvc_nod2] FROM WINDOWS; – Node2’nin Windows servis hesabı için bu instance üzerinde bir login (giriş kaydı) oluşturur. Bu adım yalnızca hesabı tanıtır; henüz herhangi bir yetki vermez.
• GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] ... – Oluşturulan bu login’e, Always On’un replikalar arası iletişim için kullandığı Hadr_endpoint üzerinden bağlanma izni verir. Bu izin olmadan karşı node senkronizasyon trafiğini iletemez.

Aynı işlemi Node2 üzerinde, bu kez Node1’in servis hesabı (sqlsvc_nod1) için tekrarlayın. Böylece iki yönlü iletişim (Node1 → Node2 ve Node2 → Node1) sağlanmış olur:

CREATE LOGIN [BAKICUBUK\sqlsvc_nod1] FROM WINDOWS;
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [BAKICUBUK\sqlsvc_nod1];
GO

Endpoint’lerin doğru oluştuğunu doğrulamak için:

SELECT name, protocol_desc, type_desc, state_desc, role_desc
FROM sys.database_mirroring_endpoints;

SELECT e.name, e.port, e.protocol_desc
FROM sys.tcp_endpoints e
WHERE e.type_desc = 'DATABASE_MIRRORING';

New Availability Group Wizard

Always On High Availability bölümüne sağ tıklayarak New Availability Group Wizard seçeneğini seçiyoruz.

Introduction ekranında Availability Group oluşturma sürecinde izlenecek aşamaları görüyoruz:

• Specify an availability group name and other options – Benzersiz AG adı ve temel davranış seçenekleri
• Select one or more user databases – AG’ye dahil edilecek kullanıcı veritabanları (Full Recovery Model’de ve Full Backup alınmış olmalı)
• Specify one or more instances of SQL Server to host secondary availability replicas – Secondary replica’ların yer alacağı instance’lar (aynı WSFC yapısına üye olmalı)
• Specify your availability group listener preference – İstemci bağlantılarının yönlendirileceği Listener
• Select your initial data synchronization preference – İlk veri eşitleme yöntemi
• Check the validation results – Ön gereksinim kontrolleri
• Review your selections – Son kontrol

Introduction ekranında Next ile devam ediyoruz.

Availability Group Seçenekleri

Specify Availability Group Options ekranında Availability Group name alanına benzersiz ve anlamlı bir isim belirliyoruz.

Cluster Type

Cluster type bölümünde üç seçenek bulunur:

• Windows Server Failover Cluster (WSFC): Windows üzerinde çalışan SQL Server kurulumlarında High Availability, Automatic Failover, Health Monitoring ve Resource Management WSFC tarafından sağlanır. Windows ortamlarında Always On mimarisinin temel yapı taşıdır.
• EXTERNAL: Linux ortamlarında Pacemaker kullanılarak yapılandırılır. Automatic Failover sağlamak amacıyla tercih edilir; failover kararları ve kaynak yönetimi Pacemaker tarafından kontrol edilir.
• NONE: Pacemaker kullanılmaz. Read Scale senaryoları ve Manual Failover gereksinimleri için uygundur. Automatic Failover desteği bulunmaz.

Diğer Seçenekler

• Database level health detection: Veritabanı seviyesinde oluşan bozulmaların tespit edilerek failover kararlarına dahil edilmesini sağlar. Yalnızca sunucu kaynaklı problemler değil, veritabanı bütünlüğünü etkileyen hatalar da Automatic Failover süreçlerine dahil edilir.
• Per Database DTC Support: Dağıtık işlemler (Distributed Transaction Coordinator) için veritabanı seviyesinde destek sağlar. Failover sonrasında dağıtık işlemlerin tutarlılığı korunur.
• Contained: Contained Availability Group, veritabanlarının yanı sıra SQL Server Agent Jobs, logins ve msdb bağımlılıklarının da AG kapsamında tutulmasını sağlar. Failover sonrasında yeni Primary Replica üzerinde manuel müdahale ihtiyacını azaltır.

Availability Group name alanına benzersiz ve anlamlı bir isim belirliyoruz Cluster type bölümünde Windows Server Failover Cluster seçeneğini seçiyoruz ve Next ile devam ediyoruz.

Veritabanı Seçimi

Select Databases ekranında AG yapısına dahil edilecek veritabanlarını seçiyoruz. Status sütunu, seçtiğimiz her veritabanının ön koşulları sağlayıp sağlamadığını gösterir; bir veritabanı ancak Meets prerequisites durumundaysa AG’ye eklenebilir.

Burada sık karşılaşılan Full backup is required uyarısının nedeni şudur: Always On, secondary replica’yı primary ile aynı noktadan başlatabilmek için veritabanının kesintisiz bir kurtarma zincirine (recovery chain / LSN zinciri) sahip olmasını bekler. Bu zincir ancak veritabanının en az bir kez Full Backup‘ı alındığında başlar. Yeni oluşturulmuş, henüz hiç yedeği alınmamış bir veritabanının recovery zinciri başlamadığı için sihirbaz bu aşamada onu AG’ye eklemenize izin vermez ve Status sütununda bu uyarıyı gösterir. Bu nedenle bir önceki adımda Full Backup işlemini gerçekleştirmiştik; yedek alındıktan sonra aynı ekranda durum Meets prerequisites olarak güncellenir.

Status sütununda görülebilecek başlıca mesajlar ve anlamları:

Meets prerequisites ifadesine tıkladığımızda detaylı bilgilendirme ekranını görüyoruz.

BAKICUBUKDB veritabanını seçiyoruz ve Next ile devam ediyoruz.

Replica Yapılandırması

Specify Replicas ekranında Replicas sekmesinde W25SQL25NOD1 sunucumuzun Initial role alanında Primary olarak tanımlandığını görüyoruz.

Add Replica seçeneğine tıklayarak W25SQL25NOD2 sunucumuzu Secondary olarak ekleme işlemine başlıyoruz.

Connect to Server ekranında W25SQL25NOD2 sunucusuna bağlantı sağlıyoruz.

Her iki replica’nın da eklendiğini görüyoruz: W25SQL25NOD1 → Primary, W25SQL25NOD2 → Secondary.

Automatic Failover

Automatic Failover (Up to 5) seçeneğini işaretliyoruz. Bu yapılandırma ile W25SQL25NOD1 üzerinde bir sorun oluşması durumunda W25SQL25NOD2 üzerine otomatik yük devretme gerçekleşir.

Availability Mode

• Asynchronous commit: Primary Replica, transaction log kayıtlarını Secondary’ye gönderir ancak işlemin tamamlanması için onay beklemez. Ağ gecikmesinin yüksek olduğu uzak lokasyonlarda tercih edilir; Disaster Recovery senaryoları için uygundur.
• Synchronous commit: Primary Replica, işlemi tamamlamadan önce Secondary’den onay bekler. Onay alındıktan sonra işlem istemciye başarılı olarak döner. Veri kaybını önlemeyi hedefleyen High Availability senaryolarında tercih edilir.

Readable Secondary

• No: Secondary replica yalnızca senkronizasyon amacıyla kullanılır, okuma bağlantılarını kabul etmez.
• Yes: Secondary replica hem normal okuma bağlantılarını hem de raporlama sorgularını kabul eder.
• Read-intent only: Secondary replica yalnızca ApplicationIntent=ReadOnly parametresi ile gelen bağlantıları kabul eder. Okuma ve yazma iş yüklerinin ayrıştırılmasını sağlar; Listener üzerinden yönlendirilen okuma trafiği için en çok tercih edilen senaryodur.

Required Synchronized Secondaries to Commit

Bu ayar, Synchronous Commit modunda çalışan işlemlerin tamamlanabilmesi için kaç adet Secondary Replica’nın senkronize olup onay vermesi gerektiğini belirler.

Ayar etkinleştirildiğinde, Primary Replica bir işlemi tamamlamadan önce belirlenen sayıda Secondary Replica’dan commit onayı bekler.

Endpoints sekmesine geçerek devam ediyoruz.

Endpoints

Endpoints sekmesinde varsayılan ayarlarda değişiklik yapmıyoruz. Varsayılan yapılandırma, tek instance kullanılan ortamlarda Always On iletişimi için yeterlidir.

• Endpoint Name: Replikalar arasındaki veri iletişimini sağlayan Database Mirroring Endpoint için tanımlanan isimdir
• Encrypt Data: Replikalar arasında taşınan verinin şifrelenmesini sağlar. Varsayılan ve önerilen ayar Yes‘tir; güvenlik açısından kapatılması tavsiye edilmez
• SQL Server Service Account: Endpoint’in hangi servis hesabı ile çalışacağını belirtir. Tüm replikalarda servis hesabının doğru yetkilere sahip olması gerekir

• Endpoint Name: Replikalar arasındaki veri iletişimini sağlayan Database Mirroring Endpoint için tanımlanan isimdir
• Encrypt Data: Replikalar arasında taşınan verinin şifrelenmesini sağlar. Varsayılan ve önerilen ayar Yes‘tir; güvenlik açısından kapatılması tavsiye edilmez

SQL Server Service Account: Endpoint’in hangi servis hesabı ile çalışacağını belirtir. Tüm replikalarda servis hesabının doğru yetkilere sahip olması gerekir

Backup Preferences sekmesine geçerek devam ediyoruz.

Backup Preferences

Backup Preferences sekmesinde yedekleme işlemlerinin hangi replica üzerinden gerçekleştirileceğini belirliyoruz:

• Prefer Secondary: Aktif bir Secondary Replica varsa yedekleme öncelikli olarak onun üzerinden alınır. Yoksa Primary kullanılır.
• Secondary only: Tüm otomatik yedeklemeler yalnızca Secondary üzerinden alınır. Primary üzerindeki I/O yükünü azaltmak için tercih edilir.
• Primary: Tüm yedeklemeler yalnızca Primary üzerinden gerçekleştirilir.
• Any Replica: Yedekleme hem Primary hem Secondary üzerinden alınabilir.

Ayrıca her replica için:

• Backup Priority: Yedekleme önceliği (yüksek değer = yüksek öncelik)
• Exclude Replica: İlgili replica’yı otomatik yedekleme işlemlerinden tamamen hariç tutar

Any Replica seçeneğini seçiyoruz ve Listener sekmesine geçerek devam ediyoruz.

Listener Yapılandırması

Listener Nedir

Availability Group yapısında birden fazla SQL Server bulunur ve veritabanı o anda hangi sunucuda aktif (Primary Replica) 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 ve buna karşılık gelen bir Listener IP Address içerir. Uygulamalar (Logo Tiger, Logo Bordro, Mikro, Eta, Nebim, Canias 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.

Yapılandırma Seçenekleri

• Do not create an availability group listener now: Listener yapılandırmasını kurulum sonrasında manuel olarak gerçekleştirebilirsiniz
• Create an availability group listener: Listener’ı bu sihirbaz sırasında oluşturarak yapılandırmayı tek adımda tamamlayabilirsiniz

Create an availability group listener seçeneğini işaretliyoruz:

• Listener DNS Name: Uygulamaların kullanacağı tek ve sabit bağlantı noktası
• Port: Uygulamaların bağlanacağı SQL Server portu
• Network Mode: Static IP – Failover senaryolarında IP adresi değişmeden aktif SQL Server’a otomatik yönlendirme sağlar

Network Mode alanını Static IP olarak seçtikten sonra Add seçeneğine tıklıyoruz.

IP Adresi Tanımlama

Add IP Address ekranında Subnet bölümü, Listener IP adresinin hangi ağ segmenti üzerinde çalışacağını belirtir.

Ortamımızda iki subnet görünüyor:

• 192.168.2.0/24 – Failover Cluster yapısında Cluster Only olarak tanımlanmış ağ. Yalnızca node’lar arası cluster iletişimi (heartbeat) için kullanılır; istemci erişimine kapalıdır. SQL Listener bu subnet üzerinden yayınlanamaz.
• 192.168.1.0/24 – Cluster and Client olarak yapılandırılmış ağ. Hem cluster içi iletişim hem de istemci bağlantıları için kullanılır. SQL Listener erişimi bu subnet üzerinden sağlanır.

IPv4 Address alanına, seçilen subnet’e uygun ve ağ üzerinde kullanılmayan bir IP adresi giriyoruz. Subnet Mask alanı, subnet seçimi yapıldıktan sonra otomatik doldurulur.

OK seçeneğine tıklıyoruz.

Network Mode bölümünün Static IP olarak yapılandırıldığını görüyoruz.

Read-Only Routing sekmesine geçerek devam ediyoruz.

Read-Only Routing

Read-Only Routing, okuma amaçlı bağlantıların otomatik olarak uygun Secondary Replica’ya yönlendirilmesini sağlayan mekanizmadır. Bu yapı sayesinde raporlama, sorgulama ve analiz gibi okuma ağırlıklı iş yükleri Primary yerine Secondary üzerinden çalıştırılabilir.

Read-Only Routing genellikle 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 üzerine otomatik yönlendirir.

Bu senaryoda varsayılan ayarlarla devam ediyoruz.

Kurulum sonrası Read-Only Routing’i T-SQL ile yapılandırmak için:

ALTER AVAILABILITY GROUP [SQL25HAG]
MODIFY REPLICA ON N'W25SQL25NOD1' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://W25SQL25NOD1.bakicubuk.local:1433'));

ALTER AVAILABILITY GROUP [SQL25HAG]
MODIFY REPLICA ON N'W25SQL25NOD2' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://W25SQL25NOD2.bakicubuk.local:1433'));

ALTER AVAILABILITY GROUP [SQL25HAG]
MODIFY REPLICA ON N'W25SQL25NOD1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'W25SQL25NOD2', N'W25SQL25NOD1')));

ALTER AVAILABILITY GROUP [SQL25HAG]
MODIFY REPLICA ON N'W25SQL25NOD2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'W25SQL25NOD1', N'W25SQL25NOD2')));

Specify Replicas ekranındaki sekmelerde gerekli yapılandırmayı tamamlıyoruz ve Next ile devam ediyoruz.

Specify Cluster Connection Options (SQL Server 2025 ile Gelen Yeni Adım)

SQL Server 2025 ile birlikte New Availability Group sihirbazına, önceki sürümlerde bulunmayan yeni bir adım eklenmiştir: Specify Cluster Connection Options. Bu adım, sihirbaz sol menüsünde Specify Replicas ile Select Data Synchronization arasında yer alır.

Bu ekran, Windows Server Failover Cluster (WSFC) ile Availability Group replikaları arasındaki iletişim için şifreleme (encryption) davranışını belirler. Arka planda, CLUSTER_CONNECTION_OPTIONS clause’unu yapılandırarak replikalar arası trafikte TLS 1.3 şifrelemesinin nasıl uygulanacağını kontrol eder. Bu yetenek, SQL Server 2025’in getirdiği TDS 8.0 desteğinin bir parçasıdır.

Encryption açılır listesinde üç seçenek bulunur:

Specify Cluster Connection Options – Encryption seçenekleri

• Mandatory: Replikalar arası tüm iletişim şifrelenir. Bu, SQL Server 2025’te Always On için varsayılan davranıştır. Bu modda, ortamda geçerli bir sertifika zinciri yoksa Trust server certificate seçeneği işaretlenerek self-signed (kendinden imzalı) sertifikalara güvenilmesi sağlanabilir.
• Optional: Şifreleme zorunlu tutulmaz. Şifreli bağlantı kurulabiliyorsa kurulur, kurulamıyorsa şifresiz bağlantıya izin verilir. En esnek, ancak güvenlik açısından en zayıf seçenektir.
• Strict (Minimum SQL 2025): En yüksek güvenlik seviyesidir ve yalnızca TDS 8.0 üzerinden TLS 1.3 ile bağlanmaya izin verir. Bu modda TrustServerCertificate yok sayılır; dolayısıyla her replikaya geçerli bir TLS sertifikasının önceden import edilmiş olması zorunludur. Adından da anlaşılacağı gibi tüm replikaların en az SQL Server 2025 olmasını gerektirir.

Bu kurulumda, laboratuvar ortamında ilerlediğimiz için Mandatory seçeneğini seçiyor ve self-signed sertifika kullanıldığından Trust server certificate kutusunu işaretliyoruz. Bu seçimde Host name in certificate ve Server certificate alanları pasif kalır; bu alanlar yalnızca Strict senaryosunda, belirli bir sertifikayı doğrulamak istediğinizde devreye girer.

Specify Cluster Connection Options – Mandatory ve Trust server certificate

Seçimi yaptıktan sonra Next ile Select Data Synchronization adımına geçiyoruz.

Initial Data Synchronization

Select Initial Data Synchronization ekranında Secondary Replica veritabanlarının ilk kez nasıl senkronize edileceği belirlenir.

• Automatic seeding: Senkronizasyon için gerekli tüm işlemler otomatik gerçekleştirilir. Ek bir paylaşım alanına veya manuel işleme ihtiyaç duyulmaz.
• Full database and log backup: Her veritabanının Full ve Transaction Log yedekleri, önceden yapılandırılmış bir Share (Paylaşım) üzerinden alınarak Secondary’ye aktarılır. SQL Server servis hesaplarının ilgili paylaşım üzerinde Read ve Write yetkilerine sahip olması gerekir.
• Join only: Full ve Transaction Log yedeklerinin manuel olarak alınmış, Secondary’ye kopyalanmış ve veritabanlarının RESTORING durumunda hazır hale getirilmiş olması gerekir.
• Skip initial data synchronization: Senkronizasyon işlemleri daha sonra manuel olarak yapılır.

Automatic seeding seçeneği işaretlenmiş haliyle ekran aşağıdaki gibi görünür; bu seçimle secondary replica veritabanları, ağ üzerinden otomatik olarak oluşturulup senkronize edilecektir:

Automatic seeding seçeneğini seçiyoruz ve Next ile devam ediyoruz.

Validation ve Kurulum

Validation ekranında Availability Group kurulumu için gerekli tüm kontroller otomatik olarak gerçekleştirilir. Tüm adımların Success olarak görünmesi, kurulumun sorunsuz ilerleyebileceğini gösterir.

Herhangi bir problem olsaydı ilgili adımlar Error olarak görüntülenirdi. Bu durumda Previous ile geri dönüp düzeltme yapabilir, ardından Re-run validation ile kontrolleri yeniden çalıştırabilirsiniz.

Summary ekranında gerçekleştirilen tüm yapılandırma adımlarının özet bilgilerini görüyoruz.

Script bölümünden, oluşturduğumuz yapılandırmayı T-SQL script olarak alabiliriz. Bu script ileride benzer kurulumlar yapmak, dokümantasyon oluşturmak veya yapılandırmayı yeniden uygulamak için kullanılabilir.

Finish seçeneğine tıklayarak kurulum işlemini başlatıyoruz.

Progress ekranında Availability Group yapısının kurulduğunu görüyoruz.

Results ekranında Availability Group yapısının başarıyla kurulduğunu görüyoruz. Close ile sihirbazı kapatıyoruz.

Kurulum Doğrulama

W25SQL25NOD1 (Primary) Üzerinde

Databases bölümünde BAKICUBUKDB veritabanının Synchronized durumunda olduğunu görüyoruz.

Always On High Availability → Availability Groups altında SQL25HAG isimli Availability Group yapısının oluşturulduğunu görüyoruz.

Availability Replicas bölümünde W25SQL25NOD1 → Primary, W25SQL25NOD2 → Secondary olarak yapılandırıldığını görüyoruz.

Availability Databases bölümünde BAKICUBUKDB veritabanının Availability Group’ye dahil edildiğini görüyoruz.

Availability Listeners bölümünde SQL25AO isimli Listener’ın oluşturulduğunu görüyoruz.

Failover Cluster Manager konsolunda Roles menüsü altında SQL25HAG Availability Group yapısının cluster rolü olarak eklendiğini görüyoruz.

W25SQL25NOD2 (Secondary) Üzerinde

W25SQL25NOD2 sunucusu üzerinde BAKICUBUKDB veritabanının Synchronized durumunda olduğunu görüyoruz. Bu, veritabanının Primary ve Secondary arasında senkronize çalıştığını ve yapının sağlıklı olduğunu doğrular.

Always On High Availability → Availability Groups altında SQL25HAG isimli Availability Group yapısının oluşturulduğunu görüyoruz.

Availability Replicas bölümünde W25SQL25NOD1 → Primary, W25SQL25NOD2 → Secondary olarak yapılandırıldığını görüyoruz.

Availability Databases bölümünde BAKICUBUKDB veritabanının Availability Group’ye dahil edildiğini görüyoruz.

Availability Listeners bölümünde SQL25AO isimli Listener’ın oluşturulduğunu görüyoruz.

Availability Group Dashboard

Availability Groups altında SQL25HAG üzerinde sağ tıklayarak Show Dashboard seçeneğini seçiyoruz.

Availability Group Dashboard ekranı, Always On yapısının anlık sağlık durumunu tek bir yerden izlemenizi sağlar:

• Primary ve Secondary Replica 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

Doğrulama ve Failover Testi

1. Listener Bağlantı Testi

Uygulamalar Listener üzerinden bağlanacağı için, Listener’ın çalıştığını doğrulamak kritiktir.

DNS kaydını doğrulayın:

nslookup SQL25AO.bakicubuk.local

Komut, Listener DNS adının doğru IP adresine çözümlendiğini gösterir:

C:\Users\administrator.BAKICUBUK>nslookup SQL25AO.bakicubuk.local
Server:  UnKnown
Address:  192.168.1.200

Name:    SQL25AO.bakicubuk.local
Address:  192.168.1.214

Bu çıktıyı satır satır okuyalım:

• Address: 192.168.1.200 – Sorgunun gönderildiği DNS sunucusunun IP adresidir; bu genellikle Domain Controller’dır. Yani sorgumuzu hangi sunucuya sorduğumuzu buradan görüyoruz.
• Server: UnKnown – nslookup, sorguyu gönderdiği DNS sunucusunun (192.168.1.200) adını çözemediği için bu satırda UnKnown yazar. Bunun nedeni, o DNS sunucusunun IP adresi için bir ters DNS kaydının (reverse lookup / PTR) tanımlı olmamasıdır. nslookup çalışırken önce hedef adı sorgulamadan, kullandığı DNS sunucusunun IP’sini ada çevirmeye çalışır; PTR kaydı yoksa adını bulamaz ve UnKnown gösterir. Bu tamamen normaldir, bir hata değildir ve Listener’ın çalışmasını etkilemez. İstenirse ilgili subnet için Reverse Lookup Zone ve DC’ye ait PTR kaydı oluşturularak bu satırda sunucu adının görünmesi sağlanabilir.
• Name / Address (alt blok) – Asıl önemli olan sonuçtur: SQL25AO.bakicubuk.local adı 192.168.1.214 adresine çözümlenmiştir. Bu IP, Listener yapılandırmasında tanımladığımız Listener IP adresidir; dolayısıyla Listener DNS kaydı doğru şekilde oluşmuştur.

SSMS ile Listener üzerinden bağlanın:

Server Name alanına sunucu adı yerine SQL25AO yazarak bağlanın. Ardından hangi node’a bağlandığınızı doğrulayın:

SELECT @@SERVERNAME AS BagliOlunanSunucu;

Bu sorgu W25SQL25NOD1 döndürmelidir (mevcut Primary).

2. AG Sağlık Durumu Sorguları

Replica durumları ve senkronizasyon sağlığı

SELECT
    ag.name AS AG_Name,
    ar.replica_server_name,
    ars.role_desc,
    ars.connected_state_desc,
    ars.synchronization_health_desc,
    ar.availability_mode_desc,
    ar.failover_mode_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id;

Veritabanı senkronizasyon durumu ve gecikme

SELECT
    DB_NAME(drs.database_id) AS DatabaseName,
    ar.replica_server_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id;

Sorgu, her replikanın veritabanı bazında senkronizasyon durumunu ve gecikmesini gösterir.

Örnek bir çıktı şu şekildedir:

Burada dikkat çeken nokta, W25SQL25NOD1 satırındakilog_send_queue_size ve redo_queue_size sütunlarının NULL olmasıdır. Bu bir hata değildir; aksine yapının sağlıklı olduğunu gösterir. Nedenini açıklayalım:

• log_send_queue_size primary’den secondary’ye gönderilmeyi bekleyen, redo_queue_size ise secondary’de henüz uygulanmayı (redo) bekleyen log miktarını ölçer. Her iki metrik de tanımı gereği yalnızca secondary replica için anlamlıdır.
• Sorgunun çalıştığı an W25SQL25NOD1 primary rolündedir. Primary kendi kendine log göndermediği veya redo yapmadığı için bu iki sütun primary satırında NULL döner. Bu, “değer eksik” değil, “bu metrik bu rol için uygulanmaz” anlamına gelir.
• W25SQL25NOD2 ise o an secondary’dir; değerlerinin 0 olması, gönderilmeyi veya uygulanmayı bekleyen hiçbir log olmadığını, yani replikalar arasında gecikme (lag) bulunmadığını gösterir. Senkronizasyon anlıktır.

Nitekim her iki satırda da durumun SYNCHRONIZED ve sağlığın HEALTHY olması, Availability Group’un tam anlamıyla sağlıklı çalıştığını doğrular. Failover sonrası bu sorguyu tekrar çalıştırırsanız, NULL değerlerin bu kez rol değiştiren diğer node’a (yeni primary’ye) geçtiğini görürsünüz.

Listener bilgileri

SELECT agl.dns_name, agl.port, agl.ip_configuration_string_from_cluster
FROM sys.availability_group_listeners agl;

3. Manual Failover Testi

1. Manual (planlı) failover, veri kaybı olmadan Primary rolünü mevcut Secondary replikaya devretmemizi sağlar. Bu test, Always On yapısının failover anında beklendiği gibi çalıştığını doğrulamanın en güvenilir yoludur. Adımları sırasıyla uyguluyoruz.Object Explorer’da Always On High Availability → Availability Groups altında SQL25HAG (Primary) üzerine sağ tıklayıp Failover… seçeneğine tıklıyoruz.

Açılan Fail Over Availability Group sihirbazının Introduction ekranı, işlemin adımlarını özetler: yeni Primary olacak Secondary replikayı seçmek, seçimleri gözden geçirmek ve failover sonucunu kontrol etmek. Next ile devam ediyoruz.

Select New Primary Replica ekranında yeni Primary olacak replikayı seçiyoruz. Ekranın üst kısmında mevcut durumu görüyoruz:

• Current Primary Replica: W25SQL25NOD1
• Primary Replica Status: Synchronous commit and Online
• Quorum Status: Normal Quorum

Listede W25SQL25NOD2 replikasını işaretliyoruz. Bu satırda Availability Mode = Synchronous commit, Failover Mode = Automatic ve Failover Readiness = No data loss değerlerini görüyoruz. Buradaki No data loss ifadesi kritiktir: senkron commit modu sayesinde failover sırasında hiçbir işlem kaybı yaşanmayacağını garanti eder.

Satırı sağa kaydırdığımızda Role sütununda hedef replikanın o an Secondary rolünde olduğunu da görebiliriz. Next ile devam ediyoruz.

Connect to Replica ekranında, yeni Primary olacak W25SQL25NOD2 replikasına bağlanmamız gerekir. Başlangıçta bağlantı durumu Not Connected görünür; sağdaki Connect… butonuna tıklıyoruz.

Açılan Connect to Server penceresinde hedef sunucuya W25SQL25NOD2 bağlanıyoruz. SQL Server 2025 ile birlikte bu pencerede Encryption varsayılan olarak Mandatory gelir; laboratuvar ortamında self-signed sertifika kullandığımız için Trust server certificate kutusu işaretli haldedir. Connect ile bağlanıyoruz.

Bağlantı başarılı olduğunda, Connected As sütununda oturum açan hesabın (BAKICUBUK\administrator) göründüğünü doğruluyoruz ve Next ile devam ediyoruz.

Summary ekranında yapılacak işlemin özetini görüyoruz: Current Primary Replica W25SQL25NOD1, New Primary Replica W25SQL25NOD2, Failover Actions No data loss ve etkilenecek veritabanı olarak BAKICUBUKDB. Seçimleri doğrulayıp Finish ile failover işlemini başlatıyoruz.

Progress ekranında failover işleminin aşamalarını canlı olarak izleyebiliriz: failover ayarlarının doğrulanması, manual failover’ın gerçekleştirilmesi, rol değişiminin tamamlanması ve WSFC quorum oy yapılandırmasının doğrulanması.

Results ekranında tüm adımların Success olarak tamamlandığını ve “The wizard completed successfully” mesajını görüyoruz. Close ile sihirbazı kapatıyoruz.

Failover sonrası doğrulama:

Bu doğrulama kritiktir: Listener’ın failover sonrası yeni Primary’ye yönlendiğini ve uygulama tarafında hiçbir değişiklik yapılmadan bağlantının devam ettiğini kanıtlar. Doğrulamayı şöyle yaparsınız:

Failover’dan önce Listener üzerinden bağlanıp çalıştırdığınız sorgu Primary olarak W25SQL25NOD1 döndürüyordu. Failover işleminden sonra, aynı Listener adına (SQL25AO) yeniden bağlanın bağlantı dizesinde, sunucu adında veya uygulama ayarlarında hiçbir şey değiştirmeden ve aynı sorguyu tekrar çalıştırın:

Listener SQL25AO üzerinden bağlıyken çalıştırın:

SELECT @@SERVERNAME AS BagliOlunanSunucu;

Aşağıdaki ekran görüntüsünde görüldüğü gibi, sorgu bu kez W25SQL25NOD2 döndürür. Object Explorer’da da SQL25HAG (Primary) artık bu node üzerinde görünür.

Listener adını hiç değiştirmediğiniz halde farklı bir node’a bağlanmış olmanız, Listener’ın istemci trafiğini otomatik olarak yeni Primary’ye yönlendirdiğini gösterir. İşte Always On’un uygulamalara sağladığı temel değer budur: failover anında uygulama yalnızca Listener adını bildiği için, arka planda hangi node’un aktif olduğunun uygulama açısından hiçbir önemi yoktur.

İsterseniz hangi node’un o an gerçekten Primary olduğunu, node’a doğrudan bağlanmadan da teyit edebilirsiniz:

AG’nin o anki Primary replica’sını gösterir

SELECT
    ag.name AS AG_Name,
    ags.primary_replica AS GuncelPrimary
FROM sys.dm_hadr_availability_group_states ags
JOIN sys.availability_groups ag ON ags.group_id = ag.group_id;

Test sonrası W25SQL25NOD1‘e geri failover yaparak ilk duruma dönün. Geri döndükten sonra aynı @@SERVERNAME kontrolünü tekrarlayarak Listener’ın bu kez yeniden W25SQL25NOD1‘e yönlendiğini doğrulayabilirsiniz.

Listener SQL25AO üzerinden bağlıyken çalıştırın:

SELECT @@SERVERNAME AS BagliOlunanSunucu;

AG’nin o anki Primary replica’sını gösterir

SELECT
    ag.name AS AG_Name,
    ags.primary_replica AS GuncelPrimary
FROM sys.dm_hadr_availability_group_states ags
JOIN sys.availability_groups ag ON ags.group_id = ag.group_id;

4. Automatic Failover Testi

Manual failover başarılıysa, otomatik failover’ı da test edin.

W25SQL25NOD1 Primary node üzerinde SQL Server servisini durduruyoruz.

Dashboard‘da rollerin otomatik değiştiğini gözlemliyoruz.

Failover geçmişini görüntüleme:

SELECT TOP 20
    ag.name,
    agc.replica_server_name,
    ags.primary_replica,
    ags.primary_recovery_health_desc
FROM sys.dm_hadr_availability_group_states ags
JOIN sys.availability_groups ag ON ags.group_id = ag.group_id
JOIN sys.dm_hadr_availability_replica_cluster_nodes agc ON agc.group_name = ag.name;

Listener üzerinden bağlantının kesintisiz devam ettiğini doğrulayın:

SELECT
    ag.name AS AG_Name,
    ags.primary_replica AS GuncelPrimary
FROM sys.dm_hadr_availability_group_states ags
JOIN sys.availability_groups ag ON ags.group_id = ag.group_id;

Sonuç

Bu beş bölümlük yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisinin kurulumunu ve yapılandırmasını baştan sona inceledik:

• Bölüm 1’de Windows Server Failover Cluster (WSFC) altyapısını kurduk
• Bölüm 2’de SQL Server 2025 kurulumunu tamamladık
• Bölüm 3’te kurulum bileşenlerini referans olarak ele aldık
• Bölüm 4’te Always On ön hazırlıklarını yaptık
• Bölüm 5’te Availability Group’u oluşturduk, Listener’ı yapılandırdık ve failover testlerini gerçekleştirdik

High Availability ve Disaster Recovery senaryolarını örnek bir mimari üzerinden, uçtan uca uyguladık.

Yeni yazılarda görüşmek dileğiyle…