Merhaba

Bu yazımızda, Microsoft SQL Server 2025 Always On Availability Group yapısına bir Database (Veritabanı)’nin Attach (Bağlama) edilmesi sürecini adım adım anlatıyor olacağız.

Daha önceki yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisini detaylı şekilde kurulumu ve yapılandırmasını anlatmıştık. 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 almıştık.

Daha önceki yazımızda

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

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

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.

ve en son yazımızda

Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4

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 almıştık.

 

Bu kapsamda, NIHATCUBUKDB isimli Database (Veritabanı)’nı mevcut Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edeceğiz.

İlk olarak, W25SQL25NOD1 isimli sunucumuz üzerinde, NIHATCUBUKDB isimli Database (Veritabanı)’ine ait SQL Server Database Primary Data File (.mdf) ve SQL Server Database Transaction Log File (.ldf) dosyalarını, Microsoft SQL Server 2025 Always On Availability Group yapısına uygun dizinler altına kopyalıyoruz.

Bu adımda, NIHATCUBUKDB.mdf isimli Primary Data File (.mdf) dosyasını, Microsoft SQL Server 2025 Always On Availability Group yapısında yapılandırılmış olan E:\DATA dizinine kopyalıyoruz.

Bu hazırlık işlemi, veritabanının sorunsuz şekilde Attach (Bağlama) edilmesi ve sonrasında Availability Group yapısına dahil edilebilmesi açısından kritik öneme sahiptir.

NIHATCUBUKDB_log isimli SQL Server Database Transaction Log File (.ldf) dosyasını, Microsoft SQL Server 2025 Always On Availability Group yapısında yapılandırılmış olan F:\LOG dizinine kopyalıyoruz.

Bu adım ile, NIHATCUBUKDB isimli Database (Veritabanı)’ine ait Transaction Log dosyası, SQL Server Always On Availability Group yapısına uygun disk yapısı altında konumlandırılmış olur. DATA ve LOG dosyalarının ayrı dizinlerde tutulması, hem performans hem de High Availability (Yüksek Erişilebilirlik) senaryolarında en iyi uygulamalardan biridir ve veritabanının sorunsuz şekilde Attach edilmesine zemin hazırlar.

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.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında BAKICUBUKDB isimli Database (Veritabanı)’in BAKICUBUKDB (Synchronized) durumunda olduğunu görüyoruz.

BAKICUBUKDB (Synchronized) durumu, veritabanının SQL Server Always On Availability Group yapısında Primary ve Secondary replikalar arasında senkronize çalıştığını ve yapının sağlıklı olduğunu gösterir.

W25SQL25NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio (SSMS) konsolununda Databases seçeneği üzerinde sağ tuş Attach… diyerek, daha önce oluşturulmuş olan NIHATCUBUKDB isimli Database (Veritabanı) için gerekli dosyaları ekliyoruz.

Bu aşamada, veritabanına ait SQL Server Database Primary Data File (.mdf) ve SQL Server Database Transaction Log File (.ldf) dosyalarını seçerek ekliyoruz. Gerekli dosyalar eklendikten sonra yapılandırmayı kontrol edip OK diyerek Attach (Bağlama) işlemini tamamlıyoruz.

Bu işlem ile NIHATCUBUKDB isimli Database (Veritabanı), W25SQL25NOD1 sunucusu üzerinde tekrar erişilebilir ve kullanılabilir hale gelir.

Attach Databases ekranında General sekmesine geldiğimizde, Database to attach bölümü karşımıza gelir.

Database to attach bölümüünde, SQL Server’a eklenecek olan veritabanının Primary Data File (.mdf) dosyası seçilir. Add seçeneğine tıklayarak NIHATCUBUKDB isimli Database (Veritabanı) ait .mdf dosyasını eklediğimizde, SQL Server ilgili veritabanını otomatik olarak tanır ve buna bağlı Transaction Log File (.ldf) dosyasını da listeye ekler. Bu sayede veritabanına ait tüm dosyalar Attach Databases ekranında görüntülenir ve ek bir işlem yapılmadan veritabanı SQL Server ortamına bağlanmaya hazır hale gelir.

Attach Databases ekranında General sekmesinde, Database to attach bölümünde Add seçeneğine tıklıyoruz.

Database to attach bölümünde Add seçeneğine tıkladığımızda, Browse For Folder penceresi açılır. Burada, NIHATCUBUKDB isimli Database (Veritabanı)’inin Primary Data File (.mdf) dosyasının bulunduğu dizini seçiyoruz. Add butonuna tıkladıktan sonra, Browse For Folder penceresinde .mdf dosyasını arıyoruz. Dosyayı bulduktan sonra seçip OK diyerek işlemi onaylıyoruz. SQL Server, veritabanına ait Primary Data File (.mdf) dosyasını ve bağlı Transaction Log File (.ldf) dosyasını otomatik olarak algılayacak ve Attach (Bağlama) işlemine devam edebilmemiz için gerekli dosyaları listeleyecektir. Bu işlem ile veritabanı dosyaları Attach Databases ekranında görülecek ve veritabanını ekleyip diyerek işlemi tamamlayabiliriz.

