Bu metinde Ctp sürümünden beri incelediğim sql server 2014 versiyonu ile geçiş maceramız sonucu elde ettiğim deneyimleri paylaşacağım;
Microsoft'un 2012 den beri bağırdığı in-memory mevzusu ( Pdw ile) her ne kadar beni çok heyecanlandırsa da bir türlü olgunlaşmamış meyve izleniminden kurtulmadı.
Temp tablolar yerine in memory tabloları kullanmak güzel sonuçlar versede ben caselerimde yapımıza daha ilerisini mantıklı olarak oturtamadım.
Tabi ki case'e göre kullanım durumu çok çok artırılabilir ancak sahip olduğu kısıtlar yüzünden neredeyse kullanılmayacak kadar atıl duruyor.
Asıl üzerinde en çok durduğum konu ise
AlwaysOn oldu.
Bilindiği üzere ilk olarak 2012 ile doğmuş 2014 ile gelişimini sürdüren teknoloji de henüz olgunlaşmamış diyebilirim.
Sql 2000 versiyonu nu kullanmış biri olarak çok sıkıntılar yaşadığım active sencronizasyon ve replikasyon olayını bir türlü sorunsuzca yapamadığımız ms sql bu sefer replikasyon, logshipping ve diğerlerinden çok daha efektif bir teknoloji ile geldi karşımıza, kullanışı ve kurulumu çok basit olan aynı oranda Yönetimi'de ileri derecede kolaylaştırılmış bu teknoloji hakkında izlenimlerimi paylaşacağım .
Önce kurulumuna değineceğim;
Kurulum yapmak için gereksinimizi iyi belirlemelisiniz. Şöyle ki 1 primary (yani kaynak sunucu) ve bir den çok active ve + ve ya pasif secondary sunucu ( replikalar) ile kolayca kurulum yapabilirsiniz.
Tabi iyi belirlemeniz gereken; ihtiyacınız doğrultusunda replika adedi seçiminizi ve bunların
active replika = senkron kopya mı
pasif replika = asenkron kopya mı olmasına karar vermek çok önemli, çünkü performansı önemli ölçüde etkileyecek bir tercih yapacaksınız.
Primary Replica : Kaynak database
Pasif Secondary : Eş zamanlı data transferi yok.
Active Secondary : Eş zamanlı data transferi var.
Nasıl etkiler sorusunun cevabı: commit olayı kaynak sql in (primary sunucu ) senkron kopyaların kaynaktan gelen transactionın teker teker commit dönmesini bekleyecek olması dır.
Neden ise : alwayson yapı gereği senkron kopyalara kaynakta açılan transactionı commit ederek kopya dbler ile senkronizasyonu sağlamaktadır. Bu sebeple kaynakta açılan transaction senkron sunuculardan commit yapıldı bilgisi gelene kadar açık kalıp commit olmayacak dır. Bu sebeple senkron kopya seçimi çok dikkat arzetmektedir.
Testlerim sonucunda bir kayıtlı insert işlemi dahi standalone database e oranla 2-3 ms geç cevap vermektedir, ilerleyen zamanlarda insert ve update gecikmelerini gidereceklerini microsoft danışmanlarımızdan öğrenmiş olsamda ne kadar performansa yansıyacağını zamanla göreceğiz.
Yapımızı her ne kadar fiber altyapı üzerine kursakta (
Buarada şunuda belirtmek isterim ki, AlwaysOn log based bir teknolojidir, Attunity şirketinden log based data transfer lisansını alarak sql server'a uygulamışlardır. Bu her ne kadar fiber networkunuz olmasada aslında networkte sorgunuzun çok zaman kaybetmeyeceği anlamına geliyor. ) tek senkron kopya seçmeme rağmen özellikle insert işlemlerin de üstelik flash storage performansı altında yeterli performans yakalayamadığımı düşünmekte ve de gözlemlemekteyim.
Not; beklediğim bir durum du açıkcası.
Ben senaryomuz gereği 1 aktif replika (senkron kopya) 1 pasif replika (asenkron kopya ) toplam 3 adet sql sunucu ile kurulum , yönetim , geliştirme ve performans testleri yaptım. (Uzun bir süre ve farklı storage artı farklı swich altyapısı altında, üstelik Firewall dan bağımsız bir yapıda)
Burada şunuda belirteyim asenkron kopyaların alwayson'un performansına hiç bir olumsuz etkisi yoktur. Yine daha önce belirttiğim transaction log dosyasından, bir nevi logshippingde olduğu gibi log dan data asenkron kopyaya iletilecektir, bu sebeple kaynak database e yük getirmeyecektir.
Dezavantajı olarak data eş zamanlı olarak asenkron kopyaya işlenmediği için fail-over durumda işlenilmemiş datalar olduğu için asenkron kopyaya failetmek zaman alacaktır (yüke göre 1-20 dakika arası bekleme değerleri gördüm.) bu süre zarfında asenkron databaseiniz restoring durumda olacaktır.
Data kaybı ise failover sırasında iletilmeyi bekleyen loglardan kaynaklı yaşanabilir.
Pasif replikayı rapor sunucusu olarak kullanmayı aktif sunucuyu ise fail-over için saklamayı bu sebeple üzerine transaction vermeyip aynı zamanda kaynak sunucu performansının olumsuz etkilemesini en az yaşamasını sağlamayı planladım.
Çünkü aktif secondary üzerindeki yük kaynaktan gelen transactionının commit olma süresini etkileyecek hatta lock bile koyabilecektir.
Bunu unutmamanızı ve mimari seçiminizi yaparken gözönünde bulundurmanızı şiddetle tavsiye ederim.
ilk yaptığımız Testler sırasında senkron kopya üzerinde datanın olması gerektiği gibi eş zamanlı olarak eşlenmediğine bile şahitlik ettim:) sebebine hala vakıf olamadık, ama çok yoğun transactionlar olduğu için belki senkron kopyada commit olmadan değerleri okumuş olabilirim diye de alwaysOn'a hüsnü niyyetle yaklaşmak isterim.
Yine bu yoğunluğu bağlı olarak asenkron kopyada data bazen saatlere yakın gecikmeler yaşamaya başladığını gözlemledim.
Bunların hepsinin ekran görüntüsünü alamadığım için buraya koyamamamın nedeni, testler uzun bir sürece yayıldığı için aldığım görüntülerin bir çoğu ya silindi ya da üzerine diğer görüntüler yazılması nedeniyle kayboldu.
İlk testlerimizde yaşadığımız sorunların bir tanesi de, Senkron kopyada bulunan databasein failover sırasında yine transaction yoğunluğuna bağlı olarak (çok ilginçtir) restoring durumda bir müddet kalıyor olması dır. Yaklaşık 30 dakika fail edilen database'in restoring durumda kalması bizde Always
OFF terimini gündeme getirdi. Çünkü sql server eski teknolojisi olan cluster yapısı bu bekleme süresinin çok çok altında bir sürede fail etmekte olduğunu gayet yeterli derecede tecrübe etmiştik, hala daha ediyoruz. Böyle bir fail over senaryosu bence baya maliyetli olur. Bunu illa ki değerlendirip services packlerle önlemini alactırlar.
Uzmanlar tarafından olmaması gerekiyor şeklinde yorumlanan bu durumu," ancak kaynaktan gelen transactionlar henüz kaynaktan gönderildiğinde commit olmadığı için onların commit olması sırasında restoring durumdasınız dır." diye kabullendik. eve incelediğimizde gerçekten de IO yu beklediğimizi gözlemledik.
Aslında olması gereken transaction bazlı senkronizasyonda database zaten commit olan sorguları tamamlamış ve eşlenmiş durumda olmalıdır diye biliyoruz. Yanılıyor muyum ?
Sorunun kaynağının IO dolayısıyla disk olduğu varsayımından yola çıkarak flash memory disklere yönelip testlerimizi bu diskler üzerinde gerçekleştirmeye devam ettik.
Sonuçlar daha iç açıcı olsada yinede bazı uçuk rakamlara rastlamadık değil, vaad edile saniye de 1 gb değerlerine asla ulaşamadık bu bir.
sebebi için yapımız ve sunucularımız destek kısıtları hatta işletim sistemi kısıtları mazeretleri karşımıza çıktı.
Bu mazeretlerle bile saniyede 350 mb yazma garanti olarak ( altını asla görmediğim bir değerdir ) bir disk yapısında teslerimizde yukarıda belirtiğim değerlerin dahada aşağılara indiğini ama kesinlikle sıfırlanmadığını belirtmek isterim.
Bu yapıda ki mazretlerin giderildiği sunucu ve network ortamı ile gerçekleştirdiğim testlerin sonuçlarını en yakın zamanda paylaşmaya devam edeceğim.
