Bu makalade AlwaysOn yapısındaki Show Dashboard ekranında bazı açıklamaları hangi kolunun ne işe yaradığını ele almış olacağım. Herhangi bir failover işleminden önce secondary sunucunun ne kadar gereden geldiğini tahmin edeceğiz ve failover için uygun adımı gözlemlemiş olacağız.
İlgili AG üzerinde sağ tıklayıp Show Dashboard diyiyoruz.
Aşağıdaki ekranda genel olarak Show Dashboard ekranını görmekteyiz.
Availability mode kısmı Synchronous Commit olduğu için Synchronization State durumu Synchronized olması gerekmektedir. Ama Availability mode kısmı Asynchronous olsaydı. Database’ler secondary sunucusunda Synchronizing durumunda olacaktı.
Synchronous Commit Seçilmesi:
Temel Felsefesi “Önce güvenlik ve tam tutarlılık, sonra hız.” Synchronous işlemi herhangi bir insert update delete primary olan sunucuya geldiğinde işlem ilk olarak primary sunucusunda ilgili veritabanının log dosyasına yazılır. Kullanıcıya işlem tamamlandı bilgisi iletilmez.(uncommitted) SQL Server’ın transaction log kayıtlarını ikincil sunucuya gönderirken kullandığı lock block(genellikle 60 kb civarında) yapısı veriyi paketleme veya paketleme veya gruplama işlemidir. Düşünün ki, ana sunucuda sürekli küçük küçük log kayıtları (her bir INSERT, UPDATE için ayrı kayıtlar) üretiliyor. Her bir kaydı tek tek, anında ikincil sunucuya göndermek son derece verimsiz olurdu. Bu, postaneye her gün tek bir mektup atmaya gitmek gibidir. Bunun yerine, SQL Server bu küçük log kayıtlarını biriktirir, belirli bir boyuta ulaştığında veya belirli bir süre dolduğunda hepsini bir paket (yani Log Block) halinde ikincil sunucuya gönderir. Bu, postaneden haftalık mektupları bir kutuya doldurup tek seferde göndermek gibidir. Çok daha verimli bir işlemdir.
1 Milisaniye Kuralı (Log Flush)
Normal şartlarda SQL Server, log kayıtlarını diske yazarken veya başka bir sunucuya gönderirken 1 milisaniye gibi çok düşük gecikmeleri hedefler. Eğer sistem çok yoğun değilse ve log bloğu (genellikle 60 KB) dolmadıysa bile, SQL Server veriyi göndermek için genellikle bir sonraki “log flush” işlemini bekler.
2. İletişim Protokolü ve Arabellek (Buffer)
SQL Server, veriyi gönderirken Network Packet Size (varsayılan 4 KB) ve Log Block Size (maksimum 60 KB) değerlerini kullanır.
- Boyut Odaklı: Eğer saniyede binlerce işlem yapıyorsanız, 60 KB’lık bloklar mikrosaniyeler içinde dolar ve süre dolmasını beklemeden paketler anında gönderilir.
- Zaman Odaklı: Eğer işlem hacmi çok düşükse, SQL Server bir kaydın sonsuza kadar orada kalmasına izin vermez. Veritabanı motoru, yaklaşık birkaç milisaniye ile 1 saniye arasında değişen iç zamanlayıcılarla (internal timers) bu paketleri “push” eder (iter).
3. Modun Etkisi (Synchronous vs. Asynchronous)
Bu “süre” kavramı, kullandığınız mimariye göre farklı hissettirir:
| Mod | Gecikme Hissi | Süreç |
| Synchronous (Senkron) | Yok denecek kadar az | Ana sunucuda işlem biter bitmez paket gönderilir ve onay beklenir. Süre sınırlayıcı değildir, veri güvenliği önceliktir. |
| Asynchronous (Asenkron) | Çok kısa (Milisoniyeler) | Ana sunucu işlemi bitirir, paketi kuyruğa atar. Arka plandaki bir thread (iş parçacığı) bu paketleri sürekli olarak ikincil sunucuya pompalar. |
Eğer 60 KB’lık bir Log Block gönderilecekse ve network paket boyutun 4 KB ise, bu blok network katmanında parçalara ayrılır. Ancak bu süreci SQL Server değil, alt katmandaki protokoller yönetir.
İşte adım adım nasıl gerçekleştiği:
1. Log Block (Mantıksal Birim)
SQL Server log kayıtlarını rastgele göndermez. Önce bunları bellekte (Log Buffer) toplar. Bu birimin maksimum boyutu 60 KB‘dır. SQL Server için “gönderilecek en küçük anlamlı bütün” budur. Buna bir konteyner gibi bakabilirsin.
2. Network Packet Size (Taşıma Birimi)
SQL Server konfigürasyonunda gördüğün network packet size (varsayılan 4096 byte / 4 KB), SQL Server ile istemci veya diğer sunucu arasındaki “iletişim tünelinin” genişliğidir.
3. Paketleme Süreci (Parçalara Ayırma)
SQL Server 60 KB’lık bir Log Block’u ikincil sunucuya göndermek istediğinde:
- SQL Server bu 60 KB’lık veriyi Network Interface Card (NIC) katmanına iletir.
- Eğer senin network packet size ayarın 4 KB ise, bu 60 KB’lık veri 15 adet network paketine bölünür.
- Bu paketler TCP/IP üzerinden sırayla gönderilir.
- Karşı taraftaki SQL Server (Secondary), bu 15 paketi alıp birleştirerek tekrar 60 KB’lık orijinal Log Block haline getirir ve ondan sonra işler.
Neden 60 KB ve 4 KB Farklı?
- 60 KB (Log Block): Diske yazma verimliliği (Disk I/O) için optimize edilmiştir. SQL Server log dosyasını diskte 60 KB ve katları şeklinde yönetmeyi sever.
- 4 KB (Network Packet): Ağ üzerindeki trafiğin akıcılığı ve hata yönetimi için optimize edilmiştir. Eğer 60 KB’lık veriyi tek bir dev paket olarak gönderseydin ve ağda küçük bir kopma olsaydı, tüm 60 KB’ı baştan göndermen gerekirdi. 4 KB olduğunda sadece kaybolan küçük parça yönetilebilir.
Performans İpucu
Eğer yüksek trafikli bir Availability Group (AG) yapın varsa, network packet size değerini 4 KB’dan 32 KB‘a çıkarmak genellikle performansı artırır. Çünkü 60 KB’lık bir bloğu 15 parça yerine 2 parçada göndermek, paket başlığı (overhead) maliyetini azaltır ve CPU üzerindeki yükü hafifletir. Bu ayarın nasıl değiştirileceğini öğrenmek isterseniz ilgili makale okunabilir.
SQL Server’ın transaction log’u fiziksel bir yapıdır. Log kayıtları, bellekte (log buffer) ve diskte (log file) art arda (sequentially) dizilir. Log Block da bu fiziksel yapının bir parçasıdır. Log block içerisinde tüm veritabanlarının bilgileri tutulmaktadır.
Log block dolduktan sonra ikinci sunucuya gönderilir. İkincil sunucu, bu log kaydını kendi transaction log dosyasına fiziksel olarak yazar ve diske (disk) kalıcı hale getirir. Bu, senkron modun en kritik adımıdır. Bu olay hardining olarak geçmektedir.İkincil sunucu, log kaydını başarıyla diske yazdığını ana sunucuya bir “onay mesajı” (acknowledgement) göndererek bildirir.
Primary sunucusunda ldf dosyasına yazma olayına commit secondary sunucusunda ldf dosyasına yazma olayına log hardining işlemidir.
Ancak ve ancak ana sunucu, ikincil sunucudan bu onay mesajını aldıktan sonra, işlemi kendi transaction log’unda commit eder. Ana sunucu, işlemin başarıyla tamamlandığına dair onayı (commit confirmation) istemci uygulamasına (client application) gönderir. İstemci ancak bu noktada “işlem tamam” bilgisini alır.
Ana sunucu anlık ve beklenmedik bir şekilde çöker (power loss, hardware failure). İşlem, çökmeden hemen önce istemciye commit onayı gönderilmişse, bu işlemin log kaydı kesinlikle en az bir ikincil sunucunun diskine de yazılmış durumdadır. Sıfır veri kaybı (Zero Data Loss) hedefine çok yakınsınız demektir. Kurtarma noktası hedefi (Recovery Point Objective – RPO) teorik olarak 0’dır. Yeni ana sunucu (eski ikincil) failover olduğunda, kayıpsız bir şekilde kaldığı yerden işleme devam eder.
İstemci, işleminin tamamlandığını öğrenmek için, işlemin ana sunucudan ikincil sunucuya gitmesi, ikincil sunucuda diske yazılması ve onayın ana sunucuya geri dönmesini beklemek zorundadır. İstemcinin aldığı yanıt süresi (transaction latency) artar. Bu artış, ana ve ikincil sunucular arasındaki ağ gecikmesi (network round-trip time – RTT) ve ikincil sunucunun disk yazma hızı ile doğru orantılıdır.
İkincil sunucunun yavaş diski veya sunucular arasındaki yüksek ağ gecikmesi, tüm sistemin işlem hacmini (throughput) ciddi şekilde düşürebilir. İkincil sunucu ne kadar yavaşsa, ana sunucu da o kadar yavaşlar.
Asynchronous Commit Seçilmesi:
Asenkron olarak seçilirse sistem siz failover modunu otomatik bir şekilde yapsanızda hata mesajı verecektir. Aslında veriler ms cinsinden yazılır. Kaybolma ihtimali olduğu için bu mesaj yazılmaktadır. Çünkü asenkron modda olan sunucu üzerine veri sonradan commit edilmektedir. Bu modda işlem ilk olarak primary sunucusuna yazılır. Failover olduğunda primary sunucusuna yazılan veri secondary sunucusuna yazılmadan failover olabilir. Buda veri kaybına sebebiyet vermektedir.
Daha detaylı açıklayalım:
Asenkron modun felsefesi “Önce hız ve performans, sonra veri tutarlılığı”dır. Primary, bir işlemin tamamlandığını istemciye bildirmek için ikincil sunucunun secondary onayını beklemez.
Bir UPDATE, INSERT veya DELETE işlemi ana sunucuya gelir. Ana sunucu, işlemin log kaydını (transaction log record) kendi transaction log dosyasına fiziksel olarak yazar ve hemen commit eder (yani, işlemin tamamlandığını işaretler). Ana sunucu, işlemin başarıyla tamamlandığına dair onayı (commit confirmation) hemen istemci uygulamasına gönderir. İstemci işlemin tamamlandığını öğrenir ve yoluna devam eder. İstemciye yanıt gönderildikten sonra, ana sunucu, log kaydını bir Log Block içinde ikincil sunucuya asenkron olarak gönderir. Bu gönderim, ana sunucunun iş yükünden bağımsız olarak, kendi hızında ve planında yapılır. İkincil sunucu log bloğunu alır, kayıtları kendi transaction log’una yazar ve veri sayfalarına uygular (redo). Ana sunucu, bu işlemin ne zaman tamamlandığıyla doğrudan ilgilenmez.
Kötü senaryo sunucu, işlemi commit ettikten ve istemciye onay gönderdikten sonra, ama o işlemin log kaydını ikincil sunucuya göndermeden önce anlık ve beklenmedik bir şekilde çöker. İstemciye “işlem başarılı” dendiği için uygulama işlemin yapıldığını düşünür. Ancak, bu işlemin kaydı ikincil sunucuya hiç ulaşmamıştır. İkincil sunucu yeni ana sunucu olduğunda, bu işlem yoktur. Veri kaybı (Data Loss) yaşanır.
Veri kaybı miktarı, ana sunucunun çöktüğü anda log buffer‘ında birikmiş ama gönderilmemiş ne kadar log kaydı olduğuna bağlıdır. Bu süre saniyeler, hatta yoğun yük altında dakikalar bile olabilir. RPO 0 değildir ve tahmin edilemez.
İstemci, işlemin tamamlandığını öğrenmek için sadece ana sunucunun kendi disk I/O hızını bekler. İkincil sunucunun ağ gecikmesi veya yavaş diski, istemcinin yanıt süresini hiçbir şekilde etkilemez.
İstemci için mümkün olan en düşük işlem gecikmesi (latency) sağlanır. Ana sunucunun işlem hacmi (throughput) üzerinde hiçbir kısıtlama yoktur. İkincil sunucunun durumu ne olursa olsun, ana sunucu maksimum hızda çalışmaya devam eder. İkincil sunucu ana sunucudan çok uzakta olsa bile (örneğin, farklı bir kıtada) performans etkilenmez. Bu, uzak felaket kurtarma (DR) senaryoları için idealdir.
Asenkron modda yapılandırılmış bir ikincil sunucu asla otomatik failover yapısında kullanılamaz. Ana sunucu çökerse, küme yöneticisi (Windows Failover Cluster) asenkron bir ikincil sunucuyu otomatik olarak yeni primary yapmaz. Çünkü bu sunucunun ana sunucuyla tamamen senkron olmadığını ve veri kaybı yaşanacağını bilir. Failover ancak manuel olarak (zorunlu manuel failover – forced manual failover) ve veri kaybı kabul edilerek yapılabilir.
Asenkron mod “gönder ve unut” gibi görünse de, SQL Server arka planda birikimi kontrol eder. Ana sunucu, ikincil sunucuya gönderilmeyi bekleyen log kayıtlarının boyutunu sürekli izler.(log_send_queue_size). Eğer bu kuyruk aşırı büyürse (örneğin, ikincil sunucunun ağı çok yavaşsa veya diski çok dolduysa), bu durum ana sunucuyu dolaylı olarak etkileyebilir. Çok aşırı durumlarda, ana sunucu log kayıtlarını temizleyemeyebilir ve bu da genel performansı etkileyebilir. Ancak, bu istemci işlemlerinin yanıt süresini doğrudan etkilemez.
Asynchronous-Commit seçmek, istemciye “işlem tamam” onayını en hızlı şekilde göndermek uğruna, ikincil sunucunun bu işlemden haberdar olup olmaması riskini almak demektir. Bu, yüksek performans ve uzak mesafeler için ödenen bir “veri tutarlılığı” bedelidir.
Genellikle aynı oda içerisinde olan sunucular fiber kabloyla birbirine senkron bir şekilde bağlanabilir. farklı ortamlarda olan sunucular bir yan oda olsa dahi asenkron modda seçilmesi demektedir. Çünkü veri ilk olarak secondary sunucunun ldf dosyasını commit yaptığı için buda network ve alt yapımıza bağlı olarak performans kaybımıza sebebiyet verecektir.
Senkronizasyon durumları asenkron modunda bırakılırsa herhangi bir manuel failover durumunda sistem kendini secondary sunucusuna atmaktadır. Yeni primary sunucusundaki AG databases sekmesinde tüm veritabanlarını resume yapmak lazım. Veri kaybından dolayı son kullanıcıdan tekrar onay almak içindir. Resume işlemi yapıldıktan sonra eski primary sunucusu yeni primary sunucusu ile kendini eşit hale getirmektedir. Eski primary sunucusunda fazla veri varsa silinir. Neden database AG altında suspend modunda olur. Veri kaybından dolayı veya tekrardan eski ortama dönmek isteyebiliriz. Sync modunda ise böyle bir sorunla karşılaşılmaz.
Disaster Recovery ortamlarında bulunan 3. node genellikle asenkron modda bırakılması gerekmektedir. Sebep farklı bir lokasyonda olduğu için verinin secondary sunucusuna bilgi düşüp primary sunucuna yazdığı için bir zaman kaybına sebebiyet verecektir.
Sonuç olarak:
Senkron Replikasyon: Primary node, değişiklikleri secondary node’a yazar ve onay alana kadar işlemi tamamlamaz. Veri kaybı riski yoktur. Gerçek zamanlı veri tutarlılığı sağlar. Performans düşebilir çünkü işlem ancak tüm kopyalar tamamlandığında başarılı kabul edilir.
Asenkron Replikasyon: Primary node değişiklikleri secondary node’a gönderir ama işlemi tamamlamak için beklemez. Daha hızlıdır ve ağ gecikmelerine karşı dayanıklıdır. Veri kaybı olabilir çünkü ikincil sunucu güncellenmeden primary sunucu çökebilir.
Hangi durumlarda hangisini kullanılması gerekmektedir. Senkron Mode’da, Aynı veri merkezindeki (low-latency) sunucular arasında, Gerçek zamanlı tutarlılık gerektiren finans ve kritik sistemlerde, Primary ve secondary node’lar yüksek hızlı ağ bağlantısına sahipse kullanılmaktadır. Asenkron Mode, Uzak veri merkezleri arasında (WAN bağlantılı), Felaket kurtarma (Disaster Recovery – DR) sistemlerinde, Performansın tutarlılıktan daha önemli olduğu durumlarda
Çok yoğun transaction olan sistemlerde asenkron olması tavsiye edilir. İki sunucudada bu işlem yapılır çünkü güncel olan sunucu başka zamanda secondary olabilir.
Not: Asenkron mod aktif edilirse show dashboard ekranında secondary sunucusu ünlem işareti olarak görülmektedir. Senkron moda çekildiğinde bu ibare kaybolmaktadır.
Bazen AG’yi senkron tanımlasak ve veritabanları senkron gözükmesine rağmen çeşitli sebeplerden dolayı geriden gelebilir. Şimdi bu geriden geldiğini görmek için bazı kavramlara değinmiş olacağız.
Synchronous commit olduğu için Failover Readiness kısmı ikinci sunucuda No Data Loss seklinde olması lazım. Ama Asynchronous olsaydı secondary sunucusunda Data Loss şeklinde gözükecekti.
Not: Alwayson yapısında Availability mode Asynchronous commit modunda olursa herhangi bir switch over işleminde data loss görülmektedir. Bu durumlarda veritabanını synchronous commit moduna alırız. Bu durumda primary ve secondary sunucusunda bulunan veritabanlarının ldf dosyaları aynı seviyeye geldikten sonra No data loss görülmektedir. Ldf dosyaları eşitleme işlemine kadar data loss şeklinde görülmektedir. Ldf dosyası eşitlendikten sonra failover işlemi olursa secondary sunucusu yeni primary sunucusu reverting moduna geçmektedir. Bu sefer veritabanları data file seviyesinde eşitleme işlemi olduktan sonra Synchronized görülmektedir.
Asenkron olduğunda ise bu işlemin tam tersi olmaktadır.
Gösterge ekranına bazı kolunlar eklemek için Add/Remove Colums’a tıklıyoruz.
Gelen ekrandaki değerlere tıklayarak Show Dashboard ekranına ekleyebiliriz.
Sorunlar ve Durumlar aşağıdaki ifadeler kullanılmaktadır.
- Issues: Replika ile ilgili olası hatalar veya problemler gösterilmektedir.
- Suspended: Replikanın durdurulup durdurulmadığını gösterir. (True/False)
- Suspend Reason: Eğer replika durdurulduysa neden durdurulduğunu gösterir.
Not: Always on yapısında olan bir veritabanında herhangi bir tablo truncate edildiğinde ne gibi ne senaryolar yapılması yapılmaktadır. Öncelikle sql serverda tablo bazlı restore işlemi yoktur. Veritabanı bazlı restore işlemi olmaktadır. Tablo truncate edilmeden önce Always on altında ilgili veritabanı pause edilip veri akışı secondary sunucuna yapılmamasına yapılmaktadır. Eğer veritabanı servis aracılığıyla alınıyorsa ilgili veritabanının diğer kolonlarına veri akışı gelmektedir. Sadece ilgili veritabanı servis aracılığıyla alınır. Eğer çok büyükse primary makina üzerinde aynı veritabanı test olarak restore edilir son ana kadar verileri ordan alıp daha sonra servis aracılığıyla fark veriler alınabilir. Eğer canlı veritabanı alan bir tablo ise truncate komutu ile tablo silindi son ana kadar veritabanı başka bir isimde dönülür. Örneğin en son backup işlemden 10 dakika öncede alınmışsa 10 dakikalık veri kaybı olmaktadır.
Kurtarma ve Veri Kaybı Tahminleri aşağıdaki ifadeler kullanılmaktadır.
- Estimated Recovery Time (seconds): Olası bir failover durumunda ne kadar sürede toparlanabileceğini gösterir.
- Estimated Data Loss (time): Asenkron modda bir failover olursa ne kadar veri kaybı yaşanabileceğini tahmin eder.
Log Gönderme ve Alma Bilgileri aşağıdaki ifadeler kullanılmaktadır.
Last Sent LSN & Time (Primary Tarafı)
Bu değerler, “Kaynağın” (Primary) görevini ne kadar güncel yaptığını gösterir.
- Primary sunucunun Transaction Log’u okuyup karşı tarafa paketleyip gönderdiği son noktadır.
- Eğer Last Sent LSN değeri artmıyorsa, Primary sunucu logları okuyamıyor veya network üzerinden dışarı çıkaramıyor demektir.
- Last Sent Time ile şu anki zaman arasındaki fark açılıyorsa, gönderim sürecinde bir duraksama (örneğin network kopukluğu) var demektir.
Last Received LSN & Time (Secondary Tarafı)
Bu değerler, “Hedefin” (Secondary) veriyi ne kadar başarıyla teslim aldığını gösterir.
- Secondary sunucunun kapısında duran kuryeden teslim aldığı son paketin kimliğidir.
- Bu değer, verinin yazıldığı (Redo) anlamına gelmez, sadece ulaştığı anlamına gelir.
- Last Sent LSN ile Last Received LSN değerleri aynı olmalıdır. Eğer gönderilen (Sent) değer, alınan (Received) değerden büyükse, veri yolda (network katmanında) takılmış veya kuyruğa girmiş demektir.
Bu metrikleri birbiriyle kıyaslayarak sistemdeki darboğazı (bottleneck) tespit edebilirsiniz:
| Durum | Olası Sorun |
| Sent LSN > Received LSN | Network Gecikmesi: Veri gönderilmiş ama henüz karşı tarafa ulaşmamış. Network bant genişliği yetersiz olabilir. |
| Sent Time – Received Time Farkı | Latency (Gecikme): Verinin bir uçtan diğer uca gitmesi için geçen süre. Senkron modda çalışıyorsanız bu fark doğrudan “Commit” süresini uzatır. |
| Received LSN > Redo LSN | Harddisk Darboğazı: Veri Secondary’e ulaştı ama diske işlenemiyor (Redo Queue birikiyor). |
Diyelim ki bir finansal işlemin log kaydı oluştu:
- Primary: “Ben 1005 numaralı LSN’i saat 12:00:01’de gönderdim.” (Last Sent)
- Secondary: “Ben 1005 numaralı LSN’i saat 12:00:02’de aldım.” (Last Received)
- Analiz: 1 saniyelik bir network gecikmeniz var demektir.
Log Gönderme ve Senkronizasyon Metrikleri Aşağıda Belirtilmiştir.
1. Log Send Queue Size (KB) – “Kamyon Bekleyen Mallar”
Fabrikada (Primary) üretilen ama henüz kamyona yüklenip yola çıkmamış olan paketlerin toplam ağırlığıdır.
- Veri tabanında işlemler yapıldı ama bu değişiklikler henüz karşı tarafa gönderilmedi.
- Bu değer yükselirse, bir felaket anında veri kaybı (RPO) riskiniz artar. Çünkü bu “kuyruktaki” veriler henüz sadece ana sunucudadır.
2. Log Send Rate (KB/sec) – “Kamyonun Hızı”
Verilerin internet veya yerel ağ (network) üzerinden karşı tarafa akış hızıdır.
- Saniyede kaç KB veriyi karşıya gönderebiliyorsunuz?
- Eğer Log Send Queue Size büyüyor ama Log Send Rate düşükse, ağ bağlantınızda (bandwidth) bir darboğaz var demektir.
3. Redo Queue Size (KB) – “Depo Kapısındaki Paketler”
Kamyon uzak depoya (Secondary) ulaştı ve paketleri indirdi. Ancak bu paketler henüz raflara dizilmedi (veritabanına işlenmedi).
- Secondary sunucu veriyi teslim aldı ama henüz SQL sorgularıyla okunabilir hale getirmedi.
- Eğer bu kuyruk çok büyürse, Secondary sunucudan rapor çekiyorsanız veriler “eski” kalır. Ayrıca failover (sistemi devretme) süresi uzar çünkü sistem açılmadan önce bu sıradaki tüm işleri bitirmek zorundadır.
4. Redo Rate (KB/sec) – “Raf Dizme Hızı”
Secondary sunucunun gelen logları ne kadar hızlı işleyip veritabanına yazdığıdır.
- Secondary sunucunun işlemci (CPU) ve disk yazma performansını temsil eder.
- Eğer Redo Queue birikiyorsa ama Log Send Rate yüksekse; sorun networkte değil, Secondary sunucunun disklerinin veya işlemcisinin yavaş kalmasındadır.
5. FileStream Send Rate (KB/sec) – “Özel Kargo Hattı”
Eğer veritabanınızda fotoğraf, video veya doküman gibi büyük dosyalar (FileStream) tutuyorsanız, bunların gönderilme hızıdır.
- Standart tablo verileri dışında kalan büyük “blob” dosyaların transfer hızı.
- Bu dosyalar çok büyük olduğu için normal log trafiğini yavaşlatabilir.
Özetle
| Metrik | Neyi Temsil Eder? | Sorun Kimde? |
| Send Queue ↑ | Gönderilemeyen Veri | Network veya Primary |
| Send Rate ↓ | Yavaş Bağlantı | Network Hattı (Bant Genişliği) |
| Redo Queue ↑ | İşlenemeyen Veri | Secondary Sunucu (Disk/CPU) |
| Redo Rate ↓ | Yavaş Yazma | Secondary Sunucu |
NOT: Secondary sunucularda sadece redo işlemi gerçekleşir. Checkpoint işlemi sadece primary olan sunucuda gerçekleşmektedir. Bu işlem diske yazılma hızlarıdır.
Şunu belirtmek gerekirse Primary sunucusuna gelen istek ilk olarak buffer manager’e yazılır.(buffer log) Daha sonra buffer üzerindeki veri log hardened yardımıyla ldf dosyasına yazılmaktadır. Primary sunucundaki veri secondary sunucusunda ilk olarak buffer manager kısmına yazılmaktadır. Daha sonra log hardened ile secondary sunucusunun ldf dosyasına yazılmaktadır. Bizlerin show dashboard ekranından redo değerine bakmamız ldf dosyasında bulunan verinin mdf dosyasına yazılma zamanı, kuyrukta bekleyen veri miktarı ve eklenen son data değerini görmekteyiz. Aslında redo değerine bakmamız son kullanıcının veri okumasına ne kadar geriden geldiğini bulmasıdır.
Log Hardened Time: Secondary sunucusunun tam replike olabilmesi için primary sunucusundan gelen isteklerin diske yazılması gerekmektedir. Ldf dosyasına yazılması için gerçekleşen işlemdir.
Hardening, bir log kaydının (log record), geçici bellek alanından (log buffer) kalıcı depolama birimine (LDF dosyası) fiziksel olarak ve güvenli bir şekilde yazılma işlemidir. SQL Server, bir işlemin kalıcı (durable) sayılabilmesi için, önce o işlemin log kaydının diske yazılması gerektiği kuralına uyar.
Hardening, WAL’ın kendisi değil, onun bir kuralıdır.
- WAL (Write-Ahead Logging): “Veri dosyasındaki (MDF) değişiklikleri diske yazmadan önce, mutlaka ilgili log kaydını (LDF) diske yazmalısın” diyen genel mimaridir.
- Hardening: Bu mimari içindeki, logun diske fiziksel olarak güvenli bir şekilde “mühürlenmesi” (yazılması) anıdır.
Özetle: WAL bir stratejidir, Hardening ise bu stratejiyi gerçekleştiren fiziksel eylemdir.
Log Uygulama (Hardened) ve Redo Süreçleri aşağıda verilmiştir.
- Last Hardened LSN: Secondary sunucunun ldf diskine kalıcı olarak yazılan en son LSN değeri.
- Last Hardened Time: Secondary sunucunun ldf diskine kalıcı olarak yazılan hardened LSN’in ldf diskine yazıldığı zamanı vermektedir.
- Last Redone LSN: Secondary sunucunun ldf dosyasında bulunan lsn değerini mdf veya ndf dosyasına yazdığı en son lsn değeridir.
Last Redone Time: Secondary sunucunun ldf dosyasında bulunan lsn değerini mdf veya ndf dosyasına yazdığı LSN’in işlendiği zamanı göstermektedir.
Son Log Kayıtları aşağıda belirtilmiştir.
Last Commit LSN: Primary sunucudaki en son commit edilen transaction’ın LSN değeri.
Last Commit Time: En son commit edilen transaction’ın zamanı.
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ış.
Aşağıdaki kod bloğunda AlwaysOn yapısındaki herhangi bir veritabanının primary ve secondary sunucusundaki senkron durumlarını görebiliriz. Aşağıdaki çalıştırdığım ikinci komutla senkron bir şekilde görülebilir.
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS ag_name,
dhdrs.synchronization_state_desc,
dhdrs.is_commit_participant,
dhdrs.last_sent_lsn,
dhdrs.last_sent_time,
dhdrs.last_received_lsn,
dhdrs.last_hardened_lsn,
dhdrs.last_redone_time
FROM sys.dm_hadr_database_replica_states AS dhdrs
INNER JOIN sys.availability_databases_cluster AS adc
ON dhdrs.group_id = adc.group_id AND
dhdrs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = dhdrs.group_id
INNER JOIN sys.availability_replicas AS ar
ON dhdrs.group_id = ar.group_id AND
dhdrs.replica_id = ar.replica_id
where database_name='DB_NAME'
Aşağıdaki script yardımıyla Secondary sunucunun primary sunucuya göre ne kadar geriden geldiğini bulabilirsiniz. 1 saat üzerinden fazla olan veritabanlarıyla ilgili kayıt dönmektedir. Aşağıdaki dönen ilgili veritabanları yukarıdaki komut ile kordineli çalıştırdığımızda mantık anlaşılıyor.
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
Availability Group (AG) yapısında Synchronous (Senkron) mod kullanıyorsanız süreç şu şekilde işler:
- Primary log kaydını oluşturur.
- Log kaydı Secondary sunucuya gönderilir.
- Secondary sunucu bu logu kendi Log Buffer‘ına alır.
- Secondary, bu logu kendi diskine (LDF) yazar (Log Hardening).
- Secondary, Primary’ye “Ben logu diske güvenle yazdım (hardened)” bilgisini gönderir.
- Ancak bu aşamadan sonra Primary işlem bitti (Commit) diyebilir.
Availability Group (AG) yapısında Asenkron mod kullanıyorsanız süreç şu şekilde işler:
- Primary log kaydını oluşturur ve kendi diskine yazar (Hardening).
- Primary, Secondary’den herhangi bir onay beklemeden işlemi “COMMIT” eder (Tamamlandı sayar). Kullanıcıya “İşlem başarılı” cevabı anında döner.
- Log kaydı arka planda Secondary sunucuya gönderilir.
- Secondary sunucu bu logu kendi Log Buffer‘ına alır.
- Secondary, logu kendi diskine (LDF) yazar (Log Hardening).
- Secondary, Primary’ye “Ben yazdım” bilgisini gönderse bile, Primary zaten çoktan başka işlemlere geçmiştir. Bu bilgi sadece durum takibi (monitoring) için kullanılır.
Başka bir makalede görüşmek dileğiyle…
“Onlar, amelleri, dünyada da, ahirette de boşa gitmiş kimselerdir. Onların hiç yardımcıları da yoktur. “Âl-i İmrân-22