Locate Database Files ekranında Primary Data File için uygun dizini bulmamız gerekiyor. Burada, Microsoft SQL Server 2025 Always On Availability Group yapısındaki DATA dizinini seçiyoruz. NIHATCUBUKDB.mdf dosyasını bulmak için Browse veya manuel olarak dizin yolunu girerek bu dosyayı seçiyoruz. NIHATCUBUKDB.mdf dosyasını seçtikten sonra, OK seçeneğine tıklayarak işlemi onaylıyoruz.

Bu işlem, .mdf dosyasını Attach (Bağlama) işlemine dahil eder ve veritabanı SQL Server’a eklenmeye hazır hale gelir.

Attach Databases ekranında General sekmesi altında, Database to attach bölümünde yer alan alanları aşağıdaki şekilde görebilir ve doğrulayabilirsiniz.

• MDF File Location alanında, seçmiş olduğumuz veritabanına ait Primary Data File (.mdf) dosyasının yolu E:\DATA\NIHATCUBUKDB.mdf olarak görüntülenir. Bu, veritabanı dosyasının doğru dizinden eklendiğini gösterir.
• Database name alanında, NIHATCUBUKDB ismini görüyoruz. Bu alan, SQL Server üzerinde veritabanının hangi isimle oluşturulacağını veya ekleneceğini belirtir. Gerekli görülmesi durumunda, veritabanı adı bu alandan değiştirilebilir.
• Attach As alanında, veritabanının SQL Server’a hangi isimle Attach (Bağlama) edileceği bilgisi yer alır. Varsayılan olarak Database name ile aynı gelir ve çoğu senaryoda bu alanın değiştirilmesi gerekmez.
• Owner alanında ise veritabanının sahibi (Database Owner) bilgisi yer alır. Attach (Bağlama) işlemi sonrasında, güvenlik ve yetkilendirme açısından genellikle sa veya ilgili uygulama/DBA hesabı atanması önerilir. Bu alan kontrol edilerek ortam standartlarına uygun bir sahip atanmalıdır.

Attach Databases ekranında General sekmesi altında, Database to attach bölümünün alt kısmında Status ve Message alanları da yer alır.

• Status alanı, veritabanına ait dosyaların mevcut durumunu gösterir. Burada genellikle OK ifadesini görürüz. Bu durum, NIHATCUBUKDB isimli Database (Veritabanı) ait .mdf ve .ldf dosyalarının SQL Server tarafından sorunsuz şekilde tanındığını ve Attach (Bağlama) işlemine hazır olduğunu ifade eder.
• Message alanı ise, ilgili dosya veya veritabanı hakkında SQL Server tarafından üretilen bilgilendirme ya da uyarı mesajlarını gösterir. Herhangi bir sorun yoksa bu alan boş kalabilir veya bilgilendirici bir mesaj yer alabilir. Eğer log dosyasının bulunamaması, yol hatası ya da yetki problemi gibi bir durum söz konusuysa, hata veya uyarı mesajları bu bölümde görüntülenir.

Attach Databases ekranında General sekmesi altında, Original File Name, File Type ve Current File Path alanları dikkat çekmektedir.

• Original File Name alanında, veritabanı oluşturulurken tanımlanmış olan orijinal dosya isimleri görüntülenir. Bu alanda NIHATCUBUKDB.mdf ve NIHATCUBUKDB_log.ldf gibi veritabanına ait Primary Data File ve Transaction Log File isimlerini görebiliriz. SQL Server, Attach (Bağlama) işlemi sırasında bu orijinal dosya isimlerine göre dosyaları eşleştirmeye çalışır.
• File Type alanı, ilgili dosyanın türünü belirtir. Burada ROWS ifadesi Primary Data File (.mdf) dosyasını, LOG ifadesi ise Transaction Log File (.ldf) dosyasını temsil eder. Bu bilgi, veritabanı dosyalarının hangi amaçla kullanıldığını net bir şekilde ayırt etmemizi sağlar.
• Current File Path alanında ise, Attach (Bağlama) işlemi sırasında SQL Server’ın ilgili dosyayı aradığı veya dosyanın mevcut olduğu dizin yolu görüntülenir. Eğer Transaction Log File (.ldf) dosyası bu belirtilen dizinde bulunamazsa, Status ve Message alanlarında hata mesajları görüntülenir. Bu durumda doğru dizin yolu gösterilmeli ya da log dosyası yeniden oluşturulmalıdır.

Attach Databases ekranında General sekmesine baktığımızda, Original File Name bölümü altında NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File (.ldf) dosyasının bulunduğu için herhangi bir hata görmüyoruz. Eğer NIHATCUBUKDB_log.ldf isimli SQL Server Database Transaction Log File (.ldf) dosyasını dizininde bulunmasaydı Message bölümünde ilgili dosyanın eksik olduğuna dair bir hata mesajı görüntülenir.

Bu durumda iki farklı çözüm yolu bulunmaktadır:

