fbpx
Anasayfa » SQL 2017 Log Shipping Yapılandırması

Makaleyi Paylaş

SQL Server

SQL 2017 Log Shipping Yapılandırması

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.

Sponsor

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Ö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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Bu ayarı gözden geçirdikten sonra Transaction Log Shipping kısmına gelelim.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Enable this as a primary database in a log shipping configuration özelliğini aktive edelim.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Klasörlerimiz paylaşıma açılmış durumda.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu
ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Network yolu üzerinden erişim sorunsuz olarak sağlanmakta. Backup alınacak ortam için yolumuzu kopyalayalım.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Primary sunucu ayarlarını tamamladık. Secondary sunucu üzerindeki işlemleri yapmaya başlamak için Add butonuna tıklayalım.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Connect butonuna tıklayarak ikinci SQL sunucumuza bağlantı işlemini başlatalım.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

İkinci SQL sunucu ismini ve bağlantı ayarını yaptıktan sonra Connect ile bağlantı sağlayalım.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Bu ekrandaki ayarlarımız tamamlandı. Son adımı yapılandırmak için Restore Transaction Log tabına tıklayalım.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

Ö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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

İş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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

ekran görüntüsü içeren bir resim

Açıklama otomatik olarak oluşturuldu

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.

Makaleyi Paylaş

1 Yorum

  1. Gerçekten harika bir anlatım olmuş teşekkürler Rıza Bey

Cevap bırakın