Merhaba

Bir önceki yazıda TDE’nin (Transparent Data Encryption) ne olduğunu ve tek bir veritabanına nasıl uygulandığını ele almıştık. Bu yazıda ise işin asıl zorlaştığı yere geçiyoruz: Always On Availability Group mimarisinde TDE’nin nasıl yapılandırıldığı.

Bu yazı, TDE temellerini bildiğinizi ve tek veritabanı senaryosunu uyguladığınızı varsayar. Henüz okumadıysanız, önce TDE temelleri yazısına göz atmanızı öneririm.

Always On İle TDE Neden Zorlaşır?

Tek bir sunucuda TDE etkinleştirmek görece kolaydır. Ancak Always On Availability Group devreye girdiğinde bir kısıt öne çıkar: aynı veritabanı birincil (Primary) ve tüm ikincil (Secondary) replikalar üzerinde eşzamanlı olarak tutulur. Bir replika şifreli veritabanını açabilmek için aynı sertifikaya sahip olmak zorundadır.

Dolayısıyla mantık şudur: birincil replikada oluşturduğumuz sertifikayı yedekleyip, tüm ikincil replikalara taşıyıp orada yeniden oluşturmak. Sertifikalar tüm replikalarda tutarlı hale gelmeden veritabanı gruplar arası senkronize olamaz.

Önemli: TDE ile şifrelenmiş bir veritabanını Availability Group’a SSMS grafik arayüzü (GUI) üzerinden ekleyemezsiniz. Bu işlem yalnızca T-SQL ile yapılır.

Bu yazıdaki örnek ortam iki düğümlüdür. İkiden fazla ikincil replikanız varsa, ikincil adımları her biri için tekrarlayın.

• Birincil Replika (Primary): W25SQL25NOD1
• İkincil Replika (Secondary): W25SQL25NOD2
• AG Grubu: SQL25HAG
• Veritabanı: BAKICUBUK_DB1
• TDE Sertifikası: BAKICUBUK_TDE_Cert

Bu senaryoda, birincil replika (W25SQL25NOD1) üzerinde TDE temelleri yazısındaki 6 adımı zaten tamamladığınızı varsayıyoruz. Yani BAKICUBUK_DB1 birincil replikada şifreli durumda.

Bölüm 1: Şifreli Veritabanını Availability Group’a Ekleme

Adım 1: Rolleri Doğrulama (İşlemlere Başlamadan Önce)

Herhangi bir komut çalıştırmadan önce, hangi sunucunun Primary hangisinin Secondary olduğunu ve AG’nin gerçek adını mutlaka doğrulayın. Bu yazıdaki komutların bir kısmı yalnızca Primary’de, bir kısmı yalnızca Secondary’de çalışır; yanlış node’da çalıştırılan bir komut hata verir veya veritabanını Restoring... durumunda bırakır. Node adlarına güvenmeyin, çünkü roller bir failover sonrasında yer değiştirmiş olabilir:

Çıktıdaki role_desc sütunu her replikanın rolünü (Primary / Secondary), AG_Name ise grubun gerçek adını gösterir. Bu yazının geri kalanındaki W25SQL25NOD1 (Primary) ve W25SQL25NOD2 (Secondary) etiketlerini, kendi çıktınızdaki gerçek değerlerle eşleştirerek uygulayın.

Her iki node’da da çalıştırın:

SELECT 
    ag.name AS AG_Name,
    ar.replica_server_name,
    ars.role_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;
GO

W25SQL25NOD1 (Primary) üzerindeki komut çıktısı:

W25SQL25NOD2 (Secondary) üzerindeki komut çıktısı:

Adım 2: İkincil Instance – Master Key Oluşturma

W25SQL25NOD2 üzerinde, eğer henüz yoksa bir master key oluşturun:

W25SQL25NOD2 (Secondary) üzerinde çalıştırın:

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Str0ng!MasterKey#TDE2026';
GO

Adım 3: İkincil Instance – Sertifikayı Taşıma

