MS SQL SERVER LOG SHIPPING

Herkese merhaba,

Bu yazımda MS SQL Server teknolojisi olan LOG SHIPPING mimarisinden ve kurulumundan bahsettim.

Keyifli okumalar dilerim.

İlk önce Log Shipping’in ne olduğunu ve ne işe yaradığını açıklayalım.

Log Shipping Nedir?

• SQL Server 7.0 ile kullanılmaya başlayan, veritabanı bazında yapılabilen bir teknolojidir.
• Primary veritabanının Transaction Log Backup’ları network üzerinde secondary server’a aktarılarak primary ve secondary server’da tutulan dataların senkronize olması sağlanır.
• Bu senkronizasyonda SQL Server Agent’ları kullanılırken ne kadar sürede bir transaction log backup’ların secondary server’a taşınıp restore edileceği ayarlanabilir.

Log Shipping Mimarisi

• Aşağıdaki görselde görüldüğü gibi 3 farklı server veya instance ile Log Shipping mimarisi kurulabilir.

Log Shipping Yapısı

Şimdi Log Shipping mimarisinde kullanılan server’ları tanıyalım.

Primary Server:

• Log Shipping mimarisindeki master server’dır.
• Tüm kullanıcılar işlemlerini bu server üzerinde yaparlar.
• Yapılan tüm işlemler transaction log’lara kaydedilir ve primary server üzerinde çalışan bir job yardımıyla belirlediğimiz sürelerde transaction log backup’ları alınarak secondary server’ın erişebileceği bir lokasyona taşınır.
• Primary server’da log shipping için kullanacağımız veritabanının Recovery Modeli Full veya Bulk Logged olarak seçilmelidir.

Secondary Server:

• Secondary server, üzerinde Log Shipping için konfigüre ettiğimiz veritabanının bir kopyası bulunur.
• Primary server’da olduğu gibi secondary server’da da bizim belirlediğimiz sürede bir job çalışarak primary server üzerindeki veritabanından kopyalanan transaction log backup’larını okuyarak kendi üzerindeki veritabanına restore eder.
• Böylece belirlenen zaman kadar bir gecikmeyle primary server’ın bir kopyasını secondary server üzerinde elde etmiş oluruz.

Monitor Server:

• Monitor server’ın kullanımı isteğe bağlıdır. Yani monitor server olmadan da Log Shipping mimarisi tasarlanabilir.
• Genelde monitor sever’ın primary veya secondary server üzerinde meydana gelebilecek bir failed durumundan etkilenmemesi için farklı bir makine üzerinde kurulması önerilir.
• Monitor server üzerinde çalışan SQL Server job’ları ile primary ve secondary server arasındaki işlemleri izler.
• Örneğin, Primary server üzerinde en son ne zaman transaction log backup’lar alınmış, en son secondary server’a ne zaman transaction log’lar restore edilmiş, bu ikisi arasında ne kadar süre geçmiş gibi detaylı bilgileri monitor server kullanarak elde edebiliriz.

Log Shipping işleyiş mantığını aşağıdaki gibi sıralayabiliriz.

1. Primary sunucu üzerinde Transaction Log Backup’ı alma işlemi sağlayan bir job oluşturulur.
2. Primary sunucu üzerinden alınan Transaction Log Backup’ları secondary sunucuya kopyalayan bir job oluşturulur.
3. Secondary 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 ve raporlamak için Monitor Server oluşturulur.

Log Shipping Kurulum Gereksinimleri

• Transaction log dosyalarını tutacağımız ve network üzerinde paylaştırılmış bir alan olması gerekmektedir.
• Primary ve Secondary server’ları seçerken konfigürasyon olarak birbirine benzer makineler seçilmelidir.
• Monitor Server kurulacaksa fiziksel olarak primary ve secondary server’dan farklı bir makineye kurulması önerilir.
• Log shipping yapılandırmak için Enterprise Edition veya Standart Edition sürümlerinden birine sahip olmamız gerekiyor.
• Log shipping için kullanacağımız veritabanlarının recovery modeli FULL veya Bulk-Logged modda olması gerekir.

Log Shipping kurulumu için gerekli gereksinimler sağlandıktan sonra kurulum adımlarına geçebiliriz.

Log Shipping Kurulumu

• Log Shipping özelliğini aktif edebilmek için, Database’in Recovery modeli Full veya Bulk-Logged modda olması gerekir. Aksi takdirde Log Shipping özelliği aktif edilememektedir.
• Veritabanı Recovery modeli simple iken Log Shipping özelliği aktif edilmeye çalışılırsa aşağıdaki gibi hata alınır.

• Database recovery modeline bakmak ve değiştirmek için veritabanı üzerine sağ tıklayarak “properties” seçeneğine tıklayıp çıkan ekranda “Options” seçeneğini seçerek recovery modele bakabiliriz.

• Yine “properties” ekranından “Transaction Log Shipping” seçeneğine tıklayarak Log Shipping kurulum ekranına geçiyoruz.
• Log Shipping özelliğini aktif edebilmek için “Enable this as a primary database in a log shipping configuration” seçeneğini işaretlememiz gerekiyor.