1. İlk seçenek olarak, NIHATCUBUKDB_log.ldf dosyasının mevcut olduğu doğru dizini SQL Server’a gösterebilirsiniz. Eğer log dosyası farklı bir klasörde bulunuyorsa, ilgili dosya yolunu belirterek Attach (Bağlama) işlemini bu şekilde tamamlayabilirsiniz.
2. İkinci seçenek olarak ise, NIHATCUBUKDB_log.ldf dosyasını SQL Server tarafından yeniden oluşturabilirsiniz. Bunun için Attach (Bağlama) işlemi sırasında eksik log dosyasının yeniden yaratılmasına izin verilir ve SQL Server, veritabanını yeni bir Transaction Log File (.ldf) ile ayağa kaldırır. Bu yöntem genellikle log dosyasının kaybolduğu veya erişilemediği senaryolarda tercih edilir.

Attach Databases ekranında gerekli kontroller yapıldıktan sonra OK seçeneğini ile Attach (Bağlama) işlemini tamamlıyoruz ve NIHATCUBUKDB isimli Database (Veritabanı)’i tekrar kullanılabilir hale getiriyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında, NIHATCUBUKDB isimli Database (Veritabanı)’nin Attach (Bağlama) işlemi sonrasında W25SQL25NOD1 isimli sunucumuz üzerine başarıyla geldiğini görüyoruz.

Bu aşama, veritabanına ait .mdf ve (varsa) .ldf dosyalarının SQL Server tarafından doğru şekilde tanındığını, Attach (Bağlama) işleminin hatasız tamamlandığını ve NIHATCUBUKDB isimli Database (Veritabanı)’in artık aktif olarak kullanılabilir durumda olduğunu gösterir. Bundan sonraki adımda, veritabanı durumunu (Online), yetkilendirmeleri (Database Owner / User Mapping) ve Always On gibi ileri seviye yapılandırmaları kontrol ederek ortam standartlarına uygunluğu doğrulayabilirsiniz.

Microsoft SQL Server Management Studio (SSMS) konsolu ile W25SQL25NOD2 isimli sunucumuz üzerine bağlantı sağlıyoruz.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında, NIHATCUBUKDB isimli Database (Veritabanı)’nin Attach (Bağlama) işlemi sonrasında W25SQL25NOD2 isimli sunucumuz üzerinde listelenmediğini / bulunmadığını görüyoruz.

W25SQL25NOD1 isimli sunucumuz üzerinde NIHATCUBUKDB isimli Database (Veritabanı)’ni Attach (Bağlama) işleminden sonra Microsoft SQL Server 2025 Always On Availability Group yapısına dahil etmeden önce bazı ön hazırlık adımlarını tamamlamamız gerekmektedir.

Öncelikle, NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarının Full olarak yapılandırılması zorunludur. SQL Server Always On Availability Group, Full Recovery Model ile çalışan veritabanlarını destekler ve bu yapı, transaction log’ların eksiksiz tutulmasını sağlayarak High Availability (Yüksek Erişebilirlik) ve veri tutarlılığı sunar.

Eğer NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarı Full olarak yapılandırılmazsa, New Availability Group Wizard içerisinde yer alan Select Databases ekranında Availability Group’a dahil etmek istediğimiz NIHATCUBUKDB isimli Database (Veritabanı)’in Status bölümünde Full recovery mode is required hatasını alırız. Bu durumda veritabanı SQL Server Always On Availability Group’a eklenemez.

Bu nedenle, SQL Server Always On Availability Group yapılandırmasına geçmeden önce NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarının Full olduğunun doğrulanması ve gerekirse bu şekilde yapılandırılması kritik bir adımdır.

Select Databases ekranında NIHATCUBUKDB isimli veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına eklemek istediğimizde, Status sütununda Full recovery mode is required uyarısını görüyoruz. Bu uyarı, ilgili veritabanının Always On mimarisi için gerekli olan ön koşulları sağlamadığını göstermektedir.

SQL Server Always On Availability Group, veritabanları arasındaki senkronizasyonu Transaction Log üzerinden gerçekleştiren bir High Availability (Yüksek Erişilebilirlik) mimarisidir. Bu nedenle, sisteme dahil edilecek tüm veritabanlarının Recovery Model ayarının Full olması zorunludur. Simple veya Bulk-Logged recovery model ile çalışan veritabanları, işlem günlüklerini sürekli ve eksiksiz şekilde tutmadığı için Always On yapısına dahil edilemez.

Ekranda ayrıca açılan uyarı penceresinde, veritabanının Availability Group’a eklenebilmesi için Recovery Model ayarının Full olarak yapılandırılması gerektiği ve bu işlemden sonra mutlaka Full veya Differential Backup alınması gerektiği belirtilmektedir. Bunun yanı sıra, transaction log zincirinin korunabilmesi için düzenli Log Backup planlarının da aktif olması gerekir.

Özetle, NIHATCUBUKDB isimli Database (Veritabanı)’i Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için önce Full Recovery Model yapılandırılmalı, ardından gerekli yedekleme işlemleri tamamlanmalıdır. Bu adımlar gerçekleştirilmeden veritabanı Always On ortamına eklenemez ve Select Databases ekranında seçim yapılamaz.

NIHATCUBUKDB isimli Database (Veritabanı)’nı Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için, Recovery Model ayarının Full olarak yapılandırılmasının ardından mutlaka Full Backup alınması gerekmektedir.

