Merhaba,

Bu yazı dizimde sizlere SQL Server 2008 de Log Shipping teknolojisini anlatacağım. SQL Server Log Shipping teknolojisini kısaca anlattıktan sonra Log Shipping kurulumu ve testlerini görsel olarak göstereceğim.

Log Shipping

Log Shipping teknolojisi SQL Server 2000 den belli gelen ve SQL Server 2012 ile devam eden bir teknolojidir. Log Shipping teknolojisi SQL Server da hem High Availability hemde Disaster Recovery çözümü olarak geçerlidir. Bu iki özelliği şu şekilde sağlamaktadır. Ana veritabanımızın transaction log larından belli aralıklarla beslenen bir yedek yada ikincil veritabanı olası bir felaket anında Ana veritabanı olarak hemen hizmet verebilmektedir. Ayrıca datalarımız da korunduğu için aynı zamanda da Disaster Recovery çözümünü de sağlamış oluyor.

Log Shipping in çalışma stratejisini teorik olarak şöyle ifade edebiliriz. Production ortamında bulunan bir veritabanımızın Felaket anında bir kopyasının tutulmasını istiyorsak ve felakete uğrayan database in bir an önce data kaybı olmadan yada minimum data kaybıyla tekrar hizmet vermesini istiyorsak Log Shipping teknolojisini kullanmamız gerekmektedir. Bu teknolojide Production database in belli aralıklarla birebir kopyası farklı bir sunucuda ki instance da tutulur ve bu secondary database dediğimiz database belli aralıklarla sürekli olarak Production veritabanından beslenir. Böylece felaket anında production database ine erişim yoksa eğer direk secondary veritabanımız ana veritabanı olarak kullanıma açılabilir.

Genel itibariyle Log Shipping in avantajları ve dezavantajlarını aşağıdaki gibi sıralayabiliriz.

Avantajlar
——————————–

  1. Hem Disaster Recovery hemde High Availability çözümü sunar.
  2. Maliyet açısından çok ucuz bir teknolojidir. SQL Server 2008 den itibaren express sürümü hariç tüm versiyonlarda bu teknoloji kullanılabilir.
  3. Kurulumu ve bakımı kolay bir teknolojidir.
  4. Bir veritabanı için sınırsız sayıda log ship yapılacak yedek database imkanı sunmaktadır. Buda bir uygulamanın downtime süresini en minimuma indirmek için bir imkandır.
  5. Standby mode da olan Secondary database  hiçbir manuel işlem yapmadan read-only modda reporting imkanı sunmaktadır.
  6. Kullanıcı hatalarına karşı eski transaction log backuplar ile hatadan dönülebilir.

Dezavantajlar
—————————-

  1. Log Shipping de otomatik failover yok bu durumda failover durumu gerçekleştiğinde database admini hemen manuel failover yapmak zorunda.
  2. Manuel Failover durumundan dolayı Downtime olasılığı senkron mirroring e göre daha fazladır.
  3. Belirlenen schedule aralığına bağlı olarak ana veritabanı down olduğu zaman veri kaybı yaşanabilir.

Şimdi örnek bir database üzerinden Log Shipping konfigürasyonu yapıp Log Shipping in gerçeklenmesini görsel olarak aşağıda maddeler halinde göstereceğim. İşlemlere başlamadan önce Log Shipping için gereken ön gereksinimleri aşağıdaki gibi belirleyebiliriz.

  1. Production Veritabanı dediğimiz primary veritabanı log shipping için Recovery Model i ya Full yada Bulk-Logged olmalı.
  2. Production veritabanın bulunduğu server üzerinde Secondary Server ın erişebileceği bir paylaşım alanı bulunmalı. Bu paylaşıma Production ortamından transaction log backup lar gelecek, secondary server ise gelen bu backup ları kendi server ına kopyalayıp restore edecek.
  3. Log Shipping konfigürasyonunu gerçekleştirecek kullanıcının sysadmin olması gerekmektedir.

Log Shipping işlemini gerçekleştireceğimiz SQL Server Instance ları ve statüleri aşağıdaki gibidir.

Primary (Production) Veritabanı: MYTESTINSTANCE

Secondary (Standby) Veritabanı: TEST2008R2

Prerequisite leri belirttikten sonra şimdi Log Shipping e başlıyorum. Bunun için aşağıdaki gibi TestDatabase oluşturup içine TestTable adlı örnek bir tablo oluşturuyorum.

