SQL Server Log Shippin Mimarisi ve Kurulumu

Merhabalar, bugün sizlere SQL Server teknolojilerinden olan “Log Shipping” çalışma mantığını ve kurulumundan bahsedeceğim.

Log Shipping Nedir?

Log shipping veritabanı bazında yapılabilen bir teknolojidir. Ana makinedeki veritabanının Transaction Log Backup’ını alarak başka bir sunucuya aktardığımız, sunucuda read yapabilmeye olanak sağlayan basit bir teknolojidir. Her adım için arka planda otomatik bir job tanımlanır.

Aşağıdaki şekilde görüldüğü gibi 3 farklı Server veya instance ile bu mimari kurulabilir.Monitor Server ihtiyaç doğrultusunda eklenilebilir. Minimum da 2 server üzerinde yapılandırma yapılabilir.

Log Shipping Mimarisi

Log shipping mimarisini aşağıdaki görselle özetleyebiliriz.

Log Shipping İşleyişi

İşleyiş Mantığı özetle aşağıdaki gibidir.

1. Transaction Log dosyalarını tutacağımız bir Paylaşım klasörümüz var buradaki SQL Server Transaction log bilgilerini bu dosyaya alınıyor.
2. Bir diğer SQL Server’ımız da yedek amaçlı kullandığımız bu paylaşım dosyalarından (ana sunucudaki) bu Tansaction log dosyalarını kendi diskine alcak ve bunu kendi üzerine restore edecek.
3. Bir kez FULL Yedek almamız gerekiyor ki diğer tarafa bunu dönelim ve onun üzerinde Transaction Log yedekleri full yedek üzerine işleyebilelim.
4. Full Yedeği Yedek sunucuya deönülür
5. Periyodik olarak ana sunucuda Log Yedek Almak (bunu biz belirlicez 10 dk, 1 saat ne dersek)
6. Periyodik olarak Ana Sunucu Transaction Log yedeklerin secondary (yedek) sunucudaki disk üzerine kopyalanması.
7. Transaction Logların secondary sunucuya restore etme işlemi

Log shipping farklı sürümler arasında yapılabiliyor mu?

Secondart Server instance’imizin sürümü, Primary’nin surumunden yüksek olmasi gerekiyor.

Örneğin,

SQL Server 2005’ten SQL Server 2000’e gonderemeyiz.

Ancak, SQL Server 2005’ten SQL Server 2008’e gonderebiliriz

Log Shipping Yapılandırması

1. Veritabanı üzerinde Log Shipping özelliğini aktive edebilmek için, veritabanının Recovery Modeli Full veya Bulk-logged modda olması gerekir. Bu ayarımıza dikkat edelim. Aksi durumda Log Shipping özelliği aktive edilememektedir.

2. “Enable this as a primary database in a log shipping configuration” seçeneğini işaretleyip Log Shipping özelliğini aktif hale getirelim.

NOT: Eğer veritabanımız üzerinde daha önceden Log Shipping yapılandırılmışsa bu seçenek seçili olarak gelecektir.

Eğer biz Log Shipping mimarisini kaldırmak istiyorsak sadece bu seçeneği kaldırmak yeterli olacaktır.

3. Bu yapılandırmayı yapabilmemiz için log backupların alınacağı ve restore edileceği klsörlerin paylaşıma açılmış olması gerekmektedir.

4. Backup Settings kısmına tıklayalım

5. Yolumuzu bizden istenen ekran üzerinde belirtelim.

Delete files older than: Backup alınması için belirttiğimiz klasörde transaction log backuplarının ne kadar saklanacağı varsayılan olarak 72 saatten daha eski olan transaction log backup dosyaları belirttiğimiz klasörden silinecektir. Tutulmasını istediğimiz zaman dilimini saat,dakika,saniye cinsinden burada belirtebiliriz.

Alert if no backup occurs within: Belirtilen zaman aralığında herhangi bir Transaction Log Backup alınmadığında SQL Server’ın bize uyarı vermesini sağlaması için.

Backup Job Name: Burada schedule kısmında belirttiğimiz sürede veritabanının transaction yedekleri alacak olan otomatik tanımlanan job’ın isim bilgisini görmekteyiz.

Compression: Transaction Log Backup’larımızın ilgili klasöre kopyalanırken sıkıştırılıp sıkıştırılmayacağını belirtebiliriz

6. Ben test ortamında olduğumuz için sonuçları hızlı alabilmek için günlük olarak Scheduler kısmına tıkladıktan sonra, backup job’ının 5 dakikada bir çalışmasını istiyorum bu nedenle ayarlarımızı aşağıdaki gibi yapıyorum.

Frequency: Backup job’ının Günlük, haftalık, aylık nasıl calısmasını istiyorsak o şekilde ayarlıyoruz.

Daily Frequency : Günlük kac saatte bir, kaç dakikada bir çalışmasını istiyorsak o şekilde ayarlıyoruz.

7. Primary Server üzerinde günlük 5 dakikada bir transaction yedek alacak şekilde ayarlamalarımızı tamamladık. Secondary Server üzerindeki işlemleri yapmaya başlamak için, Add butonuna tıklayalım.