Always On mimarisinde, veritabanının SQL Server Always On Availability Group’a eklenebilmesi için SQL Server, mevcut bir Full Backup’ın bulunmasını zorunlu kılar. Bunun nedeni, replikalar arasında başlatılacak olan senkronizasyon sürecinin sağlam ve tutarlı bir backup zinciri üzerinden ilerlemesini sağlamaktır.

Eğer NIHATCUBUKDB isimli Database (Veritabanı)’i üzerinde Full Backup alınmazsa, New Availability Group Wizard içerisindeki Select Databases ekranında ilgili veritabanının Status bölümünde Full backup is required hatası ile karşılaşılır. Bu hata nedeniyle veritabanı seçilemez ve Availability Group’a ekleme işlemi gerçekleştirilemez.

Özetle, NIHATCUBUKDB isimli Database (Veritabanı)’i Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için şu adımların eksiksiz tamamlanması gerekir:

• Recovery Model ayarının Full olarak yapılandırılması
• Veritabanı üzerinde en az bir adet Full Backup alınması
• Bu işlemler tamamlandıktan sonra, Select Databases ekranında veritabanı hatasız şekilde listelenecek ve SQL Server Always On Availability Group’a dahil edilebilir hale gelecektir.

Select Databases ekranında NIHATCUBUKDB isimli veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına eklemek istediğimizde, Status bölümünde Full backup is required uyarısını görüyoruz. Bu uyarı, ilgili veritabanı için henüz Full Database Backup alınmadığını ifade etmektedir.

SQL Server Always On Availability Group mimarisinde, bir veritabanının yapıya dahil edilebilmesi için Full Recovery Model kullanılması tek başına yeterli değildir. SQL Server, replikalar arasında veri senkronizasyonunu başlatabilmek için mutlaka geçerli bir Full Backup’ın mevcut olmasını bekler. Bu backup, Availability Group için başlangıç referansı (baseline) olarak kullanılır.

Ekranda açılan uyarı penceresinde de belirtildiği üzere, This database lacks a full database backup mesajı, veritabanının henüz tam yedeğinin alınmadığını açıkça belirtir. Bu nedenle NIHATCUBUKDB isimli Database (Veritabanı) seçilemez ve Availability Group’a ekleme işlemi devam ettirilemez.

Bu hatanın giderilebilmesi için, NIHATCUBUKDB isimli Database (Veritabanı)’i üzerinde en az bir adet Full Database Backup alınması gerekir. Full backup işlemi tamamlandıktan sonra Select Databases ekranı yenilendiğinde, ilgili veritabanının Status bölümünün hatasız hale geldiği ve Availability Group’a dahil edilebilir olduğu görülecektir.

Özetle, Microsoft SQL Server 2025 Always On Availability Group yapısında bir veritabanını Availability Group’a ekleyebilmek için şu koşulların birlikte sağlanması zorunludur:

• Recovery Model ayarının Full olması
• Veritabanı üzerinde en az bir adet Full Backup alınmış olması
• Bu gereksinimler, Always On mimarisinin veri tutarlılığı ve High Availability (Yüksek Erişilebilirlik) prensiplerinin temelini oluşturmaktadır.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.

Bu durum, NIHATCUBUKDB isimli Database (Veritabanı) için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli tüm ön koşulların eksiksiz olarak sağlandığını gösterir. Başka bir ifadeyle, Recovery Model ayarı Full olarak yapılandırılmış, Full Backup</strong (Tam Yedek) alınmış ve veritabanı Always On yapısına eklenmeye hazır hale gelmiştir.

Bu aşamadan sonra NIHATCUBUKDB isimli Database (Veritabanı)’ni seçerek Availability Group yapısına güvenle dahil edebilir ve yapılandırma adımlarına sorunsuz şekilde devam edebiliriz.

Add Database to Availability Group Wizard içerisinde yer alan Select Databases ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.

Bu ifade, NIHATCUBUKDB isimli Database (Veritabanı)’i için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli olan tüm ön koşulların eksiksiz olarak sağlandığını göstermektedir. Bu kapsamda;

• Recovery Model ayarının Full olarak yapılandırıldığı,
• Veritabanı üzerinde en az bir adet Full Backup</strong (Tam Yedek) alındığı,
• Veritabanının çevrimiçi (Online) ve erişilebilir durumda olduğu,

SQL Server tarafından doğrulanmış olur.

Ekranda açılan bilgilendirme penceresinde de belirtildiği üzere, This database meets the availability-database prerequisites mesajı, veritabanının Availability Group’a eklenmeye hazır olduğunu açıkça ifade etmektedir.

Bu aşamadan sonra NIHATCUBUKDB isimli veritabanını seçerek Next seçeneği ile devam edebilir ve veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına sorunsuz bir şekilde dahil edebiliriz.

Bu ekran, SQL Server Always On Availability Group yapılandırmasında en kritik eşiklerden biridir ve veritabanının mimariye teknik olarak uygunluğunun SQL Server tarafından onaylandığını gösterir.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuşa tıklayarak Properties seçeneğine tıklıyoruz.

Database Properties – NIHATCUBUKDB ekranın geliyor karşımıza.