1

Bu database de görebilmeniz açısından TestTable tablosuna aşağıdaki gibi örnek datalar insert ediyorum. Yazı serisinin sonunda log shipping testinde bu datalardan log shipping in gerçekleştiğini ispat edeceğim.

2

Log Shipping e başlamadan önce adımlarını aşağıdaki gibi sıralayabiliriz.

  1. Production veritabanının Full Backup ını al ve Secondary Server üzerindeki instance a bu backup ı NoRecovery Mode da restore et.
  2. Production veritabanından Transaction Log Backup al ve Secondary Server üzerindeki instance a bu backup ı NoRecovery Mode da restore et
  3. Log Shipping Konfigürasyonunu gerçekleştirme.

1. Production Veritabanımız olan TestDatabase adlı veritabanını aşağıdaki gibi full backup ını alıp Standby veritabanına NoRecovery mode da restore ediyorum.

3

6

2.Production veritabanının transaction log backup ını alıp aşağıdaki gibi Standby veritabanına NoRecovery Mode da restore ediyoruz.

4

7

3. Bu adımda Log Shipping Konfigürasyonuna başlıyorum. İşlem adımlarında sırası ile adımların ekran görüntüsü aşağıdaki gibidir.

TestDatabase veritabanına sağ tıklayıp Properties sekmesinden Transaction Log Shipping menüsüne geliyoruz ve aşağıdaki görüntüde ok la gösterildiği gibi Bu database i Log Shipping Konfigürasyonu için Enable ediyoruz.

8

Aşağıdaki gibi Transaction Log Backup job ı için aşağıdaki gibi bir Schedule belirliyoruz. Her gün 1 dakika aralıklarla Backup alınmasını ve 15 dk dan daha eski dosyaların silinmesini aşağıdaki gibi işaretliyorum.

9

10

Primary server üzerinde Secondary Server ın erişebileceği bir Share alanı oluşturup bunu aşağıdaki path lere yazıyorum.

11

Primary Veritabanı üzerinde Transaction Log Backup alacak job için gerekli konfigürasyonları yukarıdaki gibi girip OK butonuna bastım. Şimdi aşağıda Secondary Veritabanı için gerekli konfigürasyonları yapıyorum.

12

13

Secondary Database için gerekli konfigürasyonları aşağıdaki gibi yapıyorum. Initalize Secondary Database sekmesindeki gereksinimleri yukarıda gerçekleştirdim. Şimdi Primary Sunucu üzerindeki Transaction Log Backup ları Secondary Server e taşıyacak ve bunu Burdaki Standby veritabanına Restore edecek Copy ve Restore Joblarını aşağıdaki gibi oluşturuyorum.

14

15

Copy job ı için yukarıda Schedule ile job ın koşma aralığını 3 dk olarak belirttik ve 15 dk dan eski dosyalarında silinmesi işaretledik.  Secondary Server üzerinde bu dosyaların kopyalanacağı path i de aşağıdaki gibi belirttim.

16

Restore Job ını da benzer şekilde aşağıdaki gibi Schedule unu belirtiyoruz.

17

Aşağıdaki adımda Secondary veritabanımızın modunu belirliyoruz. Ben Veritabanımın modunu Standby mode olarak belirledim. Böylece Secondary veritabanı Restore job ının çalışmadığı aralıklarda Read-only mode da olacak ve raporlamaya açık olacaktır.
18

Her iki Copy ve Restore job lar için gerekli Schedule ları ve path leri yukarda girdikten sonra OK butonuna tıklıyoruz.

19

20

Yukarda da görüldüğü gibi herhangi bir sıkıntı meydana gelmediği için Log Shipping Konfigürasyonu başarılı bir şekilde tamamlandı. Kurulum başarılı tamamlandığı için Primary veritabanı altında Backup, Secondary Veritabanında ise Copy ve Restore job ı oluşacaktır. Bunların oluşmuş olduğunu aşağıdaki gibi görebiliriz.

21

22

Log Shipping Konfigürasyonunu tamamladım ve bu yazımın da sonuna geldim. Bir sonraki yazıda Aynı konfigürasyon üzerinden log Shipping in ilgili datalarla ve testlerle gerçekleştiğini göstereceğim.

Şimdilik Esen Kalın…

Mehmet Salih Deveci

Veritabanı Yöneticisi

Reklamlar

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s