Log Shipping Genel Bakış

Bu yazımda sizlere Log Shipping'in mimarisi, çalışma prensipleri hakkında genel bilgilerden bahsetmek istiyorum. Aslında Sql server 7.0' dan itibaren sunulmuş ve high availability

seçeneklerinden en eskisi diyebiliriz. Hatta yakında Microsoft'un bu hizmeti kaldırmayı planladığı söylenmektedir. Ama benim önemsediğim bir konu çünkü özellikle yeni çıkan always on gibi yeni teknolojilerde yaşanan gelişmeleri daha iyi anlamak adına Log Shipping, Mirroring gibi daha eski high availability yöntemlerini bilmek hem bunlara nazaran çok daha karmaşık bir mimari yapıya sahip olan always on'u anlamayı kolaylaştıracak hem de hangi aşamalardan geçerek ne gibi gelişmelerin yaşandığını daha rahat anlaşılacağını düşünüyorum.

Resim1.1

Resim 1.1 görüldüğü gibi, Primary, Secondary ve Monitor Database olmak üzere elimizde toplam 3 farklı veritabanı bulunmakta.

Primary Database:

                Primary Database Log Shipping mimari içerisindeki birincil ve kullanıcıların üzerinde işlemler yaptığı veritabanımızıdır. Bu veritabanında yapılan işlemler transaction log'lara kaydedilir. Primary Database üzerinde tanımlanan job'lar vasıtasıyla belirlenen periyotlarla veritabanının log backup'ları secondary veritabanının erişme yetkisi sağlanan bir lokasyona kayıt edilir. (Bu noktada ilgili klasöre erişim yetkisi verilmelidir.) Bir diğer unutulmaması gereken detay ise transaction log backup'lar ile çalışmalar yaptığımız için ilgili veri tabanının recovery modeli Bulk logged yada full recovery olarak seçilmelidir.

Secondary Database:

                Secondary server, primary database transaction log backupların ulaştığı yerdir. Aslında gerçekleşen şey primary database'in veri düzeyinde senkronize olması sağlanmaktadır. Ama bu noktada belirtilmesi gereken bir diğer önemli nokta ise Log shipping'in senkronize(eş zamanlı) değil asenkron çalıştığı unutulmamalıdır. Secondary serverda da aynı primary database de olduğu gibi bir job tanımlanır. Belirlenen periyotlarla primary database'in log backup'ları kayıt ettiği lokasyona ulaşılıp bu backup'ları okuyarak secondary database'e restore eder.

Monitor Database:

                Monitor database log shipping yapısında olmassa olmaz bir yapı değildir. Aslında tamamen sizin çalışma stratejinize ve verilerinizin ne kadar kritik düzeyde olduğu ile alakalıdır. Genelde tavsiye edilen ise monitor server'ın kullanılmasıdır.  Monitor server primary database ve secondary server arasındaki ilişkiyi sürekli olarak izler. Primary database en son ne zaman transaction back up aldığı yada secondery server üzerinde en son ne zaman backup'ların restore edildiği izlenir. Bu noktada siz monitor database'i eğer primary database içerisinde tanımlarsanız bir fail olma durumu söz konusu olursa monitor server de devre dışı kalacağı için anlamsız bir planlama yapılmış olur bu noktada monitor database farklı bir makinede konumlandırmak fail durumlarında monitor database'in çalışmasını ve bize bildirim göndermesine engel teşkil edecek bir durumu bertaraf etmiş olacağız. Bu fiziksel mimariyi oluştururken başta dikkatli olmak gerekmektedir. Çünkü bir monitör server yapılandırıldıktan sonra log Shipping kaldırılamdan bir daha farklı bir yerde yapılandırılmasına izin verilmez başta iyi düşünülüp değerlendirildikten sonra monitor server konfigre edilmesinde fayda vardır.

Log Shipping Genel Bakış:

                İlk adım olarak log shipping modeline dahil edilecek primary database ve secondary server'lar tanımlanırlar. Yanlız şunu belirtmekte fayda var illa ki fiziksel ortamda iki farklı sunucu olmasına gerek yoktur. Aynı sunucu üzerinde farklı veritabanları arasında da log shipping özelliğini kullanabilirisiniz. Ayrıca riskleri delege etmek içinde birden fazla secondary  server da kullanılabilir. Ayrıca Log shipping işlemini yaptığımız windows kullanıcısının tüm suncularda system admin yetkilerine sahip olması gerektiğini unutmamak gerekir.  Primary ve secondary olmak üzere iki dosya paylaşmının yapılmış olması gerekmektedir. İlk olarak Primary database kaynak veritabanının transaction log'larının tutlacağı bir klasör ardından da secondary sunucu tarafından bu log'ların taşınacağı ve restore edileceği bir klasör oluşturulur. Burada dikkat edilmesi gereken bir diğer husus ise her iki sunucudaki SQL Agent'in kullandığı Windows kullanıcısının bu klasörler üzerinde yetki sahibi olması gerekmektedir.

                Log Shipping eski bir yöntem olsa bile hala kullanıldığını unutmamak gerekir. Bu sayede Log shipping bize hem disaster recovery hemde high availability çözümü sunar. Maliyet açısından da oldukça ucuz ve kullanımı ve oluşturulması kolay bir teknolojidir. Express sürümü haricinde tüm versiyonlarda kullanılabilir durumdadır. Aynı zamanda ciddi bakım gerektiren bir yapı değildir. Bir database için sınırsız sayıda log ship yapabileceğiniz yedek database imkânı sunmaktadır. StandBy mode da olan secondary database hiçbir manuel işlem yapmadan read-only modda reporting imkanındanda faydalanabilirsiniz. Ayrıca kullanıcı hataları söz konusu olduğu zaman eski transaction log backup'ları kullanarak hatadan dönülebilir.

                Tüm bunlara karşın dezavantajlarıda bulunmakta. Bunlardan bir taneside log shipping de otomatik failover imkânı bulunmamaktadır. Böle durumlarda manuel olarak failover yapılmak durumunda kalınabilir. Şimdilik log shipping hakkında söyleyecebileceklerim bunlar. Umarım faydalı olmuştur. Bir sonraki yazıda görüşmek üzere hoşçakalın...