Bu makalede Log Shipping kavramını ele almış olacağız Ortak bir paylaşım klasörüne log backupların atılarak ikinci sunucuda bu loglar restore edilerek sistemin kısa sürelide olsa bir veri kaybından sonra ayağa kalkmasını sağlamaktır. Oluşturacağımız her adımda system arka plan bir job oluşturmaktadır. Veritabanı seviyesinde yapılan bu işlemde recovery model full olması gerekmektedir.
Burada sıkıntı aktif pasif çalışması durumudur. Burada herhangi bir arıza durumunda kullanıcıları veya connection stringleri manuel bir şekilde değiştirmem gerekiyor. Failover mode olmadığı için kullanmak mantıklı değildir. Gerçek sistemde sisteme getirilecek yükü azaltmak için ikinci bir sunucu üzerinde raporlama amaçlı kullanılabilir.
Log shipping kurulumuna başlamadan önce Transaction log dosyalarını tutacağımız bir paylaşım klasörü yapacağız.
Uygulamalı bir şekilde yapmak için ilk başta bir database oluşturuyorum. Daha sonra bu database’de bir tablo oluşturup içerisine bir değer insert edelim. Buradaki amaç log shipping yaptıktan sonra insert edilen değerlerin ikinci sunucudaki database’e kaydedilip kaydedilmediğini görmek.
İnstance altında bulunan Databases > New Database diyiyoruz.
Veritabanımızı oluşturduktan sonra sıra geldi bir tablo oluşturmada içine manuel değerler insert etmede. TARIH adında tablomuzu oluşturduktan sonra içerisine manuel bir değer insert ettik.
Bu işlemleri yaptıktan sonra şimdi ise veritabanı üzerinde log shipping özelliğini aktif etmede.
Veritabanı üzerine sağ tıklanır properties kısmına gelinir.
Gelen ekranda Transaction Log Shipping sekmesine gelinir. İlgili Enable this as a primary database in a log shipping configuration checkbox’ı aktif edilir.
Transaction Log Shipping sekmesini aktif ettikten sonra Transactions log backups bölümünde bulunan Backup Settings.. kısmına tıklanır.
Gelen ekranda Backup job bölümünde Job Name kısmında job’a bir isim verdikten sonra Schedule kısmına tıklayarak backup için gerekli olan zaman konfigürasyonunu yapmam gerekiyor. Default olarak 15 dakika ayarlanmış onun düzenlenmesini yapalım. Bu işlem primary sunucusunda backup alıncak job’ın ne kadar sürede bir çalışacağını belirleyen yapı.
Gelen ekranda kaç dakikada bir Log Backup almak istiyorsak onu seçeriz. 30 sn’de bir transaction log backup alacak şekilde ayarlamaları yaparız.
Alacağımız transaction backup’ı sıkıştırarakmı yoksa varsayılan olarak mı alacağımız seçenek karşımıza çıkıyor.
Db boyutum küçük olsa bile sıkıştırarak alıyorum. Daha sonra backuplarımı alacağım bir paylaşım klasörü oluşturmam gerekiyor. Çünkü primary sunucuda oluşturacağımız klasöre yukarıda tanımladığımız job’ımız backup alacak ikinci sunucuda bu klasörden kendi üzerindeki job ile restore işlemi tabi tutacak.
Bunun için backup diskimin altında ABC diye bir klasör oluşturuyorum ve buna paylaşım yetkisi veriyorum. Çünkü farklı bir sunucunun bu klasöre ulaşması gerekiyor.
S2 sunucusunda(primary olan sunucu) BACKUP diskimin altında ABC diye bir klasör oluşturuyorum.
ABC klasörümün üzerine sağ tıklayıp properties’den Sharing bölümüne geliyorum.
Daha sonra alt kısımda bulunan Advanced Sharing sekmesine tıklanır.
Advanced sharing sekmesine tıkladıktan sonra gelen ekranda Share this folder checkbox’ını aktif ettikten sonra alt kısımda bulunan Permissions kısmına tıklanır.
Gelen ekranda Everyone’a full kontrol yetkisi verilmesi tavsiye edilmez. Sql server’ın yapacağı tüm işlerde database engine’a tanımladığımız sql server servisi sorumludur.
Servisimiz aşağıda gözükmekte.
Bunun için add kısmına tıklayıp active directory üzerinden servisimizi seçiyoruz ve full kontrol yetkisi veriyorum.
Servisi ekledikten sonra Full kontrol yetkisi veriyorum.
Apply dedikten sonra gelen ekranda tekrardan işlemleri onaylıyorum ve paylaşım yolunu kopyalıyorum.
Şimdi oluşturmuş olduğum sharing yolunu kopyalayalım. Şunu belirtmek gerekirse S1 ve S2 sunucusu aynı network içerisinde olduğu için S1(secondary) sunucusu bu paylaşım klasörünü görmüş olacak.
Garanti olması açısından zaten bizim yukarıdaki kısımlarda klasörü okuma yetkisi verdik sadece okuma değil yazma yetkiside verilebilir. Yukarıdaki ekran görüntüsündeki Share kısmına tıklanır.
Gelen ekrana sql servis hesabımız yazılır ve add kısmına tıklanır. Aşağıdaki resimde dikkat edersek default olarak read yetkisine sahip herhangi bir sıkıntı yaşamamak için read write yetkisi verilebilir.
Bu ayarlamalardan sonra Share denilip çıkılır.
Paylaşım yolunu kopyalayıp transaction log shipping kurulum ekranına yapıştırıyorum.(\\S2\abc) Bu yapıştırdığımız uzantı log backup’ı nereye almak istiyorsak o uzantı yazılır.
İkinci seçenekte paylaşım yeri network’de değil de bu makine üzerindeyse yazmamızı istiyor. Yazılmamasında herhangi bir sakınca yoktur. Genellikle paylaşım yolu tercih edilir. Aynı instance altında log shipping yapımızı oluşturacaksanız normal klasör yolu verilebilir.
Yukarıdaki ayarlamaları yaptıktan sonra alt kısımda hangi zamandan önceki dosyaları silmemiz gerektiğini söylüyor.
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.
Default değerlerle bırakıp OK deyip primary makinamda işlemlerimi tamamlıyorum.
Ok ikonuna bastıktan sonra şimdi ise gelen ekranda secondary makina için bu ayarlamaları yapmak var. Bu işlemlerin hepsi primary olan sunucuda yapılıyor.
Yukarıdaki resimde Add ikonuna tıkladıktan sonra aşağıdaki ekran karşımı gelmekte burada connect ikonuna tıklayıp S1 sunucuma bağlantı işlemlerimi yapıyorum. Benim şuan S1 sunucum secondary, S2 sunucusu primary sunucusu..
İşaretlemiş olan 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ğinde primary (ana) veritabanının tam yedeğini alır ve secondary (ikincil) sunucuya geri yükler. Eğer secondary sunucuda ilgili veritabanı yoksa, otomatik olarak oluşturulur.Yeni bir Log Shipping yapılandırması oluştururken bu seçeneği kullanabilirsin.
Yes, restore an existing backup of the primary database into the secondary database (and create the secondary database if it doesn’t exist) ile başlayan kısmı seçersek primary veritabanının daha önce alınmış bir yedeği varsa, onu kullanarak secondary sunucuda aynı veritabanını oluşturur. Bu işlem için bir ağ yolunda (network path) bulunan bir yedek dosyasını (backup file) belirtmek gerekir. Mevcut bir yedeği manuel olarak yükleyerek Log Shipping başlatmak için kullanılır.
No, the secondary database is initilalize kısmını seçerseniz, ikincil veritabanının zaten oluşturulduğunu ve restore işleminin yapılmayacağını belirtir. Yani primary sunucudan bir backup alınmasına veya restore edilmesine gerek yoktur. Eğer zaten bir secondary database oluşturduysan ve sadece Log Shipping işlemlerini başlatmak istiyorsan bu seçeneği kullanabilirsin.
Hangi Seçeneği Kullanmalısın?
Yeni bir Log Shipping yapılandırması yapıyorsan ve secondary veritabanın yoksa: 1. Seçenek (Yes, generate a full backup…)
Zaten bir backup aldıysan ve manuel restore etmek istiyorsan: 2. Seçenek (Yes, restore an existing backup…)
– Secondary veritabanı zaten hazırsa ve sadece Log Shipping’i devam ettirmek istiyorsan: 3. Seçenek (No, the secondary database is initialized)
Daha sonra Copy Files sekmesine geçilir. İkinci sunucuda kopyalar hangi klasör içerisinde dursun oluşturduğumuz secondary(S1) sunucusundaki klasörü yazıyoruz. Bu klasörün paylaşım klasörü olmasına gerek yok. Destination folder for… ile başlayan kısma secondary sunucudaki lokal bir path’i yazmalısınız. Secondary sunucusunda oluşturulan klasörde sql server servis hesaplarının yetkisi olması gerekmektedir. Delete copied files after yazan kısım kopyalanan backup’ın 72 saat sonra silineceğini gösterir.
Bu işlemleri yaptıktan sonra alt tarafta bulunan Copy Job kısmında kopyalama işlemlerinin ne kadar süreyle olacağını belirtiyoruz. Kısacası aşağıdaki copy job ile paylaşım klasöründen log dosyasını alır belirtmiş olduğumuz disk uzantısına kaydetmektedir.
Bu ayarlamaları yaptıktan sonra Restore Transaction Log bölümüne geçilir.
Bu kısım ikinci sunucuda log backuplar restore edilirken veritabanın davranış şeklini belirtir. No recovery mode veritabanını restoring moduna sokar bu da ulaşılmasını engeller. Yani secondary sunucunda kullanıcılar select çekemez. No recovery moda değişmediği müddetçe biz veritabanına ulaşamayız.
Biz burada ikinci seçenek olan Standby mode’u seçiyoruz ne zaman veritabanı restoring moda girerse kullanıcıların bağlantısını keser. Veritabanı ne zaman kopyalamış olduğu log’u üzerine dönerse veritabanı ulaşılamaz olur yoksa erişilebilir haldedir. Standby modunun altında bulunan Disconnect users in the database when restoring backups seçenek ise veritabanına restore yapılmadan önce kullanıcı varsa ilgili kullanıcının bağlantısını koparır.
Delay Restoring Backups At Least: Bir hata veya yanlışlıkla yapılan bir işlem primary veritabanında gerçekleşirse, gecikmeli restore sayesinde bu hatayı fark edip geri alma şansı sağlar. Örneğin, bir kullanıcı yanlışlıkla önemli bir tabloyu sildi. Eğer log restore işlemi gecikmeli yapılandırılmışsa, bu hatayı fark edip primary sunucudaki bir backup veya point-in-time recovery ile düzeltme yapabilirsiniz. Örnek: Delay Restoring Backups At Least = 30 dakika ise, primary sunucuda alınan her Transaction Log yedeği, secondary sunucuda en az 30 dakika bekletildikten sonra restore edilir. Kısacası Log Shipping restore işlemini geciktirerek yanlış işlemlerden kaçınma şansı tanır.
Alert If No restore occurs within: Eğer belirlenen süre içinde primary sunucuda yeni bir log yedeği alınmazsa, log shipping’in çalışmadığını veya bir hata olduğunu gösteren bir uyarı üretir.
Daha sonra ikinci sunucumda bir restore işlemi için aşağıda belirtilen Schedule bölüme girip 1 dakikalık arayla restore edilmesi gerektiğini söylüyor. Bu joblar kendiliğinden oluşuyor biz sadece Schedule tanımlıyoruz.
Schedule bölümüne tıkladıktan sonra 1 dakika bir restore etme schedule’nı tanımlıyorum.
Ok tuşuna basıp secondary sunucusunda ayarlamaları yaptıktan sonra ana ekrana gelip tekrar ok tuşuna basıp işlemi sonlandırıyoruz.
Ok ikonuna bastıktan sonra gelen ana kurulum ekranında da ok tuşuna basıp işlemlerimizi sonlandırıyoruz.
Şunuda belirtmek gerekir aşağıdaki ekranda bulunan Use a monitor server instance kısmı backup almada kopyalamada veya restore işlemlerinde bir problem varsa bize bunun için alert üretiyor. Burada settings kısmında alert için bir alert job oluşturmamız gerekiyor. Açılan moniter server instance bölümünde alertlerimizi izleyeceğimiz bir instance belirtmemiz gerekiyor. Bu instance primary ve secondary sunucusuda olabilir. 3. Farklı bir instance seçmek daha faydalı olacaktır.
Başarılı bir şekilde sonuçlanmış oldu.
S2\TEST sunucum üzerinde belirtilen klasöre full backup aldıktan sonra log backup almaya başlıyor 30 saniyede bir. S1 sunucusuda full backup’ı log backup’ı restore işlemlerine tabi tuttu.
Şimdi S1\TEST sunucum da oluşturmuş olduğum klasöre bakayım restore edeceği belgeleri oluşturduğumuz klasöre alıyor mu. Aşağıdaki bak ve trn uzantıları primary sunucusunda(S1) paylaşım klasöründe alıyor.
S1\TEST sunucusunda backup restore edilmiş ve log backuplar restore ediliyor 1dk aralıklarla
S1\TEST sunucusunda görünüm şekli.
Şimdi ise primary olan S2 sunucusunda bir insert yapalım bakalım ne zaman restore işlemi gerçekleşiyor ve restore tam anlamıyla oluyor mu.
İkinci sunucuda(S1) hala değerlerim gelmedi.
Bir dakika schedule’da belirlediğim süre dolduktan sonra değerlerimin geldiğini görmüş oluyorum.
Yeni değerler insert ettiğimde bu değerlerinde belirli bir gecikmeyle geldiğini görmüş oldum.
Aşağıdaki resimde log shipping aktif edildikten sonra system tarafında oluşturulan joblar görülmektedir. Dikkat edersek paylaşım klasöründe kopyalayıp restore ediyor.
Aşağıdaki resimde S2 sunucusunda sadece backup işlemleri için oluşturulan job’ı görmekteyiz.
Bu joblarlarda sürelerini tekrardan düzenleye biliriz gerekli değişikli ayarlarını yapabiliriz.
Log backup’ın alıp ikinci makinaya restore edene kadar ikinci makinaya F5 tuşuna basarak yeniliyorum stand by kısmını başta seçtiğimiz zaman veritabanı restore anında aşağıdaki gibi ulaşılamaz olur. Restore işlemi gerçekleşene kadar sürmektedir.
Restore tamamlandıktan sonra secondary(S2) sunucum kaldığı yerden devam eder.
Şimdi restore modunu değiştirelim no recovery mode yapalım bakalım ne gibi bir sonuçla karşılaşacağız. Bu işlemleri primary(S2) sunucunda yapılır. Bu işlemi kurulum aşamasında yapmıştık dikkat etmişseniz.
Bunu yaptıktan sonra veritabanı üzerine yeni değerler insert edelim S1 sunucusunda gözlemleyelim.
Yeni değer insert etmeden S1 sunucusundaki ABC veritabanı kendini restoring moduna aldı ve sürekli bu şekilde kalır hiçbir işlem yapılamaz. Ancak primary sunucum ulaşılamaz olduğunda manuel bu şekilde bu restore modundan dönülür.
Tekrar restoring modunu düzelttikten sonra eski halime dönmüş oldum. Son olarak log shipping yapısının mevcut durumunu öğrenmek için instance üzerine sağ tıklanır. Report>Standard Reports bölümünden Transaction Log Shipping Status seçilir.
Not: Always On AG altında bir veritabanı secondary replica’da restore (NORECOVERY veya STANDBY) modunda olmasa bile , Log Shipping ile restore işlemi yapılamaz. Always On’daki secondary replika, zaten primary’dan gelen logları kendi mekanizması ile işlediği için, Log Shipping restore işine müdahale edemez. Log Shipping, transaction log backup alarak logları bir secondary sunucuya kopyalar ve orada restore eder. Always On ise logları doğrudan diğer replikalara aktararak sürekli senkronizasyon sağlar. Eğer bir veritabanı zaten AG altındaysa, transaction log’lar Always On tarafından kullanılmaktadır ve ayrı bir Log Shipping mekanizması ile aynı anda restore edilemez.
Log Shipping’i Always On’daki PRIMARY REPLICA üzerinde değil, bir SECONDARY REPLICA üzerinde yapılandırarak TEST ORTAMINDA yaptıgında secondary sunucuları backup alma işlemi gerçekleşmez.
Alwayson yapsında primary replica üzerinde log shipping özelliği açılıp AG altında olmayan bir sunucuya yapılabilir. Sadece primary replicada database log dosyası nerede oluşturulmuşsa backupların oraya alınması gerekmektedir.
Bu makalede uygulamalı bir şekilde sql server Log Shipping işlemini ele almış oldum.Başka bir makalede görüşmek dileğiyle.
“Allah, rüzgarları gönderendir. Onlar da bulutları hareket ettirir. Biz de bulutları ölü bir toprağa sürer ve onunla ölümünden sonra yer yüzünü diriltiriz. İşte ölümden sonra diriliş de böyledir. “Fâtır-9
