Bu makalede kurulu olan AlwaysOn yapısına yeni bir database yöntemini ele almış olacağız. İlk başta microsoft’un sayfasından indirmiş olduğum bir database’i alwayson yapımıza ekleme işlemini görmüş olacağız. Anlamamız açısından ekran görüntüleriyle bu işlemleri yapmış olacağız.
SQL Server Always On Availability Groups (AG) yapısında bir veritabanını Full + Log Backup (Manual Seeding yerine) yöntemiyle secondary sunucuya dahil etmek, özellikle büyük ölçekli ve kritik sistemlerde hala en çok tercih edilen “geleneksel ama güvenli” yöntemdir.
Bu yöntemde, primary sunucudan alınan bir Full Backup ve ardından gelen Transaction Log yedekleri secondary sunucuya NORECOVERY modunda restore edilir. Ardından veritabanı Availability Group’a dahil edilir.
Avantajları
- Ağ Kontrolü: Veri transferini SQL Server’ın kendi “Automatic Seeding” mekanizmasına bırakmazsınız. Backup dosyalarını sıkıştırıp (compression) farklı bir kanaldan veya fiziksel diskle taşıyabilirsiniz.
- Kesintiye Karşı Dayanıklılık: Automatic seeding sırasında ağ koparsa işlem en baştan başlar. Backup yönteminde ise kaldığınız log dosyasından devam edebilirsiniz.
- Büyük Veritabanları (VLDB): Terabaytlarca veriniz varsa, network üzerinden stream etmek yerine yedek alıp taşımak çok daha yönetilebilirdir.
- İzlenebilirlik: Restore aşamalarını tek tek takip edebilir, nerede hata oluştuğunu (LSN uyumsuzluğu vb.) net görebilirsiniz.
Dezavantajları
- Manuel işlem gerektirir (yedek al, taşı, restore et, join et).
- Hem primary hem secondary (veya ortak bir share) üzerinde devasa backup dosyaları için boş alan gerektirir.
- Veritabanı çok büyükse, backup ve restore süreleri veritabanının secondary üzerinde ayağa kalkma süresini uzatır.
Log Şişmesi Meselesi (Kritik Nokta)
Log dosyasının dikkat edilmezse şişmesine sebep olur.
- Bir veritabanını AG’ye dahil ettiğinizde, SQL Server secondary sunucuya gönderilmemiş log kayıtlarını “truncate” etmez (silmez). Eğer siz Full Backup aldınız ve restore işlemi 5 saat sürdü; bu 5 saat boyunca primary’de oluşan tüm loglar, secondary henüz “Synchronizing” aşamasına geçmediği için primary diskinde birikmeye başlar.
- Restore işlemi biter bitmez veritabanını AG’ye join etmeniz ve ardından primary’de tekrar bir Log Backup almanız gerekir. Join işlemi gerçekleştiği an, primary ve secondary arasındaki LSN (Log Sequence Number) zinciri eşleşir ve SQL Server artık güvenle logları temizleyebilir.
“LDF dosyasındaki LSN’ler ne zaman silinir (truncate edilir)?” sorusunun cevabı şudur:
Primary sunucuda bir Log Backup aldığınızda, SQL Server log dosyasını temizlemek (truncate etmek) ister. Ancak AlwaysOn yapısında SQL Server şu iki şartın da gerçekleştiğinden emin olur:
- Log yedeğinin başarıyla alınmış olması.
- Bütün Secondary replica’ların o LSN (Log Sequence Number) değerine kadar olan kayıtları aldığını ve diske yazdığını onaylaması (hardened).
Eğer bir Secondary sunucu çevrimdışıysa veya Full Backup henüz restore edilmediği için logları işleyemiyorsa, Primary sunucuda istediğiniz kadar Log Backup alın, .ldf dosyası küçülmez ve LSN’ler silinmez. Primary sunucu, “Secondary henüz bunları almadı, silersem aradaki bağı koparırım” diyerek logları saklamaya devam eder.
| Durum | Neden Bu Yöntem? |
| Düşük Bant Genişliği | Primary ve Secondary arası ağ yavaşsa, Automatic Seeding sistemi kilitler. Backup’ı sıkıştırıp taşımak mantıklıdır. |
| Çok Büyük Veritabanları (VLDB) | 5TB+ veritabanlarında Automatic Seeding hata yapmaya meyillidir. Kontrollü restore hayat kurtarır. |
| Farklı Lokasyonlar | Disaster Recovery (DR) merkezi başka bir şehirdeyse, veriyi kargoyla veya özel hatla taşımak gerekebilir. |
| Karmaşık LSN Yapıları | Hali hazırda çalışan bir backup chain (yedekleme zinciri) varsa, bu zinciri bozmadan sürece eklemleme yapmak daha sağlıklıdır. |
Not: AG yapımızda olan bir veritabanı secondary sunucusunda restoring moduna düştüğü zaman mevcut veritabanında bulunan log veya yeni alınacak diff backup norecovery modda restoring modunda olan veritabanının üzerine restore işlemi gerçekleştirip AG yapısına dahil edilir.
İlk başta indirmiş olduğum database’i sql server’a restore yapalım. Databases’ın üzerine sağ tıklayıp Restore Database sekmesine tıklıyoruz.
AdventureWorks2012 veritabanını indirmiş olduğum klasörden Device bölümünde seçiyorum.
Ok ikonuna bastıktan sonra veritabanının backup’ını doğru bir şekilde almış oluyorum.
Veritabanımızı sql server’a restore ettikten sonra AlwaysOn ekleme adımlarına geçebilirz.
AlwaysOn’da oluşturmuş olduğumuz AG üzerine geldikten sonra Availability Databases sekmesinden Add Database diyoruz.
Gelen ekranda Next dedikten sonra bir sonraki adıma geçiyoruz.
Aşağıdaki resimde AdventureWork2014 veritabanının zaten availability group’da olduğunu söylüyor. AlwaysOn’a dahil edeceğimiz veritabanı için bize ilk başta ilgili veritabanını full recovery moda almam gerektiğini söylüyor. Çünkü full modda yapılan her işlem ldf dosyasında tutulduğu ve secondary sunucuda bu ldf dosyasını referans aldığı için full moda çekilmesi gerekmektedir.
Veritabanımızı full moda alalım. Veritabanımız üzerine sağ tıklayıp properties diyiyoruz.
Daha sonra gelen ekranda options kısmından recovery model kısmını full yapıyoruz. Secondary ldf dosyasını referans aldığı için bu işlemi yapıyoruz.
Ok butonuna basıp tekrar AlwaysOn database ekleme ekranına gelip refresh yapıyorum. Refresh yaptıktan sonra bu sefer benden full backup almam gerektiğini söylüyor.
AlwaysOn yapısı kendini garanti altına almak için full backup almamız gerektiğini söylüyor. Bunun için restore ettiğimiz database üzerine sağ tıklayıp task bölümünden backup seçeneğini seçip backup alma işlemlerini yapıyorum.
Sağ tarafta bulunan add sekmesini seçtikten sonra backup alacağımız yolu belirtiyoruz.
Backup işlemini başarılı bir şekilde almış olduk.
Backup işlemimizi başarılı bir şekilde aldıktan sonra AlwaysOn database ekleme ekranına tekrar gelip refresh yapıyorum.
Artık database AlwaysOn yapısına eklenebilir durumda. İlgili database’i seçip next deyip bir sonraki aşamaya geçiyoruz.
Yeni gelen ekrandan connect deyip secondary sunucumuza bağlanıyoruz. Birden fazla replicamız varsa ikisinide connect deyip bağlarız.
Connect butonuna tıklıyoruz.
Yukarıdaki resimde S2 makinamıza bağlandığımızı görüyoruz hangi User name ile bağlandığımızın bir önemi yoktur.
Next deyip bir sonraki ekrana geçiyoruz.
Yukarıdaki ekranda full database and log backup modu ile backup almaya çalışacağız. Bu yapı S1 ve S2 makinanın ortak göreceği bir klasör olması gerekiyor S1 makinası primary olduğu için backup’ı belirtilen klasöre döndürmüş olacak S2 sunucusuda bu yoldan backup’ı alıp üzerine dönmüş olacak.
Büyük databaselerde bu yöntem ile ilerlenebilir.
İlk başta S1 sunucumuzun herhangi bir disk’inde bulunan bir klasörü Sharing yapıp açalım. Ben Backup diskinin içerinde bulunan backup klasörünün altından ABC diye bir klasör açıyorum. Backup diski altında bulunan backup klasörünü paylaşıma açıp AlwaysOn adımlarımıza devam edelim.
S1 sunucusu üzerinde backup diskimi açıyorum.
Daha sonra belirtmiş olduğum isimde backup klasörü altında yeni bir klasör oluşturuyorum.
Bir üst klasöre gelip BACKUP klasörünü Sharing yapısına geçiriyorum. Backup klasörüne sağ tıklayıp properties dedikten sonra Sharing kısmına gelip Advanced Sharing kısmına tıklıyorum.
Gelen ekranda Share this folder kısmını işaretleyip apply deyiyorum. Apply dedikten sonra permission kısmından yetkimi veriyorum.
Permissions bölümüne tıklıyorum.
Gelen ekranda everyone’a full kontrol yetkisi verilmesi tavsiye edilmez. Sql server’ın yapacağı tüm işlerde database engine’a tanımladığımız sql server servisi sorumludur.
Servisimiz aşağıda gözükmekte.
Bu servisin eklenmesi için yukarıdaki resimde add kısmına basıp active directory üzerinden servisimizi seçiyoruz ve full kontrol yetkisi veriyorum.
Servisi ekledikten sonra full kontrol yetkisi veriyorum.
Şimdi oluşturmuş olduğum Sharing yolunu AlwaysOn ekranımdaki ilgili yere kopyalayıp yapıştırayım.
Kopyaladıktan sonra AlwaysOn ekranıma yapıştırıyorum.
İlgili paylaşım kopyalanıp AlwaysOn’daki belirtilen ekrana yapıştırılır.
Full database and log backup seçersek, seçtiğimiz her veritabanının full backup’ını ve log backup’ını otomatik olarak alıp secondary sunucuya kendisi aktarır ve bu işlem için iki instance’ın sql server servis hesaplarının okuma ve yazma yetkisi olan bir paylaşım/share ister.
Join only seçersek, seçtiğimiz her veritabanının full backup’ını ve log backup’ını manual olarak alıp manual olarak secondary sunucuya bu adımı geçmeden önce aktarmamız gerekir.
Skip initial data synchronization’ı seçersek yine her veritabanının full backup’ını ve log backup’ını manual olarak alıp manual olarak secondary sunucuya aktarmamız gerekir ama bu işlemi daha sonra yaparız. Secondary sunucusuna manuel join işlemi yaparız.
Aşağıdaki resimde tanımlamış olduğumuz paylaşım klasörüne kısa bir bilgi atıldığını görmüş oluyorum. Next deyip bir sonraki aşamaya geçiyoruz.
Finish deyip işlemlerimi tamamlıyorum.
Kurulum işlemi başarılı bir şekilde gerçekleşmiş oldu.
Tanımlamış olduğum paylaşım klasörüne primary sunucum aşağıda görüldüğü gibi full ve log yedek alınmış oldu.
İkinci sunucuma bağlanıp kontrol ettikten sonra ilgili veritabanımın restoring modunda olduğunu görmüş oluyorum.
NOT: Sql server’la ilgili her işlemlerde sql server servisi yetkilidir ona yetki verilmesi lazım.
Şunu da teyit edelim primary sunucusunda hangi yoldaysa data ve log dosyam secondary sunucusunda aynı yerde oluşmuş durumda(Aşağıdaki Resimlerde Görülmektedir.) AlwaysOn kurulumunda disk kısımlarının aynı olmasından bahsetmiştik.Aynı disk uzantısı yoksa secondary instance’ın default disk uzantısılarında mdf ve ldf dosyamız oluşmaktadır. Aynı işlem auto seeding modunda da geçerlidir.
En son yapmamız gereken secondary sunucuda restoring modda olan veritabanını AlwaysOn yapısına dahil etmek secondary’de AG altına gelip sağ tıklayıp join dememiz yeterli. Tabi bu işlem Auto seeding modunun manuel olmasından dolayı. Auto seeding yapısı otomatik olursa secondary sunucusuna eklenmektedir.
Başka bir makalede görüşmek dileğiyle..
“Rabbimiz! Şüphesiz sen, hakkında şüphe olmayan bir günde insanları toplayacaksın. Şüphesiz Allah va’dinden dönmez. “Âl-i İmrân-9