Database Properties – NIHATCUBUKDB ekranında sol menüde yer alan Options seçeneğine tıklıyoruz.

Database Properties – NIHATCUBUKDB ekranda NIHATCUBUKDB isimli Database (Veritabanı) ait Recovery Model, Auto Close, Auto Shrink, Compatibility Level gibi SQL Server Always On Availability Group yapılandırması açısından kritik olan seçenekleri görüntüleyebilir ve gerekli yapılandırmaları gerçekleştirebiliriz.

Database Properties – NIHATCUBUKDB ekranında Options sekmesine geldiğimizde, Recovery model ayarının Simple olarak yapılandırıldığını görüyoruz.

Ancak NIHATCUBUKDB isimli Database (Veritabanı)’nı Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için Recovery model ayarının mutlaka Full olarak yapılandırılması gerekmektedir. Always On mimarisi, transaction log zinciri üzerinden çalıştığı için Simple Recovery Model ile yapılandırılmış veritabanları bu yapıya dahil edilemez.

Bu nedenle, SQL Server Always On Availability Group yapılandırmasına devam edebilmek için Recovery model ayarını Simple’dan Full’a çevirerek gerekli yapılandırmayı yapmamız gerekir.

Recovery model bölümünde Full, Simple ve Bulk-Logged olmak üzere üç farklı seçenek bulunmaktadır. Bu modeller, SQL Server’da transaction log yönetiminin nasıl yapılacağını ve olası bir felaket durumunda verinin ne kadar geri döndürülebileceğini belirler.

Full: Full Recovery Model’de yapılan tüm işlemler transaction log dosyasına eksiksiz olarak kaydedilir ve manuel müdahale edilmedikçe silinmez. Bu sayede veritabanı, istenilen herhangi bir zamana kadar geri döndürülebilir. Bu model, SQL Server’da en güvenilir recovery model olarak kabul edilir ve özellikle SQL Server Always On Availability Group, Log Shipping ve kritik Production sistemleri için zorunludur.

Ancak Full Recovery Model’de transaction log yönetimi manuel yapılır. Bu nedenle transaction log dosyalarının kontrolsüz şekilde büyümemesi için düzenli olarak işlem yapılmalıdır. SQL Server’da transaction log temizliği için iki temel yöntem vardır:

• Transaction Log Backup almak
• Transaction Log Shrink işlemi yapmak

SQL Server 2005 ve sonrası sürümlerde, transaction log shrink işlemi uygulanacaksa, veritabanının Recovery Model’i geçici olarak Simple yapılmalı, shrink işlemi tamamlandıktan sonra tekrar Full olarak ayarlanmalıdır. Full Recovery Model’de INSERT, DELETE, UPDATE gibi DML işlemlerinin yanı sıra; Index oluşturma, Index Rebuild, BCP, Bulk Insert gibi bakım ve toplu işlemler de transaction log’a detaylı şekilde yazılır. Bu durum transaction log dosyasının hızla büyümesine ve işlemlerin bir miktar yavaşlamasına neden olabilir.

Bulk-Logged: Bulk-Logged Recovery Model, Full Recovery Model’e benzer şekilde çalışır; ancak bulk işlemler sırasında önemli bir fark ortaya çıkar. Bulk işlemler esnasında yapılan tüm işlemler tek tek loglanmaz, bunun yerine tek bir kayıt transaction log’a yazılır. Bu sayede bulk işlemler, Full Recovery Model’e kıyasla daha hızlı gerçekleştirilir ve transaction log büyümesi daha kontrollü olur. Ancak bu modelde, bulk işlem yapılan zaman aralığına point-in-time restore yapmak mümkün değildir.

Bu nedenle Bulk-Logged Recovery Model, Production ortamları için kalıcı bir çözüm değildir. Ancak yaygın bir kullanım senaryosu şu şekildedir:

• Bulk işlem öncesinde Transaction Log Backup alınır
• Recovery Model geçici olarak Bulk-Logged yapılır
• Bulk işlem tamamlanır
• Recovery Model tekrar Full olarak ayarlanır

Bu yaklaşım sayesinde hem performans kazanılır hem de veri güvenliği korunur. Bu nedenle Bulk-Logged Recovery Model’i geçici olarak tercih edilen bir recovery model olarak tanımlamak yanlış olmaz.

Simple: Simple Recovery Model’de çalışan veritabanlarında, transaction log kayıtları Checkpoint işlemi sonrasında otomatik olarak temizlenir. Bu nedenle transaction log dosyasının sürekli büyümesi söz konusu değildir ve log yönetimi oldukça kolaydır. Burada sıkça yanlış anlaşılan önemli bir noktaya değinmek gerekir. Simple Recovery Model dahil olmak üzere tüm recovery modellerinde transaction log tutulur. Ancak Simple Recovery Model’de bu loglar, checkpoint işleminden sonra otomatik olarak silinir. Simple Recovery Model’in en büyük dezavantajı, transaction log backup alınamamasıdır. Bu nedenle point-in-time restore (belirli bir zamana geri dönüş) mümkün değildir. Olası bir felaket durumunda, en iyi ihtimalle yalnızca en son alınan Full veya Differential Backup’a kadar geri dönülebilir. Bu da ciddi veri kaybı riskine yol açar.

