Log shipping sql server 2000’den günümüze kadar süregelen bir teknolojidir. Production (sistemde etkin olarak görev yapan veritabanı) ortamında bulunan veritabanlarından herhangi bir olağan dışı durum sebebiyle, veri kaybolmasını istemiyorsak Log shipping teknolojisini kullanmalıyız. Production ortamındaki veritabanının belirli aralıklarla kopyası alınıp diğer sunucuda tutulur. Jobl’ar vasıtasıyla secondary database, production ortamından beslenmelidir. Böylece veri kaybını en aza indirebiliriz. Olağan dışı durumlarda secondary database’in devreye girmesi sebebiyle high availability özelliği, aynı zamanda dataları da koruduğu için disaster recovery özelliğini kullanmış oluruz. Avantajları olduğu gibi dezavantajları da mevcuttur. Otomatik failover yok yani herhangi bir sistem çökmesi olduğunda, secondary database otomatik olarak product veritabanının yerine geçmez. Admin manuel olarak secondary veritabanını sistemde aktif hale getirmelidir. Schedule’da zaman aralığına bağlı olarak, product veritabanı down olduğunda veri kaybı yaşanabilir. Product veritabanı log shipping yapabilmek için Recovery Model’i ya Full yada Bulk-Logged olmalıdır.  

Şimdi Log Shipping konfigürasyonlarına geçelim.

Resim 1- İlk olarak cihazınızda 2 farklı sql server instance bulunmalıdır. İlk instance (Hayrıc) Product veri tabanımızım bulunduğu sunucu olacak. İkincisi ise (Hayrıc\Alıc) secondary database’ imizin bulunduğu sunucu olmalı.

Resim 2- Hayrıc instance’ında USIS adlı veritabanı için log shipping yapacağız. Sizde aynı yolları izleyebilirsiniz. Öncelikle log shipping yapacağımız veritabanımızın recovery modeli Full yapıyoruz.

Resim 3- Log Shipping yapılacak olan veritabanının özelliklerinden shipping konfigürasyon ayarları enable edilmelidir.

Resim 4- Product veritabanının full backup ve transactional yedeklerin alınacağı ve secondary sunucudan bu dosyalara erişebilmek için, dizinde “backup” klasörü açıp share ettik.

Resim 5- İlk olarak oluşturduğumuz “backup” klasörüne product veritabanının backuplarını almak için job oluşturmalıyız. Daha sonra bu klasörden secondary database’ e restore yapılacaktır. Aldığımız backup ları “backup” klasörüne atmak için yolunu yazıyoruz.

Resim 6- Schedule type “recurring” olarak ayarlanmalıdır. Her 15 dakikada bir backup alınacaktır.

Resim 7- Product veritabanı ve ayarları yapıldıktan sonra, secondary database için Sql sunucusuna bağlanmalıyız. Add butonuna bastıktan sonra gelen ekrandan sunucuyu seçip, login olmalıyız.

Resim 8- Secondary ortamına bağlandıktan sonra, secondary veritabanını product veritabanı üzerinden ayağa kaldırma işlemini yapıyoruz. İkincil veritabanı “rstore” klasörü üzerinden verileri çekecek, o yüzden “rstore” klasörü dizinde yaratılıp share edilmeli yalnız share edilirken özelliği read/write olarak belirlenmeli.

Resim 9- Product veritabanın sakladığı backup ve transactional log dosyaları, secondary veritabanında hangi klasörde sakalanacağı belirtilmelidir. Secondary veritabanı bu klasörden veri çekerek kendini eşitleyecektir.

Resim 10- Bir sonraki adım secondary veritabanının modunun seçilmesidir. “Standby” modda secondary veritabanına read-only olarak erişebiliriz.

Resim 11- Son değişiklikleri de yaptıktan sonra sonuçları ekranımızda görüntüledik.Belirtilen süre aralıklarıyla, ana veritabanımız(product) secondary veritabanını besleyecektir.

Resim 12 ve Resim 13 – Sistemimizin çalışıp çalışmadığını instance’lar sql server agent\job activity monitor kısmından bakabiliriz.

 

iyi çalışmalar….