SQL Server Always On Mimarisinde Secondary Sunucuda Veritabanının Ne kadar geriden geldiğini bulmak

SQL Server Always ON mimarisinde availability group’u asenkron tanımlarsanız secondary sunucu biraz geriden gelir. Always On ile ilgili detayları “SQL Server Always ON AG(Availability Group) Oluşturmak” isimli makalemde bulabilirsiniz. Secondary Sunucunun ne kadar geriden geldiği uygulamanın transaction yoğunluğu ile ilgilidir. Örneğin uygulama çok yoğun bir şekilde insert, update ve delete işlemleri içeriyorsa işlemlerin secondary sunucuya aktarılması biraz zaman alabilir.

Bazen availability group’u senkron bile tanımlasanız veritabanları senkron göründüğü halde secondary’i çeşitli sebeplerle geriden gelebilir. Örneğin secondary sunucudaki disk’in yavaşlığı.

Senkron göründüğü halde kısmının altını çizdim çünkü,

always on’da secondary sunucunun tamamen replike olması için öncelikle primary sunucudan gelen log kayıtlarının diske yazılması gerekiyor(log hardened işlemi).

Daha sonra log’a yazılan kayıtların data file’lara yazılması gerekiyor.(redone işlemi)

Commit işlemi de redone işlemi ile beraber gerçekleşiyor.

Bazı blog’larda commit olması için redone olmasına gerek yok gibi anlatımlara rastladım fakat pratikte secondary’de redone işleminde bir problem olduğunda her zaman commit işleminin redone işlemi gerçekleşmeden gerçekleşmediğini görüyorum.

Peki durum böyle olunca bizi nasıl etkiliyor. Eğer log hardened işlemi gerçekleşirse veri kaybımız olmuyor. Çünkü veriler bir şekilde secondary’ye aktarılmış oluyor. SQL Server’da senkronizasyonun sağlandığını log hardened işlemine göre belirliyor.

Yani log hardened işlemi gerçekleşmişse ve senkron ag kullanıyorsanız dashboard’da synchronized görüyorsunuz.

Ama bazı durumlarda log hardened işlemi gerçeklemişse bile redone işlemi geriden gelebiliyor.( Disk yavaşlığı vb.)

Böyle bir durumda ag’yi synchronized görüp failover yapmaya çalışsanız failover’ın gerçekleşmesi için saatlarce beklemeniz gerekebilir.

Çünkü redone işlemi yapılmamış. Yani log dosyasına yazılan kayıtlar data dosyasına işlenmemiş. Bu yüzden secondary veritabanının primary hale gelebilmesi için öncelikle redo işlemi yaparak recover olması gerekiyor. Bu yüzden last redone time ve last commit time bizim için failover öncesinde ciddi bir öneme sahip.

Aşağıdaki script yardımıyla Secondary sunucunun primary sunucuya göre ne kadar geriden geldiğini bulabilirsiniz.  Sorgu sonucunda primary’deki veritabanı ile secondary’deki veritabanı arasında 1 saat’ten fazla fark olan veritabanları ile ilgili kayıtlar dönmektedir. Bu sureyi 3600 değerini değiştirirerek istediğiniz süreyi ayarlayabilirsiniz.

Bu script’i primary sunucuda çalıştırmalısınız.

SELECT DB_NAME(drs.database_id) AS Database_Name
      ,drs.last_commit_time AS Primary_Commit
         ,drs2.last_commit_time AS Secondary_Commit
         ,CONCAT(DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)/3600 , ' Saat '
         ,(DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)%3600)/60 , ' Dakika '
         ,DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)%60 ,' Saniye') AS Senkronizasyon_Farki
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.dm_hadr_database_replica_states drs2 ON drs.database_id=drs2.database_id
WHERE drs.is_local=1 AND drs2.is_local=0 AND DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)>3600
ORDER BY DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time) DESC