Not:

Eğer veritabanımız üzerinde daha önceden Log Shipping yapılandırılmışsa bu seçenek seçili olarak gelecektir. Log Shipping mimarisini kaldırmak istersek sadece bu seçeneği kaldırmak yeterli olacaktır.

• Bu yapılandırmayı yapabilmemiz için transaction log backup’ların alınacağı ve restore edileceği klasörlerin paylaşıma açılmış olması gerekmektedir.

• Daha sonra transaction log backup ayarlarını yapabilmek için “Backup Settings” kısmına tıklıyoruz.

• Bu ekranda backup’ların alınması için oluşturduğumuz ve paylaşıma açtığımız klasörün path bilgisini bizden istenen ekran üzerinde belirtiyoruz.
• Delete files older than: Backup alınması için belirttiğimiz klasörde transaction log backup’larının ne kadar saklanacağını saat, dakika, saniye cinsinden burada belirtebiliriz.
• Alert if no backup occurs within: Belirtilen zaman aralığında transaction log backup alınmadığında SQL Server’ın bize uyarı vermesini sağlar.
• 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.

• “Schedule” kısmında transaction log backup’ların ne kadar sıklıkla alınacağını aşağıdaki gibi belirtebiliriz.

• Sonuç olarak, Primary Server üzerinde günlük 5 dakikada bir transaction log backup alacak olan job tanımlaması yapıldı.

Şimdiye kadar yaptığımız işlemler Primary Server için olan kısımdı, şimdi ise Secondary Server Konfigürasyonunu yapalım.

• Secondary Server konfigürasyonu için “Secondary database” kısmındaki “Add” butonuna tıklıyoruz.

• Bu ekranda “Connect” butonuna tıklayarak, Secondary SQL Server ismini ve bağlantı ayarını yaptıktan sonra Secondary Server’ımıza bağlanıyoruz.

• “Initialize secondary Database” kısmında Primary Server’daki veritabanımızın Full yedeğini Secondary Server üzerinde nasıl oluşturulacağını seçiyoruz.

• “Copy Files” kısmında Primary sunucudan alınan transaction log yedeklerin, Secondary sunucuda kopyalanacağı yolu belirtiyoruz.
• “Delete copied files after” seçeneği ile alınan backup dosyaların ne zaman silinmesini istiyorsak buradan ayarlıyoruz.

• “Copy job” kısmındaki “Schedule” seçeneğine tıklayarak Primary Sunucu da alınan yedekleri ne sıklıkla Secondary sunucuya kopyalanacağını belirtiyoruz.

• Alınan yedeklerin her gün 5 dakika da bir Secondary Server’a kopyalacak şekilde ayarladık.

• “Restore Transaction Log” kısmında ise Secondary veritabanına kopyalanan backup’ları restore eden bir job daha otomatik olarak oluşacaktır. Burada Secondary veritabanının modunu seçebiliriz.

No recovery mode: Bu modda transaction log backuplar restore işlemine devam ettiği için veritabanı restoring moddadır ve veritabanına erişim sağlayamayız.

Standby Mode: Bu modda transaction log Restore işlemlerinin bitmediğini fakat bir sonraki transaction log restore işlemine kadar veritabanı read modda oluyor. Böylelikle Secondary veritabanından da rapor çekebilmemizi sağlıyor.

• Monitor Server eklemek istersek “Use a monitor server instance” seçeneğini seçerek gerekli işlemleri yapabiliriz.

Yapılandırma sonucunda gerçekleşecek işlemler aşağıdaki gibidir:

1. Primary Server’da tanımlanan job ile 5 dakikada bir transaction log backup alınıyor.

2. Secondary Server’da tanımlanan job ile 5 dakikada bir alınan transaction log yedeklerini kendi üzerine kopyalıyor.

3. Restore job’ı ise 5 dakikada bir kopyalanan yedekleri sisteme dönüyor.

• Kurulum bitince ilk seferinde çalışmaya başlıyor. Bundan sonraki çalışma süreleri bizim belirlediğimiz zaman dilimlerinde gerçekleşecektir.

• Yapılandırma tamamlandıktan sonra Primary sunucumuzda ilgili veritabanı için backup job’ı tanımlanmış oldu.

• Aynı zamanda Secondary sunucumuzda da alınan yedekleri kopyalayan ve bu yedekleri restore eden job’lar tanımlanmış oldu.

• Yedeklerin alınması için belirttiğimiz BACKUP klasörünü kontrol ettiğimizde belirtilen zamanda yedeklerin alındığını görüyoruz.

• Log shipping durum bilgisine aşağıdaki gibi bakabiliriz.

Böylelikle Log Shipping kurulumunu tamamlamış olduk ve bir yazımın daha sonuna geldik. Bir sonraki yazılarımda görüşmek üzere.

Yazımı incelediğiniz için teşekkürler.

LinkedIn hesabımdan bana ulaşabilirsiniz. HARUN ERDİNÇ