Log Shipping Özelliğini Kullanarak Yüksek Sürekliliğinize Katkıda Bulunun
Bu makalemde sizler SQL Server 2000 den beri hayatımızıda varolan ve her yeni sürümünde kendini yeniliyen bir yüksek süreklilik çözümü olan Log Shippingden bahsedeceğim.
Temel bir bakış açısıyla Log Shipping özelliği SQL Server’ın temel iki özelliği olan Backup/Restore işlemlerinin özelleşmiş hali olarak karşımıza çıkıyor. Log Shipping işleminde olay belirli bir kaynak veritabanından düzenli sıklıkta alınan log backup dosyalarının hedefte bir veritabanı sunucusuna taşınarak düzenli sıklıkta restore edilmesiyle tamamlanıyor ve ikincil sunucularda salt okunur veritabanlarına sahip oluyoruz. Bu süreçte bizler logshipping kurulumunda ve yapılandırılmasında her adımı ayrı olarak zamanlama şansına sahibiz.Bu durum bizlere production ortamımıza eşlenik, istediğimiz sürelerde geriden gelen veritabanları ve ortam lar oluşturma avantajı sağlıyor.
Başka bir önemli özelliği sayesinde log shipping sürecinde oluşan eşlenik veritabanları stand-by özelliğine sahip olabilir, bu usayede oluşturduğunuz stand-by veritabanları bir takım raporlama ihtiyaçlarınız içinde kullanılabiliyor.
Bir başka kurgu olarak log shipping mekanizmasını alınan log yedeklerin doğrulanması içinde kullanılabilir. Log shipping hiç bir zaman eşlenik donanımlara sahip kaynak ve hedef sunucu beklemez ve kendi içindeki süreçleri birbirinden bağımsız çalışır. Buda iş kritik uygulama süreçlerimizi etkilemeden önemli bir bakım ihtiyacımızı düşük maliyetlerle karşılayacaktır..
Log shipping yüksek süreklilik özelliğinin SQL Server 2000 ile geldiğinden bahsetmiştik, o dönemler sadece Enterprise sürümüyle kullanılabilen bir özellikti.SQL Server 2005 le beraber Enterprise editiondan farklı sürümlerede yaygınlaşmaya başladı. SQL Server 2008 R2 sürümüyle beraber Log Shipping yüksek süreklilik özelliği Express edition hariç tüm sürümlerde mevcut.
Birtakım önbilgiler verdikten sonra şimdi kaynak sunucudaki bir veritabanını Log Shipping özelliğini kullanarak hedefte bir veritabanı sunucusuna standby veritabanı olarak eşlenik hale getirelim ve Log Shipping özelliğinin gerçekleştirimindeki detayları inceleyelim.
Örneğimize başlamadan önce örneğimizde varmak istediğimiz noktanın şeklini bir görelim.
Öncelikle örneklerimizi yapabilmemiz için primary veritabanı sunucusunda örnek bir veritabanı tanımlayalım ve Log Shipping işleminin log backup alma gereksiniminden dolayı recovery model özelliğini full olarak düzenleyelim.
CREATE DATABASE LSTEST;
ALTER DATABASE LSTEST SET RECOVERY FULL;
“Enable this as a primary database in a log shipping configuration” seçeneğinin işaretlenmesiyle konfigürasyon adımlarına bu veritabanının primary veritabanı olduğunu kabul ederek başlıyoruz ve primary veritabanının backup ayarlarını yapıyoruz.
Not: Eski backup dosyaların silinmesi işleminin kurumumuz için kurguladığımız backup policylerle paralel olması önemlidir, Aksi taktirde log backup kaybı ihtimali gündeme gelir.
Backup ayarlarımızın bitmesiyle beraber şimdi ikincil sunucularımızın ayarlarına geçebiliriz.
İlgili bölümde add düğmesine basarak ikincil sunucuların konfigürasyon yapılandırmalarına başlayabiliriz.
Bu ekranda karşımıza üç farklı bölüm çıkıyor, bunlardan ilki ikincil sunucularda ilk veritabanı yapılandırması ne şekilde gerçekleşeceğiyle ilgili.
Yeşil ile ifade edilen bölümde sizin verdiğiniz restore seçenekleriyle beraber Management Stdudio primary veritabanımızın full yedeğini alarak ikincil sunucuya belirttiğimiz isimli bir veritabanı restore yapacaktır. Bu restore seçeneklerini incelersek.
Log Shipping sihirbazı bizden yedeğin dönüleceği data ve log dosyalarının lokasyonlarını talep edecektir. Verilen bu lokasyonların ikincil sunucular için olduğunu unutmamak gerekir. Bu verilen dizinler ikincil sunucu üzerinde olmaması durumunda log shipping sürecinde hata oluşacaktır.
Sarı ile ifade edilen bölümde sizin daha önceden aldığınız (Backup zincirine uygun olarak) full backup dosyasının yerini belirterek bu backup dosyasının ikincil sunucuda verdiğimiz restore seçenekleri ile restore edilmesi sağlanır.
Mavi ile ifade edilen bölüm bizlerin daha önceden aldığımız full backup dosyasının ikincil sunucuda bizim tarafımızdan NORECOVERY modda restore edildiğini ifade eder. Bu seçim yapıldığı taktirde ikincil sunucuda ilk veritabanı oturşturma işlemi log shipping yapılandırma süreçlerinde olmayacaktır.
İkinci bölüm olan “Copy Files” bölümünde primary veritabanının alınan log yedeklerinin ikincil sunucuda nereye kopyalanacağını, karşı karafta ne zaman silineceğini ve ne frekansla kopyalanacağını belirleriz. Schedule düğmesine basarak kopyalama frekansınızı kendi istediğimiz gibi düzenleyebiliriz. Ben örneğimiz için bu frekansı backup frekansıyla aynı tutuyorum.
Üçüncü ve son bölümde restore opsiyonlarına karar verebiliyoruz.
İlk kısımda restore edilen veritabanının restore sonrası durumuna karar verebiliyoruz. Burdaki seçim kriterimiz veritabanının restore sonrası erişim ihtiyacımız. Eğer okuma amaçlı bir erişim ihtiyacımız varsa seçmemiz gereken Standby mode dur, No recovery modda bir veritabanı okunamaz. Standby seçeneğindeki bir başka seçenek ise “Disconnect users in the database when restoring backup” seçeneğidir. Bu seçenek özellikle log shipping ortamının raporlama amaçlı kullanıldığı durumlarda önemli bir rol oynar . Bu özelliğin kapalı olması durumunda bir kullanıcı bir rapor alırken log shipping operasyonu rapor alma işleminin bitiminden sonraki bir tarihe ötelenir.
İkinci kısımda alınan backupları nekadar geriden gelerek restore edilmesi gerektiğini belirlediğimiz parametreleri belirleriz. Log shipping mantıksal hatalara karşı önlem almak içinde kurgulanabilen bir özelliktir. Ben örneğimde bu parametre değerini sıfır olarak belirledim, sıfır değeri dönülmemiş tüm log yedeklerinin dönülmesini sağlar.
Son olarak restore işlemi için tanımlanacak jobun frekansını yine bu ekrandan belirleyebiliyoruz. Restore işlemi bu ekranda belirlediğimiz frekanslarda gerçekleşecektir.
Tüm bu parametrelerimizi tanımladıktan sonra artık log shipping sürecini başlatabiliriz.
Sürecin tamamlanmasıyla beraber, ikincil sunucumuzda Standby salt okunur bir veritabanı oluşacaktır.
Bu makalemizde log shipping kavramından ve temel log shipping yapılandırmasından bahsettik, bir sonraki makalemizde log shippingin monitör edilme süreçlerini detaylandırıyor olacağız.
İlişkili Yazılar
-
Ekleyen:
Kadir Evciler Eurobank Tekfen Veritabanı Yöneticisi
-
Ekleyen:
Kadir Evciler Eurobank Tekfen Veritabanı Yöneticisi
-
Ekleyen:
Kadir Evciler Eurobank Tekfen Veritabanı Yöneticisi