Bu sebeple Simple Recovery Model, Production ortamlarında kesinlikle önerilmez.

Database Properties – NIHATCUBUKDB ekranında Options sekmesi altında yer alan Recovery model bölümünden Full seçeneğini seçiyoruz.

Database Properties – NIHATCUBUKDB ekranında Options sekmesinde gerekli yapılandırmayı tamamladıktan sonra OK diyerek ayarları kaydediyoruz.

Bu işlem ile NIHATCUBUKDB isimli Database (Veritabanı), Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi için gerekli olan Full Recovery Model ile yapılandırılmış olur.

Microsoft SQL Server Management Studio (SSMS) konsolunda, Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuş Tasks menüsüne giriyoruz ve Back Up… seçeneğine tıklıyoruz.

Bu adım ile Microsoft SQL Server 2025 Always On Availability Group yapılandırmasına NIHATCUBUKDB isimli Database (Veritabanı)’ni ekleyebilmek için gerekli olan Full Backup</strong (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 yer alan Back up to seçeneğini Disk olarak belirliyoruz. Bu yapılandırma ile veritabanının Full Backup</strong (Tam Yedek) işleminin 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.

Gerekli kontrolleri tamamladıktan sonra, Back Up Database – BAKICUBUKDB ekranında OK seçeneğine tıklayarak Full Backup (Tam Yedek) alma 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) konsolunda Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin durumunun Online olduğunu görüyoruz.

Ancak NIHATCUBUKDB isimli Database (Veritabanı)’nin Synchronized durumuna geçebilmesi için, ilgili veritabanının Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilmesi gerekmektedir. Veritabanı SQL Server Always On Availability Group içerisine eklendiğinde, Primary ve Secondary replikalar arasında veri eşitleme (synchronization) süreci başlayacak ve senkronizasyon başarıyla tamamlandığında veritabanı durumu Synchronized olarak görüntülenecektir.

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 bulunan Availability Databases bölümünde, BAKICUBUKDB isimli Database (Veritabanı)’nın ilgili Availability Group içerisinde yer aldığını görüyoruz. Ancak NIHATCUBUKDB isimli Database (Veritabanı) henüz bu Availability Group yapısına dahil edilmediği için Availability Databases listesinde görünmemektedir. Bu nedenle NIHATCUBUKDB isimli Database (Veritabanı) için senkronizasyon (Synchronized) durumu da henüz oluşmamıştır.

Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön hazırlıkları tamamladık. Bu kapsamda, veritabanının Recovery Model ayarını Full olarak yapılandırdık ve ardından Full Backup (Tam Yedek) işlemini aldık.

Bu adımların tamamlanmasıyla birlikte NIHATCUBUKDB isimli Database (Veritabanı), artık Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilmeye hazır hale gelmiştir.

Bu işlem için Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz. Always On High Availability bölümü altında yer alan Availability Groups üzerinde sağ tuşa tıklayarak Add Database seçeneğini seçiyoruz.

Bu adım ile Add Database to Availability Group Wizard başlatılır ve veritabanını Availability Group yapısına ekleme sürecine geçilmiş olur.

Add Database to Availability Group Wizard başlatıldığında ilk olarak Introduction ekranı karşımıza gelir.

Introduction ekranıında mevcut bir Availability Group yapısına yeni bir veritabanı ekleme süreci hakkında genel bilgilendirme sunar.

Introduction ekranında bu sihirbazın mevcut Availability Group yapısına bir veya birden fazla availability database eklemek için kullanılacağı belirtilmektedir. Ayrıca veritabanını Availability Group’a ekleyebilmek için izlenecek temel adımlar özetlenir. Bu adımlar arasında; SQL Server instance üzerindeki uygun veritabanının seçilmesi, başlangıç veri senkronizasyon yönteminin belirlenmesi, varsa secondary replica’lara bağlantı sağlanması, doğrulama kontrollerinin yapılması ve son olarak yapılandırma özetinin gözden geçirilmesi yer alır.

Introduction ekranı yalnızca bilgilendirme amaçlıdır ve herhangi bir yapılandırma işlemi içermez. NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön koşullar (Full Recovery Model ve Full Backup) sağlandığı için, bu aşamada Next seçeneğine tıklayarak Select Databases adımına geçebiliriz.

Select Databases ekranında Availability Group yapısına dahil edeceğimiz Database (Veritabanı)’nı seçmemiz gerekmektedir. Select Databases ekranında SQL Server instance üzerinde bulunan tüm kullanıcı veritabanları listelenir ve her bir veritabanının Availability Group’a uygunluk durumu Status sütununda görüntülenir.

Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK isimli Database (Veritabanı) Status bölümünde Already part of this availability group olarak görüyoruz. Bu ifade, ilgili veritabanlarının halihazırda SQL Server Always On Availability Group üyesi olduğunu ve yeniden eklenemeyeceğini gösterir.

Availability Group yapısına eklemek istediğimiz NIHATCUBUK isimli Database (Veritabanı) ise Status bölümünde Meets prerequisites olarak görünmektedir. Bu durum, veritabanının SQL Server Always On Availability Group yapısı için gerekli tüm ön koşulları sağladığını ve eklenmeye hazır olduğunu ifade eder.

