Bu makalemizde SQL log shipping yapılandırma işlemlerini ele alıyor olacağız. Son yıllarda yazılımların çok hızlı gelişmesi, buna paralel olarak sanallaştırmanın hızlı ivme kazanması ile birlikte sistemlerin yüksek erişilebilirliği ve yük dağılımı noktasında bir hayli mesafe kat edilmiş durumda. Biz bu yeniliklerden makalemize konu olan SQL tarafına yoğunlaşacağız. Öncelikle “Log Shipping nedir?” bunu açıklayalım.
Aşağıdaki şeklimize göre açıklayacak olursak, veri tabanı üzerinde yapılan konfigürasyondan sonra aynı sunucu üzerindeki farklı bir instance veya farklı bir sunucu üzerindeki instance üzerine, veri tabanının transaction log backup’unu alarak aktarılmasını sağlayan bir yedekleme metodudur. Burada bulunan Monitör Database server olmazsa olmaz değildir. Sizin belirlediğiniz mimariye göre olabilir veya olmayabilir.
Yukarıda yapılan işlemleri maddeler halinde özetleyecek olursak;
1-Transaction Log Backup’ı alma işlemi sağlayan bir job oluşturulur. Bu job primary sunucu üzerinde oluşturulur.
2-Primary sunucu üzerinden alınan Transaction Log backup’ı secondary instance veya sunucuya kopyalayan bir job oluşturulur.
3-Secondery sunucu üzerinde, Secondary sunucuya kopyalanan backup’ı restore etmek için bir job oluşturulur.
4-Bu işlemler sırasında oluşacak olumsuzlukları bildirmek raporlamak için Monitoring Server oluşturulur.
Eski bir teknoloji olmakta olup, lisans maliyetlerinden kısıntı yaparak yedekleme ve yedek sunucu üzerinden read yapılması istenilen durumlarda kullanılabilir. Sql sunucu üzerinde özellikle Allways On gibi bir teknolojinin yanında esamesi okunamaz ancak lisanslama maliyetlerinden dolayı bazı ortamlarda güzel iş başarabilir.
Makalemizdeki kurgulayacağımız ortamımız aşağıdaki gibidir.
Elimizde domaine üye iki adet Windows Server 2019 işletim sistemi kurulu sunucu ve bunların üzerine kurulu olan SQL Server 2017 standart bulunmaktadır. Bu işlemin yapılabilmesi için ortamda Active Directory olma zorunluğu yoktur. Workgroup olarak çalışan ve network katmanında birbirine ulaşım sağlayabilen sistemlerde bu mimari kurulabilir.
Log Shipping hakkında genel bilgilendirme ve ortamımız hakkında gerekli bilgileri aktardıktan sonra kurulum adımlarımıza geçebiliriz.
Sunucularımız sanal platform üzerinde hali hazırda çalışır durumda.
Sql server, Management Studio versiyonları aşağıdaki gibi. Bu mimarimiz SQL 2005 versiyonundan bu güne yaşam döngüsünü devam ettirmekte.
Öncelikle veri tabanı özelliklerimize göz atalım. Bu işlem için veri tabanı üzerinde sağ tıklayarak Properties kısmına tıklayalım.
Veritabanı üzerinde Log Shipping özelliğini aktive edebilmek için Full veya Bulk-legged modda olması gerekir. Bu ayarımıza dikkat edelim. Aksi durumda Log Shipping özelliği aktive edilememektedir.
Bu ayarı gözden geçirdikten sonra Transaction Log Shipping kısmına gelelim.
Enable this as a primary database in a log shipping configuration özelliğini aktive edelim.
Bu özelliği aktive ettikten sonra karşımıza gelen ekranda bazı tanımlamalar yapmamız gerekmekte. Veri tabanının yedeğinin alınacağı yolun network ve lokal yolu bizden istenmekte.
Bu nedenle ben Backup ve restore işlemlerinin yapılabilmesi için iki adet paylaşımlı klasör oluşturdum. Bu işlem için sunucuların üzerinde dosya paylaşılması önerilmekte birlikte ortak bir file server üzerinde paylaştırılmış klasör oluşturulması durumunda bu senaryo yine desteklenmekte. Bu nedenle ben klasörlerimi Domain Sunucu üzerinde tanımladım. Tabi önerilen bu değil ancak test ortamında olmamızdan dolayı bu şekilde ilerliyorum.
Klasörlerimiz paylaşıma açılmış durumda.
Test ortamı olduğu için full erişim sağlanmış durumda. Tabi ideal yapıda gerekli olan hesapların klasör üzerinde yetkilendirmesi yapılmalıdır.
Network yolu üzerinden erişim sorunsuz olarak sağlanmakta. Backup alınacak ortam için yolumuzu kopyalayalım.
Yolumuzu bizden istenen ekran üzerine yapıştıralım. Bizden lokal yol istenilen alana yine network yolunu yapıştırdık ama bu sistemin hata vermesine mani çalışmasına engel bir durum değil. Bu ekranda alınan yedeklerin belirli süre sonra silinmesini ve bir alert oluşmasını istiyorsak Delete Files older than ve Alert if bo backup occours within kısmından gerekli ayarlamaları yapabiliriz. Schedule butonu ile alınacak olan yedek için zamanlama yapabiliriz.
Ben test ortamında olduğumuz için sonuçları hızlı alabilmek için günlük olarak ve 5 dakikada bir işlemin tekrarlanmasını istiyorum bu nedenle ayarlarımızı aşağıdaki gibi yapıyorum.
Gerekli ayarlarımız yapıldı. Dilersek alınan yedeğin büyük olmasını engellemek adına sıkıştıtılmış yedek almasını sağlayabiliriz. Bu işlem tamamlandıktan sonra OK butonu ile bu kısımda yapacaklarımızı tamamlayalım.
Primary sunucu ayarlarını tamamladık. Secondary sunucu üzerindeki işlemleri yapmaya başlamak için Add butonuna tıklayalım.
Connect butonuna tıklayarak ikinci SQL sunucumuza bağlantı işlemini başlatalım.
İkinci SQL sunucu ismini ve bağlantı ayarını yaptıktan sonra Connect ile bağlantı sağlayalım.
Sunucumuza bağlantı sağlandı. Bu ekranda Restore ile ilgili seçimlerimizi yapmamız gerekmekte. Yes, generate a full backup of the primary database and restore it into the secondary database (and create the secondary database if it doesn’t exist) seçeneği ile veri tabanının full yedeğini aldıralım. Bu full yedek üzerine log backup’ların alınmasını sağlayabiliriz. Biz bu seçimi yapacağız.
Veri tabanının büyük ve uzak lokasyonlarda olması durumunda ise alınan bir full yedek karşı tarafa taşınarak orada zaman kazanmak için sisteme gösterilebilir. Bu işlem için Yes, restore an existing backup of the primary database intro the secondary database (and create the secondary database if it doesn’t exist) seçimi yapılabilir.
Secondary sunucu üzerine Log Shipping metodu ile veri tabanını taşırken secondary sunucu üzerinde veri tabanının ismini farklı yapabiliriz. Karışıklıkları engellemek için bu iyi bir özellik. Burada veri tabanı ismimizi değiştirelim.
Primary sunucu üzerinde alınan yedeğin kopyalanacağı restore alanının yolunu kopyalayalım. Bu paylaşımlı alana üst kısımda değinmiş ve klasör tanım ve paylaşım işlemini yapmıştık.
Alınan yedeklerin kopyalanacağı alanın yol bilgisini kopyaladıktan sonra Copy Files tabında yer alan Destinations folder for copied files: alanına yapıştıralım. Yine buradaki dosyaların hangi zamanlarda silineceği ayarını yapabiliriz. Yedekleme işleminden sonra kopyalama işleminin zamanını Schedule… butonuna tıklayarak açılan ekrandan belirleyebiliriz.
Gerekli ayarları ortamımızda yer alan mimarimize göre yapabiliriz. Biz test ortamında olduğumuz için bu işlemi her gün 5 dakikada bir sadece saat 06:00-18:00 arasında olacak şekilde ayarlıyorum. İşlemlerimiz bitince bu ekranı OK ile kapatalım.
Bu ekrandaki ayarlarımız tamamlandı. Son adımı yapılandırmak için Restore Transaction Log tabına tıklayalım.
Öncelikle transaction log yedeklerinin ne zaman restore edileceğini belirlemek için bir görev zamanlaması yapalım. Bu işlem için Schedule… butonuna tıklayalım. Buradaki ayarımı ben günlük 15 dakikada bir olacak şekilde yapılandırdım.
Bu işlemden sonra kritik bir seçim yapmamız gerekmekte. İkinci sunucu üzerindeki veri tabanı read modda olacağı için rapor v.s. çekilme durumları olabilir buradaki bağlantıları sonlandırıp, Standby mode seçimi ve Disconenct users in the database when restoring backups yapılarak restore işlemini yapmakta yarar var. İşlemlerin sonrasında OK ile bu ekranı kapatalım.
İşlemler tamamlandı. Biz bir Monitoring Server eklemeyeceğiz, bu işlemi yapıyor olsak yine bu ekrandaki Use a monitör server instance ekranından yapabilirdik. OK butonuna tıklayalım.
Bu adımdan sonra yapılandırmamız ilk seferinde çalışmaya başlıyor. Bundan sonraki çalışma süreleri bizim belirlediğimiz zaman dilimlerinde gerçekleşecek.
Yukarıdaki işlemi özetleyecek olursak, Primary sunucu üzerinde Log Shipping yapılan veri tabanının full yedeği belirlediğimiz paylaşımlı Backup klasörüne alındı. Alınan backup secondary sunucu üzerine restore edildi. Bu işleri yapacak olan ayarlar job olarak sunuculara eklendi.
Durumu incelediğimizde full yedek belirlenen hedefe alınmış durumda.
Belirlenen zaman diliminde transaction log yedekler alınmakta.
Yedeklenen veri tabanı ve log yedekler görev zamanlarına göre Restore sunucu üzerine kopyalanmakta.
Örnek olarak bir işlem yapalım. Primary sunucu üzerinde yer alan veri tabanı içerisinden bir tabloyu siliyorum.
Silme işlemini onaylıyorum.
Tablomuz silindi.
Belirlenen sürelerde primary sunucu üzerinde backup ve secondary sunucu üzerinde restore işlemleri gerçekleşiyor. Secondary sunucu üzerinde de tablonun silindiğini yani primary sunucu ile birebir duruma geldiğini görebiliyoruz.
Transaction backup alınırken bunların zincirlerinin bozulmamasına dikkat etmemiz gerekir. Log Shipping teknolojisinde en kritik noktalardan bir tanesi burası. Zincirin bozulması durumunda secondary sunucu üzerinde işler doğru gitmeyecektir.
Örnek olarak bu işlemlerin olduğu sistemde primary sunucu üzerinde bir full yedek almanız zinciri, full yedeğin üzerine almasını sağlar. Bunu engellemek için full yedek alınırken copy only parametresini kullanmak gerekir gibi.
Burada veri tabanı üzerinde oluşturacağınız işlerin Zinciri bozmasına engel olarak şekilde dizayn edilmesini sağlamanız önemlidir.
Bu makalemizin de sonuna geldik. Umarım yararlı olmuştur. Bir başka makalede görüşmek dileğiyle.