8. İkinci SQL Server ismini ve bağlantı ayarını yaptıktan sonra Connect ile Secondary Server’ımızabağlantı sağlayalım.

9. Connect butonuna tıklayarak ikinci SQL Server’a bağlantı işlemini başlatalım.

10. Sunucumuza bağlantı sağlandı. Bu ekranda Restore ile ilgili seçimlerimizi yapmamız gerekmekte

NOT: Secondary Server üzerine Log Shipping metodu ile veri tabanını taşırken Secondary Server ü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.

12. Primary sunucu üzerinde alınan transaction yedeklerinin, secondary sunucuda kopyalanacağı yolu belirtelim. (Farklısunuda olması durumunda klasör paylaşımlı olup IP ve path bilgisiyle yolu belirtmemiz gerekmekte)

Gördüğünüz gibi ikinci sunucumuzda, ana sunucuda alınan yedekleri secondary sunucuya kopyalayan job tanımlanmıs oldu.

13. Ana sunucuda alınan yedeklerin hangi zaman aralıgında ikinci sunucumuza kopyalanmasını istiyorsak Schedule kısmına tıklayıp ayarlayabiliriz.

Ne kadar sıklıkla çalışmasını istiyorsak ayarlayalım.

[Starting at- Ending at ] kısmında işlemlerin ne zaman gerçekleşip, ne zaman durmasını istiyorsak ayarlamasını yapabilmekteyiz

14. Secondary veritabanına kopyalanan yedekleri, restore eden bir job daha otomatik oluşacaktır. Burada ikinci sunucumuzdaki veritabanının modu’unu seçebilmekteyiz.

NOT: Ben test amaçlı olduğundan VERIDATA_DRS şeklinde tanımladım veritabanı ismini, prod ortamlarda aynı şekilde yapılması daha sağlıklı olacaktır

Standby Mode: İkinci sunucu bu seçenepi seçersek veritabanımız read modunda olacaktır. Yani ikinci sunucudan da rapor çekebilmezi sağlayacaktır. “Disconnect users in the database when restoring backups” seçeneğini seçersek restore edilirken buradaki bağlantıların sonlandırılması daha saglıklı çalışmasını sağlayacaktır.

No Recovery Mode: Veritabanı Restoring moddadır ve modu değişmediği müddetçe biz database’e ulaşamayız, kimse erişemez. Eğer ben bu server’ı raporlama amacıyla kullanıyorsam ve bunlarla alakalı rapor çelkerken biraz gecikmeye razı olabilirim ama ana sunucumu bunlarla yormak istemem.

Dolayısıyla Log Shipping yaptığım database’in ayakta kalması gerekiyor olabilir bunun için de Standby moddayız. Fakat Standby modda da şöyle bir şey var insanlar bir taraftan o makineden rapor çekiyor ama benim ayarladığım Schedule da da RESTORE etme işlemi gerçekleşiyor. İkisi aynanda olamayacak bir şey ya RESTORE işlemi GERÇEKLEŞMEYECEK ya da KULLANICILAR RAPOR ÇEKEMEYECEK.

Biz bir Monitoring Server eklemeyeceğiz, bu işlemi yapıyor olsak yine bu ekrandaki Use a monitör server instance ekranından yapabilirdik

Yapılandırma sonucunda olacak işlemler özetle aşağıdaki gibidir:

• 5 dakikada 1 dosya kopyalıyor
• Diğer taraftaki job 5 dakikada bir kopyalanan dosyayı kendi üzerine alıyor
• Restore Job’um da 5 dakikada 1 kendi üzerine aldığı dosyayı sisteme dönüyor.

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

Yapılandırma tamamlandıktan sonra ana sunucumuzda ilgili veritabanı için backup jobı tanımlanmış oldu

Yedek sunucuuzda ana sunucudan alınan yedekleri kopyalayan ve bu yedekleri yedek sunucuya restore eden joblar tanımlanmış oldu.

Bu Job BACKUP klasörünün içersine Backup’ı attı şuanda. Belirlenen zaman diliminde transaction log yedekler alınmakta.

Eğer Log shipping yapılandırmasında tanımlanan jobları o an çalışmasını istiyorsak manuel olarak da jobları aşağıdaki şeilde çalıştırabilmekteyiz.

Log shipping yapılandırmasından sonra başarılı çalışıp çalışmadığını kontrol etmek için Reports → Standard Reports → Transaction Log Shipping Status diyelim

Log Shipping durumuna aşağıdaki gibi bakabilmekteyiz. Ana sunucuda Log shipping yapılandırması yapılan veritabanlarının durum bilgisi aşağıdaki gibidir. Status durumu Good yani sorun olmadıgını görmekteyiz

Ana sunucumuzdaki yedekler secondary sunucuya kopyalandı mı başarılı şekilde restore edildi mi kontrol etmek için aynı şekilde bakabiliriz.

Umarım sizler için faydalı olmuştur 🙂 Log shipping yapılandırması hakkında merak ettiklerinizi, aldıgınız hataları sorabilirsiniz.