Eğer bir Database (Veritabanı) üzerinde Full Backup alınmamışsa, Status bölümünde Full backup is required uyarısı görüntülenir. Bu durumda ilgili veritabanı seçilemez ve Availability Group yapısına dahil edilemez. Hatanın giderilmesi için veritabanı üzerinde Full Backup</strong (Tam Yedek) alınması gerekmektedir.

Benzer şekilde, Status bölümünde Full recovery mode is required hatası görülüyorsa, ilgili veritabanının Recovery Model ayarı Full olarak yapılandırılmamıştır. Bu durumda Database Properties → Options bölümünden Recovery Model ayarı Full olacak şekilde değiştirilmelidir.

Select Databases ekranında Availability Group’a eklenecek bir veritabanının Status bölümünde mutlaka Meets prerequisites ifadesinin yer alması gerekmektedir. Aksi durumda, ilgili hata mesajına göre Recovery Model veya Full Backup işlemleri tamamlanmadan veritabanı Availability Group yapısına eklenemez.

Add Database to Availability Group Wizard içerisinde yer alan Select Databases ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.

Bu ifade, NIHATCUBUKDB isimli Database (Veritabanı) için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli olan tüm ön koşulların eksiksiz olarak sağlandığını göstermektedir. Bu kapsamda;

• Recovery Model ayarının Full olarak yapılandırıldığı,
• Veritabanı üzerinde en az bir adet Full Backup</strong (Tam Yedek) alındığı,
• Veritabanının çevrimiçi (Online) ve erişilebilir durumda olduğu,

SQL Server tarafından doğrulanmış olur.

Ekranda açılan bilgilendirme penceresinde de belirtildiği üzere, This database meets the availability-database prerequisites mesajı, veritabanının Availability Group’a eklenmeye hazır olduğunu açıkça ifade etmektedir.

Bu aşamadan sonra NIHATCUBUKDB isimli Database (Veritabanı) seçerek Next seçeneği ile devam edebilir ve veritabanını Availability Group yapısına sorunsuz bir şekilde dahil edebiliriz.

Bu ekran, SQL Server Always On Availability Group yapılandırmasında en kritik eşiklerden biridir ve veritabanının mimariye teknik olarak uygunluğunun SQL Server tarafından onaylandığını gösterir.

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

Status bölümünde Meets prerequisites olarak görüntülenen NIHATCUBUKDB isimli Database (Veritabanı)’i işaretledikten sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz. Bu işlem ile veritabanını Availability Group yapısına ekleme sürecinde bir sonraki yapılandırma ekranına ilerlemiş oluyoruz.

Connect to Existing Secondary Replicas ekranında Microsoft SQL Server 2025 Always On Availability Group yapısında Secondary Replica olarak yapılandıracağımız W25SQL25NOD2 isimli sunucumuza bağlantı sağlamamız gerekmektedir.

Connect to Existing Secondary Replicas ekranında Availability Group yapısına dahil olan mevcut secondary replica sunucular listelenir. W25SQL25NOD2 sunucusu için ilgili satırda yer alan Connect seçeneğine tıklayarak, Microsoft SQL Server 2025 Always On Availability Group yapısına bu sunucu üzerinden bağlantı kurabiliriz.

Eğer ortamda birden fazla secondary replica bulunuyorsa, Connect All seçeneğini kullanarak Microsoft SQL Server 2025 Always On Availability Group yapısındaki tüm secondary sunuculara tek seferde bağlantı sağlamak mümkündür. Bu adım, veritabanının secondary replica’lara doğru şekilde kopyalanması ve senkronizasyon sürecinin sorunsuz ilerlemesi açısından kritik öneme sahiptir.

Connect to Existing Secondary Replicas ekranında Secondary Replica olarak yapılandıracağımız W25SQL25NOD2 isimli sunucumuz için ilgili satırda yer alan Connect seçeneğine tıklayarak bağlantı sağlıyoruz.

Bu işlem ile Microsoft SQL Server 2025 Always On Availability Group yapısında, W25SQL25NOD2 sunucusu secondary replica olarak sürece dahil edilir ve bir sonraki adımda veritabanının bu sunucuya senkronize edilmesi için gerekli yapılandırmalara geçilmiş olur.

Connect to Server ekranında Server name bölümünde W25SQL25NOD2 bilgisinin otomatik olarak geldiğini görüyoruz.

Connect to Server ekranında gerekli kontrolleri yaptıktan sonra Connect seçeneğine tıklayarak W25SQL25NOD2 isimli sunucuya bağlantı sağlıyoruz. Bu işlem ile Microsoft SQL Server 2025 Always On Availability Group yapısında Secondary Replica olarak yapılandırılacak olan sunucuya başarıyla bağlanmış oluyoruz.

Connect to Existing Secondary Replicas ekranında Secondary Replica olarak yapılandırdığımız W25SQL25NOD2 isimli sunucumuza bağlantıyı başarıyla sağladıktan sonra Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Bu adım ile, Microsoft SQL Server 2025 Always On Availability Group yapısında yer alacak secondary replica sunucular için gerekli bağlantılar tamamlanmış olur ve yapılandırma sürecine devam edilir.

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. Select Initial Data Synchronization ekranında 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.

