SQL Server’da HADR_SYNC_COMMIT, Always On Availability Groups (AG) mimarisinde Synchronous-Commit modunda çalışan sistemlerin en kritik bekleme tipidir. Bu bekleme tipi, Primary sunucunun bir işlemi tamamlamak için Secondary sunucudan “Log kayıtlarını aldım ve diske yazdım” onayını beklediği süreyi temsil eder.
Synchronous mode’da veri bütünlüğü esastır. Bir INSERT/UPDATE/DELETE işlemi geldiğinde süreç şöyle işler:
- Primary sunucu işlemi kendi Log dosyasına yazar.
- Bu log kaydını Secondary sunucuya gönderir.
- Secondary sunucu logu alır ve kendi diskine yani ldf dosyasına yazar. (Hardening).
- Secondary sunucu, Primary’ye “Tamam, bende güvendeler” mesajı gönderir.
- Primary sunucu bu mesajı alana kadar HADR_SYNC_COMMIT durumunda bekler ve mesaj gelince işlemi onaylar (Commit).
Bu beklemenin yüksek olması, veritabanının dış dünyayla (network veya karşı sunucu) iletişiminde bir yavaşlık olduğunu gösterir:
- Ağ Gecikmesi (Network Latency): İki sunucu arasındaki bant genişliğinin düşük olması veya ping sürelerinin yüksek olması.
- Secondary Sunucu Disk Performansı: İkincil sunucunun log dosyası (.ldf) yavaş bir diskteyse, logu yazması uzun sürer ve Primary sunucu bekletilir.
- Büyük İşlemler (Heavy Transactions): Tek bir işlemle milyonlarca satırı güncellemek, devasa log paketlerinin karşıya gönderilmesine neden olur.
- Secondary Sunucu CPU Yükü: İkincil sunucu o sırada çok yoğunsa (örneğin backup veya ağır raporlama), log paketlerini işleyip onay vermekte gecikebilir.
Eğer bu bekleme tipi sisteminizde darboğaz yaratıyorsa şu adımları izlemelisiniz:
A. Network Gecikmesini Ölçün
Sunucular arasındaki ağ hızını test edin. Genellikle 1ms ve altı gecikme istenir. Daha yüksek süreler doğrudan uygulama performansına yansır.
B. Secondary Log Diskini Kontrol Edin
Şu sorgu ile her iki sunucudaki disk yazma hızlarını (Write Latency) karşılaştırın:
SELECT io_stall_write_ms / num_of_writes AS [Avg Write Latency MS]
FROM sys.dm_io_virtual_file_stats(DB_ID('VeritabanıAdı'), 2); -- 2 genellikle Log dosyasıdır
Eğer Secondary sunucuda yazma süresi Primary’den çok yüksekse, sorun Secondary sunucunun diskidir.
C. Log Dosyası Yapılandırması (VLF)
Log dosyasında çok fazla VLF (Virtual Log File) olması, logun karşı tarafa aktarılmasını (Log Capture) zorlaştırabilir. VLF sayısını kontrol edip optimize edin.
D. Mod Değişikliği (Geçici veya Kalıcı Çözüm)
Eğer performans veri bütünlüğünden daha önemliyse (veya ağ sorunu anlık olarak çözülemiyorsa), ilgili sunucuyu Asynchronous-Commit moduna almayı düşünebilirsiniz. Bu durumda Primary sunucu, Secondary’den onay beklemeden işlemleri tamamlar.
Özetle
| Belirti | Olası Sorun | Çözüm |
| Ağ ping süresi yüksek | Network Latency | Bant genişliğini artırın veya sunucuları fiziksel olarak yaklaştırın. |
| Secondary Write Latency > 10ms | Secondary Disk Darboğazı | İkincil sunucunun log disklerini hızlandırın (NVMe/SSD). |
| Anlık büyük log üretimi | Batch Transactions | Büyük işlemleri daha küçük parçalara bölün. |
| İşlem sonunda uzun bekleme | Senkronizasyon yükü | Mümkünse Asynchronous modunu değerlendirin. |
Başka makalede görüşmek dileğiyle..
“Allah içinizden iman edenlerin ve kendilerine ilim verilenlerin derecelerini yükseltir.” Mücâdele – 11
