SQL Server Log Shipping Kurulumu

Log Shipping gerekli konfigurasyonlar yapıldıktan sonra veritabanının Transaction Log Backup’ını alarak başka bir sunucuya aktaran ve aktardığımız sunucuda read yapabilmeye olanak sağlayan basit bir teknolojidir. Her adım için arka planda bir job tanımlar.

• Transaction Log Backup’ı alan bir job(primary instance’da oluşur),
• Alınan log backup’ı secondary sunucuya kopyalayan bir job(secondary instance’da oluşur),
• Secondary sunucuda kopyalanan backup’ı restore eden bir job(secondary instance’da oluşur),
• Herhangi bir job’ta sorun ya da gecikme olduğunda alert üreten bir job(monitor server instance’da oluşur. Yazının devamında monitor server instance’a değineceğim.)

Yukardaki jobların her birinin bir schedule’ı var. Yani 5 dakikada bir çalışsın,15 dakikada bir çalışsın gibi. Bu süreye bağlı olarak secondary veritabanının ne kadar geriden geleceğini bulabilirsiniz.

Veritabanı seviyesinde yapılır. Veritabanının Recovery Model’inin Full olması gerekir.

HA(High Availability) seçeneklerinden biri olarak karşımıza çıksa da primary ve secondary sunucu arasında her zaman bir süre farkı olacak. Otomatik fail over modu’da olmadığı için HA için kullanmak çok da mantıklı değil. Ama raporlama amaçlı veritabanı bazında Log Shipping yapabilirsiniz.

2 test sunucusu üzerinde bir örnek yaparak konuyu netleştirelim.

1.sunucu üzerinde AdventureWorks2014 isimli veritabanını log shipping yöntemi ile 2.sunucu üzerindeki bir instance’a aktaralım.

1.sunucu üzerindeki AdventureWorks2014 veritabanına sağ tıklayarak properties diyoruz. Aşağıdaki gibi Transaction Log Shipping sekmesine gelerek Enable this as a primary database in a log shipping configuration’ı tıklıyoruz.

Ardından Backup Settings’e tıklayarak 1.sunucudan backup alacak job’ın ne kadar sürede bir çalışacağını belirliyoruz. Backup Settings’e tıkladığınızda karşınıza aşağıdaki gibi bir ekran gelecek.

Ya network path ile başlayan kısma bir share ismi vermelisiniz ya da if the backup ile başlayan kısma lokal bir path vermelisiniz. Paylaşım verirseniz paylaşım üzerinde, lokal path verirseniz lokal path üzerinde primary instance’ın SQL Server servis hesabının ve SQL Server Agent servis read ve write, Secondary instance’ın SQL Server Agent hesabının read yetkisinin olması gerekiyor. Secondary instance’a da yetki vermemiz gerektiğinden ben paylaşım üzerinden gidiyorum.

Delete files older than kısmından kaç saat sonra eski backup’ların silineceğini,

Alert if no backup occurs within kısmından da backup alınmamışsa kaç saat sonra alert üreteğini ayarlayabilirsiniz.

Backup job’ın altından Schedule’a tıklayarak aşağıdaki gibi 15 dakikada bir backup alacak şekilde set ediyoruz. Siz isterseniz bu süreyi uzatabilir ya da kısaltabilirsiniz.

Backup için schedule’ı ayarladıktan sonra aşağıdaki ekrandan Secondary databases kısmından Add diyoruz.

Karşımıza gelen ekranda Connect diyerek Secondary veritabanının nereye kopyalanacağını seçiyoruz.  Veritabanı kısmındanda gerekli seçimi aşağıdaki gibi yapıyoruz.

Initilalize Secondary Database sekmesinde;

Do you want the Management Studio to restore… ile başlayan kısımda,

Yes, generate a full backup… ile başlayan kısmı seçersek 1.sunucudan backup alıp ikinci sunucuya restore eder.

Yes, restore an existing backup… ile başlayan kısmı seçersek backup alma işlemini yapmaz ama mevcut backup’ımızı alıp secondary’ye restore eder.

No, the secondary database is initilalize kısmını seçerseniz backup’ı manual olarak secondary sunucuya norecovery mode’da restore etmeniz gerekir.

Biz aşağıdaki gibi ilk seçeneği seçerek Copy Files Sekmesine geçiyoruz.

Copy Files sekmesinde,

Destination folder for… ile başlayan kısma secondary sunucudaki lokal bir path’i yazmalısınız. Daha önce oluşturmuş olduğumuz paylaşıma alınan backup dosyaları burada belirttimiz path’e kopyalanacak. Bu path üzerinde sql server servis hesabının ve sql server agent servis hesabının read ve write yetkisinin olması gerekiyor.

