SQL Server AlwaysOn Failover Öncesi Veri Bütünlüğü Kontrolleri

AlwaysOn Availability Groups (AG) yapısında kontrolsüz bir failover, veri kaybına (RPO) veya servis kesinti süresinin (RTO) uzamasına neden olabilir.

SQL Server AlwaysOn Availability Groups mimarisinde, manuel bir failover işlemi başlatmadan önce sistemin “sağlıklı bir geçişe” hazır olup olmadığını doğrulamak gerekir. Bu doğrulama sürecinin en temel taşı sys.databases tablosundaki log_reuse_wait_desc kolonudur.

Failover işlemi sadece bir “düğmeye basma” eylemi değildir; arka planda log kayıtlarının senkronizasyonu ve redo (yeniden işleme) süreçlerini barındırır. Aşağıdaki riskleri bertaraf etmek için kontrol şarttır:

Veri Kaybı Riski: Eğer ikincil (Secondary) replica üzerinde loglar henüz işlenmemişse, “Force Failover” durumunda veri kaybı yaşanır.
Servis Kesintisi (Downtime): İkincil sunucuda bekleyen çok fazla log (Redo Queue) varsa, veritabanının “Online” olması dakikalar sürebilir.
Log Şişmesi: Failover sonrası yeni Primary sunucuda logların temizlenememesi disk alanını bitirebilir.

Failover Öncesi Hangi Durumlarda Kontrol Edilmeli?

Sadece rutin geçişlerde değil, aşağıdaki spesifik ve kritik durumlarda bu sorgu hayati önem taşır:

1. LDF Shrink (Log Dosyası Sıkıştırma) İşlemleri Öncesi

Log dosyasını küçültmek istiyorsanız, SQL Server’ın logu “yeniden kullanılabilir” (reusable) olarak işaretlemiş olması gerekir.

Neden kontrol edilmelidir. Eğer log_reuse_wait_desc değeri NOTHING değilse, yapacağınız DBCC SHRINKFILE işlemi hiçbir işe yaramayacaktır. Failover öncesi logları temizleyip diski rahatlatmak istiyorsanız önce bu engeli kaldırmalısınız.

2. CDC (Change Data Capture) Aktifliği

CDC, veritabanındaki değişiklikleri okuyup yakalayan bir mekanizmadır.

Neden kontrol edilmelidir. CDC açıkken, değişiklikler “Capture Job” tarafından okunana kadar log kayıtları silinemez. Failover yaparsanız ve yeni sunucuda CDC job’ları düzgün başlamazsa veya gecikirse, log dosyanız kontrolsüzce büyür. Sorguda REPLICATION değerini görüyorsanız, CDC’nin logu tuttuğunu anlarız.

3. Planlı Bakım Çalışmaları

Sunucu yamaları (patching) veya donanım yükseltmeleri öncesi sistemin stabil olduğundan emin olunmalıdır.

4. Yüksek Gecikme (Latency) Belirtileri

Ağ yavaşlığı veya disk darboğazı hissedildiğinde, verinin diğer tarafa yazılıp yazılmadığını (Hardened LSN) kontrol etmek için bakılır.

5. Büyük Veri İşlemleri Sonrası

Milyonlarca satırlık UPDATE veya INDEX REBUILD işlemi bittikten hemen sonra loglar çok yoğundur. Bu yük “Redo Queue” (İkincil sunucuda işlenme sırası) oluşturur. Kontrol edilmeden yapılan failover, veritabanının uzun süre “Recovery” modda kalmasına sebep olur.

6. Log Dosyası Beklenmedik Şekilde Büyüdüğünde

Eğer LDF dosyası şişmişse, sorunu çözmeden failover yapmak yangını diğer odaya taşımaktır. Yeni Primary sunucuda da disk alanı yetersizliğiyle karşılaşabilirsiniz.

Mevcut komut ile kontrol işlemi yapılmaktadır.

SELECT name, log_reuse_wait_desc FROM sys.databases

İkinci kontrol edilen komut:

Select name,S.log_reuse_wait_desc from sys.databases s
--where log_reuse_wait_desc !='NOTHING'

Karşılaştığınız değerlere göre almanız gereken aksiyonlar şunlardır:

A: AVAILABILITY_REPLICA

Transaction loglar henüz ikincil sunucuya (Secondary) gönderilmedi veya orada onaylanmadı.
Failover yapmayın. sys.dm_hadr_database_replica_states tablosundan log_send_queue_size değerini kontrol edin. Bu değer sıfıra yaklaşana kadar bekleyin.

B: LOG_BACKUP

Veritabanı log yedeği bekliyor.
Failover öncesi manuel bir Transaction Log Backup alın. Log zinciri kopuksa, failover sonrası yeni Primary üzerinde loglar temizlenemez ve disk dolar.

C: ACTIVE_TRANSACTION

İçeride henüz tamamlanmamış (Commit edilmemiş) büyük bir işlem var.
İşlemin bitmesini bekleyin veya KILL komutuyla sonlandırın. Aktif işlem varken yapılan failover, yeni sunucuda uzun bir “In Recovery” süresine (Rollback süreci) neden olur.

D: NOTHING

Log döngüsü sağlıklı, bekleyen kritik bir engel yok.
Failover için en güvenli durumdur.

E: CHECKPOINT

Log dosyasının bufferdan diske yazılması için bir checkpoint bekleniyor.
Checkpoint işlemi otomatik olarak gerçekleşecektir. Ancak, manuel olarak CHECKPOINT komutunu çalıştırabilirsiniz.

F:DATABASE MIRRORING

Veritabanı yansıtma (mirroring) işlemi devam ediyor.
Mirroring işlemi tamamlandıktan sonra log dosyası temizlenebilir.

G:ACTIVE_BACKUP_OR_RESTORE

Aktif bir yedekleme veya geri yükleme işlemi devam ediyor.
İşlem tamamlandıktan sonra log dosyası temizlenebilir.

K:REPLICATION

Replikasyon işlemi devam ediyor.
Replikasyon işlemi tamamlandıktan sonra log dosyası temizlenebilir.

M:LOG_SCAN

Log taraması (log scan) devam ediyor.
arama işlemi tamamlandıktan sonra log dosyası temizlenebilir.

N:OLDEST_PAGE

En eski sayfa (oldest page) işlemi devam ediyor.
İşlem tamamlandıktan sonra log dosyası temizlenebilir.

J:DATABASE_SNAPSHOT_CREATION

Veritabanı anlık görüntüsü (snapshot) oluşturuluyor.
Snapshot işlemi tamamlandıktan sonra log dosyası temizlenebilir.

L:OTHER_TRANSIENT

Geçici bir durum söz konusu.
Genellikle kendiliğinden çözülür.

Sadece log_reuse_wait_desc yeterli değildir. Failover’dan hemen önce şu sorgu ile senkronizasyon durumunu (Synchronization State) mutlaka teyit edin:

SELECT 
    ar.node_name, 
    adc.database_name, 
    drs.synchronization_state_desc, 
    drs.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_databases_cluster adc ON drs.group_database_id = adc.group_database_id;

synchronization_state_desc kolonunda SYNCHRONIZED (Synchronous mode için) veya SYNCHRONIZING (Asynchronous mode için) görmeden işleme başlamayın.

Başka makalede görüşmek üzere..

“Biz ona şah damarından daha yakınız.” Kaf-16

Bir yanıt yazın