Not: C:\TDE_Backup klasörünün her iki node’da da (hem Primary hem Secondary) var olması gerekir. Yoksa BACKUP CERTIFICATE (Primary’de) veya sertifikayı dosyadan okuma (CREATE CERTIFICATE ... FROM FILE , Secondary’de) adımı hata verir. Ayrıca SQL Server hizmet hesabının (service account) bu klasöre yazma/okuma izni olmalıdır.

W25SQL25NOD1 birincil replikada ürettiğiniz .cer ve .pvk dosyalarını W25SQL25NOD2 sunucusuna kopyalayın ve sertifikayı bu dosyalardan yeniden oluşturun. Özel anahtarı korumak için birincil replikada yedek alırken kullandığınız parolanın aynısını girmelisiniz:

W25SQL25NOD2 (Secondary) üzerinde çalıştırın:

USE master;
GO
CREATE CERTIFICATE BAKICUBUK_TDE_Cert
    FROM FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert.cer'
    WITH PRIVATE KEY (
        FILE = 'C:\TDE_Backup\BAKICUBUK_TDE_Cert.pvk',
        DECRYPTION BY PASSWORD = 'Cert!PrivKey#Str0ngTDE2026'
    );
GO

Parola notu: Buradaki DECRYPTION BY PASSWORD = '...' satırındaki parola, birincil replikada sertifikayı yedeklerken (BACKUP CERTIFICATE ... ENCRYPTION BY PASSWORD) kullandığınız parolayla birebir aynı olmak zorundadır. Farklı bir parola girerseniz .pvk dosyası açılamaz ve Msg 15208 - The certificate, asymmetric key, or private key file is not valid benzeri bir hata alırsınız. Bu yüzden yedekleme parolasını değiştirdiyseniz, buraya da aynısını yazın.

Bu noktada her iki replikada da aynı sertifika mevcut. Sertifikaların gerçekten eşleştiğini thumbprint değerini karşılaştırarak doğrulayabilirsiniz iki node’da da aynı olmalıdır:

Her iki node’da ayrı ayrı çalıştırıp thumbprint’leri karşılaştırın:

SELECT name, thumbprint 
FROM sys.certificates 
WHERE name = 'BAKICUBUK_TDE_Cert';
GO

W25SQL25NOD1 (Primary) üzerindeki komut çıktısı:

W25SQL25NOD2 (Secondary) üzerindeki komut çıktısı:

Hangi Komut Hangi Rolde Çalışır? (En Sık Yapılan Hata)

Buradan sonrası, uygulamada en çok hataya yol açan kısımdır. Her komutun doğru rolde (Primary mi, Secondary mi) çalıştırılması zorunludur; yanlış node’da çalıştırıldığında ya hata alırsınız ya da veritabanı Restoring... durumunda takılı kalır. Hangi node’un Primary olduğunu Adım 1: Rolleri Doğrulama’daki sorguyla doğruladığınızı varsayıyoruz.

Komutların rol dağılımı şöyledir:

Komut	Çalıştığı Rol	Amacı
RESTORE DATABASE ... WITH RECOVERY	Primary	Veritabanı Primary’de ONLINE (kurtarılmış) olmalı
ALTER AVAILABILITY GROUP ... ADD DATABASE	Primary	Veritabanını gruba ekler
RESTORE DATABASE/LOG ... WITH NORECOVERY	Secondary	Yedeği geri yükler, DB Restoring... halinde kalır
ALTER DATABASE ... SET HADR AVAILABILITY GROUP	Secondary	Restoring... durumundaki DB’yi gruba katar

Kritik: NORECOVERY yalnızca Secondary tarafında kullanılır. Primary tarafında veritabanı ONLINE olmalıdır. Eğer Primary’de veritabanı Restoring... görünüyorsa, büyük olasılıkla yanlışlıkla NORECOVERY ile bırakılmıştır; RESTORE DATABASE BAKICUBUK_DB1 WITH RECOVERY; ile online hale getirin.

Not: ALTER AVAILABILITY GROUP ... ADD DATABASE komutunu Secondary üzerinde çalıştırırsanız Msg 15151 - Cannot alter the availability group ... because it does not exist or you do not have permission hatasını alırsınız. Bu hata çoğu zaman “yetki yok” değil, “yanlış rolde çalıştırıldı” veya “AG adı yanlış yazıldı” anlamına gelir.