Delete copied files after yazan kısımda ben 72 saat olacak şekilde bırakıyorum. Kopyalan backup’ların 72 saat sonra silineceği anlamına geliyor.

Daha sonra aşağıdaki Copy Job kısmının sağ tarafındaki schedule’a tıklayarak aşağıdaki gibi kopyalama işleminin 15 dakikada bir yapılacağını söylüyorum. Siz bu süreyi uzatıp kısaltabilirsiniz.

Ok’e tıkladıktan sonra bir sonraki sekme olan Restore Transaction Log sekmesine geçiyoruz.

No recovery mode’u seçersek 1.sunucudan aldığı backup’ı 2.sunucuya restore ederken norecovery mode’da restore eder. Yani 2.sunucudan okuma işlemi yapılamaz.

Standby mode’u seçersek 2.sunucudan okuma yapılabilir. Bu mode’u seçersek hemen altında bir seçenek daha çıkar.

Disconnect users in the database when restoring backups: bu seçeneği seçersek 2.sunucuya restore yapılmadan önce veritabanına bağlı bir kullanıcı varsa o kullanıcının bağlantısını koparır ve restore’u gerçekleştirir. Biz aşağıdaki gibi bu seçeneği seçiyoruz.

Yukardaki resmin alt tarafında görünen Restore Job kısmının sağ tarafındaki Schedule’a tıklayarak aşağıdaki gibi kopyalanmış backup’ların secondary sunucuya restore edilmesi için gerekli job’ı schedule ediyoruz. Ben 15 dakikada bir restore yapacak şekilde ayarladım. Siz isterseniz bu süreyide uzatıp kısaltabilirsiniz.

Bu işlemde bittikten sonra secondary database settings’teki ayarlar bitmiş oluyor ve ok’e tıklıyoruz.

Ok’e tıkladıktan sonra Database Properties’e geri dönüyoruz ve aşağıdaki gibi Use a monitor server instance’a tıklıyoruz ve ardından settings diyoruz. Aslında Monitor server’ın ayarlarını yapmadan ne işe yaracağından bahsedeyim. Eğer Log Shipping de bir sıkıntı varsa, yani backup job’ı, copy job’ı ya da restore job’ında bir problem varsa problem olduğu ile ilgili alert üretir.

Settings’e tıkladıktan sonra aşağıdaki gibi bir ekran gelecek. Monitor Server instance’ın yanındaki connect’e tıklayarak Log Shipping ‘de bir sorun olup olmadığını izleyecek instance’ı yani monitor server’ı seçiyoruz. Bu iki instance’ınız dışında başka bir instance’ınız varsa o instance’ı seçmenizde fayda var. Çünkü, 1. instance’ımızı monitor server yaptığımızı düşünelim. 1.instance kapansa ve backup  ya da  copy job’ı çalışmasa alert te üretilemeyecek. Çünkü monitor server olarak ta 1.instance’ı seçtik. Bu yüzden 3.bir instance seçmenizi tavsiye ederim.

Monitor server instance üzerinde Backup, copy ve restore job’ını monitor edecek bir kullanıcı girmemiz gerekiyor.

By impersonating the proxy… ile başlayan kısmı seçersek monitor server instance’ın SQL Server Agent servis hesabını seçmiş oluruz.

Use the following SQL Server Login diyerek SQL Login ve şifre girişi de yapabilirsiniz. Biz ilk seçeneği seçerek monitor server instance’ın sql server agent servisinin bu işi yapmasını tercih ettik.

Monitor işlemini yapacak kullanıcının primary ve secondary instance üzerinde sysadmin yetkisinin olması gerekiyor. Ben yukarda belirttiğim gibi By impersonating the proxy… ile başlayan kısmı seçtiğim için Monitor Server Instance’ın SQL Server Agent servis hesabını, Primary ve Secondary instance üzerinde sysadmin yaptım.

Bütün işlemleri tamamlayıp ok’e tıkladığımızda aşağıdaki gibi bir ekran gelmesi gerekir.

1.sunucudaki backup job’ını manual olarak çalıştırıyorum. Bu job tamamlandıktan sonra 2.sunucudaki copy job’ını manual olarak çalıştırıyorum. Bu job’da bittikten sonra 2.sunucudaki restore job’ını çalışıtırıyorum. Konfigurasyon doğru yapıldıysa bu 3 job’ta çalışacaktır. Bu şekilde konfigurasyonu doğru yaptığımı test etmiş oluyorum.

Log Shipping’in mevcut durumunu görmek için 2.instance üzerine sağ tıklayarak aşaıdaki gibi Connect->Reports->Standart Reports-> Transaction Log Shipping Status diyebilirsiniz.