Automatic seeding seçeneğini ile, veritabanlarının Primary Replica üzerinden Secondary Replica’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 bir sonraki adıma geçiyoruz.

Validation ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nı Availability Group yapısına dahil edebilmek için gerekli olan tüm kontrollerin otomatik olarak yapıldığını görüyoruz.

Validation ekranında gerçekleştirilen her bir kontrol adımının durumu listelenir ve NIHATCUBUKDB isimli Database (Veritabanı)’nı için tüm adımların Status bölümünde Success olarak sonuçlandığı görülür. Bu durum, yapılandırmada herhangi bir hata veya eksiklik olmadığını ve işlemin sorunsuz şekilde ilerleyebileceğini gösterir.

Eğer herhangi bir aşamada bir problem tespit edilseydi, ilgili adım Error olarak görüntülenirdi. Bu durumda Previous seçeneğini kullanarak önceki adımlara geri dönülebilir, hatalı yapılandırma düzeltildikten sonra Re-run validation seçeneği ile kontroller yeniden çalıştırılabilirdi.

Validation ekranında NIHATCUBUKDB isimli Database (Veritabanı)’in Availability Group yapısına dahil etmeye engel herhangi bir sorun bulunmadığı için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Summary ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nı Availability Group yapısına dahil etmek için gerçekleştirilen tüm yapılandırmaların bir özetini görüyoruz. Summary ekranında seçilen NIHATCUBUKDB isimli Database (Veritabanı)’nı, secondary replica’lar, senkronizasyon yöntemi (Automatic seeding) ve diğer ilgili ayarlar toplu olarak listelenir.

Summary ekranında yapılandırma özetini kontrol ettikten sonra Finish seçeneğine tıklayarak NIHATCUBUKDB isimli Database (Veritabanı)’in Availability Group yapısına dahil etme işlemini başlatıyoruz.

Summary ekranında ayrıca Script bölümü sayesinde, Availability Group’a veritabanı eklemek için yapılan tüm yapılandırmaları Script (Senaryo) olarak oluşturabilir ve kaydedebilirsiniz. Bu özellik; Dokümantasyon, Denetim (Audit) ve benzer ortamlar için tekrar kullanılabilir kurulumlar açısından önemli bir avantaj sağlar.

Results ekranında Adding databases to availability group ‘SQL25HAG ifadesini görüyoruz. Bu ekran, seçmiş olduğumuz NIHATCUBUKDB isimli Database (Veritabanı)’nın Microsoft SQL Server 2025 Always On Availability Group yapısına başarıyla eklendiğini göstermektedir.

Bu aşamada NIHATCUBUKDB isimli Database (Veritabanı), Availability Group içerisine dahil edilmiş olup primary ve secondary replikalar arasında veri senkronizasyon süreci başlatılmıştır. Senkronizasyon işlemi başarıyla tamamlandığında, veritabanının durumu Synchronized olarak görüntülenecek ve Availability Group → Availability Databases bölümü altında yer alacaktır.

Results ekranında gerçekleştirilen işlemin sonucunu özetleyen ve herhangi bir hata oluşup oluşmadığını gösteren son kontrol adımıdır. Bu ekranın sorunsuz şekilde tamamlanması, veritabanının Availability Group mimarisine başarılı bir şekilde entegre edildiğini doğrular.

Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla listelendiğini görüyoruz.

Ayrıca Database (Veritabanı) adının yanında NIHATCUBUKDB (Synchronized) ifadesinin yer aldığını fark ediyoruz. Bu durum, NIHATCUBUKDB isimli Database (Veritabanı)’nin Microsoft SQL Server 2025 Always On Availability Group yapısı içerisinde Primary ve Secondary replica’lar arasında senkronizasyonun başarıyla tamamlandığını ve verinin tutarlı bir şekilde eşitlendiğini gösterir.

Bu aşama, veritabanının Availability Group mimarisi içerisinde sağlıklı, aktif ve High Availability (Yüksek Erişilebilirlik) prensiplerine uygun şekilde çalıştığını doğrulayan en önemli göstergelerden biridir.

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

İlgili Availability Group’u genişlettiğimizde, Availability Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla eklendiğini görüyoruz.

Bu görünüm, NIHATCUBUKDB isimli Database (Veritabanı)’nin SQL25HAG isimli Availability Group yapısına sorunsuz bir şekilde dahil edildiğini ve Always On mimarisi içerisinde aktif ve sağlıklı olarak çalıştığını doğrulamaktadır.

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

İlgili Availability Group’u genişlettiğimizde, Availability Databases bölümü altında NIHATCUBUKDB isimli Database (Veritabanı)’nin başarıyla eklendiğini görüyoruz.

Bu görünüm, NIHATCUBUKDB isimli Database (Veritabanı)’nin SQL25HAG isimli Availability Group yapısına sorunsuz bir şekilde dahil edildiğini ve Always On mimarisi içerisinde aktif ve sağlıklı olarak çalıştığını doğrulamaktadır.

 

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