Adım 4: Veritabanını Availability Group’a Ekleme

Birincil replikada tam yedek ve transaction log yedeği alın, dosyaları W25SQL25NOD2‘ye kopyalayın ve ikincil replikada NORECOVERY ile restore edin:

W25SQL25NOD1 (Primary) üzerinde yedek al

BACKUP DATABASE BAKICUBUK_DB1 
    TO DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Full.bak';
GO
BACKUP LOG BAKICUBUK_DB1 
    TO DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Log.trn';
GO

W25SQL25NOD2 (Secondary) üzerinde NORECOVERY ile restore et

RESTORE DATABASE BAKICUBUK_DB1 
    FROM DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Full.bak'
    WITH NORECOVERY;
GO
RESTORE LOG BAKICUBUK_DB1 
    FROM DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Log.trn'
    WITH NORECOVERY;
GO

Ardından veritabanını gruba ekleyin:

W25SQL25NOD1 (Primary) üzerinde

ALTER AVAILABILITY GROUP SQL25HAG ADD DATABASE BAKICUBUK_DB1;
GO

W25SQL25NOD2 (Secondary) üzerinde AG’ye katıl

ALTER DATABASE BAKICUBUK_DB1 SET HADR AVAILABILITY GROUP = SQL25HAG;
GO

Sık karşılaşılan hata – Msg 1412 (log zinciri boşluğu): Bu komutu çalıştırdığınızda şu hatayı alabilirsiniz:

Msg 1412 - The remote copy of database "BAKICUBUK_DB1" has not been rolled forward to a point in time that is encompassed in the local copy of the database log.

Bu, Secondary’ye geri yüklenen kopyanın Primary’nin güncel log noktasına kadar ilerletilmediğini, yani aradaki log kayıtlarında bir boşluk (LSN gap) olduğunu gösterir. En yaygın nedeni, full yedek ile birlikte log yedeğinin alınmaması veya Secondary’de yalnızca full yedeğin restore edilmesidir. Çözüm için Primary’de yeni bir log yedeği alın, Secondary’ye NORECOVERY ile restore edip komutu tekrarlayın:

W25SQL25NOD1 (Primary) üzerinde

BACKUP LOG BAKICUBUK_DB1 
    TO DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Log2.trn';
GO

W25SQL25NOD2 (Secondary) üzerinde

RESTORE LOG BAKICUBUK_DB1 
    FROM DISK = 'C:\TDE_Backup\BAKICUBUK_DB1_Log2.trn'
    WITH NORECOVERY;
GO

Ardından ALTER DATABASE ... SET HADR komutunu yeniden çalıştırın. İki noktaya dikkat edin: tüm restore işlemleri Secondary’de NORECOVERY ile yapılmalıdır (yanlışlıkla RECOVERY ile geri yüklendiyse veritabanı artık log kabul etmez; Secondary’de silip full + log zincirini baştan NORECOVERY ile geri yükleyin). Ayrıca full ve log yedekleri aynı kesintisiz zincirden gelmelidir; başka bir bakım planı arada BACKUP LOG alıyorsa log zinciri o dosyalara kaymış olabilir, bu durumda en güncel log yedeğini kullanın.

Adım 5: AG Sağlık Doğrulaması ve Failover Testi

Şifreli veritabanının gruba sağlıklı katıldığını iki aşamada doğrularız: önce senkronizasyon durumu, sonra bir failover testi.

1. Senkronizasyon durumunu kontrol edin.

T-SQL ile hızlı kontrol:

Herhangi bir replikada:

SELECT 
    ag.name AS AG_Name,
    DB_NAME(drs.database_id) AS DatabaseName,
    ar.replica_server_name,
    drs.synchronization_state_desc,
    drs.is_suspended
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;
GO

synchronization_state_desc değeri tüm replikalarda SYNCHRONIZED (senkron commit modunda) veya SYNCHRONIZING (asenkron modda) olmalı; is_suspended değeri 0 olmalıdır.

W25SQL25NOD1 (Primary) üzerindeki komut çıktısı:

W25SQL25NOD2 (Secondary) üzerindeki komut çıktısı:

Grafik arayüzden görmek isterseniz:

SSMS’te Object Explorer → Always On High Availability → Availability Groups → ilgili grubun üzerinde sağ tık → Show Dashboard.

Açılan panoda her replikanın rolü, senkronizasyon durumu ve veritabanı bazında sağlık göstergeleri yeşil olmalıdır.

2. Failover testi yapın

Failover, Primary rolünü bir replikadan diğerine devretme işlemidir; amaç, gerçek bir kesinti anında şifreli veritabanının yeni Primary üzerinde sorunsuz açıldığını önceden görmektir. Sertifika ikincil replikada eksikse, failover sonrası veritabanı açılamaz; test bunu ortaya çıkarır.

Yöntem A – SSMS Failover Wizard üzerinden:

Object Explorer’da Always On High Availability → Availability Groups altında AG’nin ü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.

Yöntem B – T-SQL ile:

Failover’ı hedef (yeni Primary olacak) replika üzerinde, yani şu an Secondary olan node üzerinde çalıştırın. Senkron ve veri kaybısız failover için:

Yeni Primary olacak (şu an Secondary olan) replika üzerinde çalıştırın

ALTER AVAILABILITY GROUP SQL25HAG FAILOVER;
GO

Sık karşılaşılan hata – Msg 41122: Bu komutu yanlışlıkla Primary üzerinde çalıştırırsanız şu hatayı alırsınız:

Msg 41122 - Cannot failover availability group '...' to this instance of SQL Server. The local availability replica is already the primary replica...

Anlamı basittir: FAILOVER komutu “bu instance’ı yeni Primary yap” demektir; dolayısıyla zaten Primary olan bir replikada çalıştırılamaz. Komutu, Primary yapmak istediğiniz Secondary replika üzerinde çalıştırın. (GUI’deki Failover Wizard bu bağlantıyı sizin için otomatik yönettiğinden bu hatayla karşılaşmazsınız.)

Failover sonrası doğrulama. İşlem bittikten sonra roller yer değiştirir. Yeni rol dağılımını, Adım 1: Rolleri Doğrulama’daki sorgusuyla teyit edin artık W25SQL25NOD2 Primary, W25SQL25NOD1 Secondary olarak görünmelidir:

W25SQL25NOD1 (Secondary) üzerindeki komut çıktısı:

W25SQL25NOD2 (Primary) üzerindeki komut çıktısı:

Ardından yeni Primary üzerinde veritabanının ONLINE ve şifreli (encryption_state = 3
) olduğunu doğrulayın. Bu, TDE sertifikasının ikincil replikada da doğru şekilde bulunduğunun kanıtıdır:

SELECT DB_NAME(database_id) AS DatabaseName, encryption_state
FROM sys.dm_database_encryption_keys;
GO

Test bittikten sonra dilerseniz aynı adımlarla rolleri eski haline döndürebilirsiniz (bu kez W25SQL25NOD1‘i yeni Primary seçerek).

Uyarı: Failover’ı üretim ortamında iş saatleri dışında yapın; kısa bir bağlantı kesintisine yol açar. Asenkron commit modundaki bir replikaya zorlanan failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) veri kaybına neden olabilir; test için senkron commit modundaki replikayı hedefleyin.

Sonuç

TDE, Always On Availability Group ile birlikte kullanıldığında tek kritik nokta öne çıkar: sertifikanın tüm replikalarda tutarlı biçimde bulunması. Bu yazıda şifreli bir veritabanını gruba eklemeyi, rol bazlı komut ayrımını ve failover testini adım adım ele aldık; yol boyunca Restoring... takılması, Msg 1412 , Msg 15151 ve Msg 41122 gibi sık karşılaşılan hataların nedenlerini ve çözümlerini de gördük. Doğru planlama ve düzenli sertifika yönetimiyle TDE, yüksek erişilebilirlikten ödün vermeden hem güvenlik duruşunuzu güçlendirir hem de regülasyon uyumunuza somut katkı sağlar.

Halihazırda grupta çalışan bir veritabanını sonradan şifrelemek ve sertifika rotasyonu gibi işlemleri ise serinin bir sonraki yazısında ele alıyoruz.

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