SQL Server replication teknolojisi sayesinde bu noktada bize kullanılabilirlik, sürdürülebilirlik sunuyor. Şimdi konuyu detaylandırmadan önce değinmek istediğim bir diğer nokta ise data replication'u SQL Server'in tüm sürümlerinden kullanmak mümkün. Fakat Express sürümü üzerinde küçük bir kısıtlama uygulanmış; bu sürüme sahipseniz birazdan detaylandıracağımız SnapShot modelini kullanamıyorsunuz ve sunucunun publisher olarak kullanıma izin verilmiyor. Bu noktada sadece sunucunun Subscriber olmasına izin verilmekte.
Şimdi kısaca data replication modelindeki sunucu tiplerinden bahsedelim:
1- Publisher: Publisher'ın Türkçe karşılığıda yayıncıdır. Yani bizim kaynak verilerimizin alınıp diğer sunuculara kopyalandığı merkezi sunucumuz diyebiliriz.
2-Subscriber: Subscriber'in Türkçe karşılığı ise üyedir. Aslında isimden de anlaşılacağı üzere Subscriber sunucular publisher'lardan gelen kaynak veriyi alırlar.
3-Distributor: Publisher ile Subscriber arasında veri alış verişini sağlayan ve bu akışı yöneten sunucudur. Değişikliğe uğramış veriler subscriber sunucuya ulaşana kadar bu sunucu üzerinde saklanır. Distributor ayrı bir sunucu olabildiği gibi aynı zamanda da publisher'ın içerisinde tanımlanabilir. Aslında buna karar verirken tamamen sizin sunucu trafiğiniz yada publisher üzerinde gerçekleşen replikasyon işlem yoğunlu ile alakalıdır. İlerleyen aşamalarda bu konuyu detaylandıracağım.
Artcile: Publisher tarafından subsciriber' a yayınlanan her türlü yayın içeriği denilebilir. Bunlar table, view, stored procedure olabilirler.
Bir replication modeli oluştururken modellememiz gereken publisher, subscriber ve distributor sunucularmız, ayrıca agentların hangi tarafta çalışması gerektiği gibi sormamız gereken sorular olacaktır. İşte bu noktada sistemimizi iyi bilmemiz, oluşacak network trafiği ve replikasyon işlem yoğunluna uygun strateji geliştirip, bu doğrultuda aşağıda bahsedilenlerden hangi yapıyı kullanmak bizim için daha uygun olacağına karar vermek gerekir.
Toplam 5 adet replikasyon modeli bulunmaktadır, bunlardan ilki:
Central Publisher Modeli: Bu modelde adından da anlaşılacağı üzere tek bir publisher sunucu vardır ve birden fazla subsriber server' a yayın yapar. Aynı zamanda bu model de unutulmaması gereken bir diğer önemli ayrıntı distributor sunucu, burada ayrı bir sunucuda değil publsiher sunucu içerisinde bulunur. Bu noktada eğer ki yoğun replikasyon işlemleri olacaksa bu model tavsiye edilmemektedir. Eğer sunucu tarafında distributor'u ayrıma imkânınız yoksa en azından Pull Subscription yönetimi kullanarak iş yükünü birazcık daha Subscriber sunucuya yükleyerek Publisher sunucu tarafın işini hafifletmeye çalışabiliriz.
Central Subscriber modeli: Bu model de ise yukarıda bahsettiğmiz central publisher modelin tam tersi bir yapı söz konusu. burada bir adet subscriber sunucu varken birden fazla publisher sunucu bu tek subscriber sunucuya yayın yapar. Genel de bu yapının kullanım alanı Data Warehouse sistemlerinde görülmektedir. Bu yapıda birden fazla publisher olduğu için veri iletiminde distributor'lar yaptığı için iki farklı distributor subscriber ile publisher arasındaki veri iletişimini sağlar ama bunlar ayrı bir sunucu içerisinde değil publisher içerisinde çalışırlar.
Central Publisher with Remote Distributor Modeli: Bu model yoğun işlem ve replikasyonların çalıştığı sistemlerde tercih edilir. Bu tarafta bir adet publisher sunucu, birden fazla subscriber sunucu ve bir adette ayrı bir sunucuda da Distributor vardır. Burada amaç Distributor'u Publisher'dan ayırarak zaten publisher üzerinde yoğun olan işlemler yüzünden bir de veri transferi ile publisher sunucuyu boğmamak amaçlanır.
Publishing Subscriber Modeli: Bu modelde publisher bir sunucu aynı zamanda başka bir sunucunun subscriber görevini üstlenir. Bu modelde iki sunucada aynı veriyi yayınlar. Burada bir adet publisher sunucu bir adet subscriber/publisher sunucu birden fazla da subscriber sunucu bulunur. Distributorlar publisher sunucuların içerisinde yer alırlar.
Central Distributor Modeli: Birden fazla publisher sunucu ve birden fazla da subscriber sunucu vardır. Bu sunucların arasında iletişimi sağlayan publisherdan bağımsız olarak bulunan distributor sunucu vardır.
Şu ana kadar modellerden bahsettik fakat bu verilerin gönderilmesinin iki farklı türü vardır. Bunlardan bir tanesi Push Subscriptiondur. Burada distributor verileri subscriber' a kendisi kopyalar yani agent aslında distributor tarafında çalışır.Bir diğre ise pull subscriptiondur. Burada ise bizim subscriber sunucumuz verileri distributor tarafından kendine çeker. Yani bu işlemde agent subscriber tarafında çalışır. Yukarıda da biraz değinmiştim eğer ki Distributor, publisher sunucu üzerinde çalışıyorsa ve işlem yoğunluğu fazla ise push subscription distributor tarafında çalışacağından sunucumuzu ekstra yoracaktır. Bu noktada pull subscription yönetimi kullanarak agent'ı subscriber tarafında çalıştırırarak publish sunucuyu bir miktar rahatlatmış olacağız.
Tüm bunlar ayarlandıktan sonra sırada karar verilmesi gereken bir diğer nokta ise bizim replication türümüzün ne olacağıdır. Burada tamamen aslında bizim nasıl bir replication stratejesine ihtiyaç duyduğumuz önemlidir. Bu noktada SQL Server bize 3 farklı seçenek sunmaktadır. Bunlar: Snapshot replication, transactional replication ve merge replicationur. Snapshot replication static bir yapıdır. Çalışma şekli, kaynak veritabanındaki tüm verileri alarak subscriber sunucumaza kopyalar ve bunu her defasında yapar. Bu model az transaciton işlemlerin olduğu sistemlerde kullanılabilir.
Transactional replication snapshota göre dinamik bir yapıya sahiptir. İncremental bir yapıdadır. Son yapılan replication işlemlerinden sonraki değişiklikleri subscriber sunucuya gönderir. Bunu yaparken de publisher tarafındaki log dosyasını dinleyerek gerçekleştirir. Burda opsiyonel olarak gerçek zamanlı yada periyodik aralıklarla da replicaiton işleminin uygulanma şeklini ayarlayabiliriz. Bu yönetem yoğun replication işlemlerin olduğu sistemlerde tercih edilmektedir. Çünkü bu yapıda sadece transaction'lar subscriber'a gönderilir.
Merge replication transactional replication gibi incremental bir yapıya sahip olup aynı zamanda çift yönlü replication işlemi sunar. Yani Publisher sunucuda subscriber tarafındaki değişiklikleri dinler. Bu yapı birden fazla subscriber'ın bulunduğu ve yapılan değişiklerin publisher sunucuyla birlikte aynı zamanda diğer üyelerede uygulanması gerektiği durumlarda tercih edilmelidir. Merge Replicationdaki bir diğer ayrıntı, bir data üzerinde birden fazla yapılan değişiklik adım adım subscriber'a yansıtılmaz bunun yerine en son yapılan değişiklikler gönderilir. Bu nokta da transactional replicationdan da farklılaşmaktadır. Çünkü transactional replicationda data üzerinde yapılan bütün değişiklikler adım adım olarak diğer üyelere yansıtılır. Bununla birlikte transactional replication bize "Updatable Subscriptions for transactional replication" adında ekstra bir seçenek sunmakta. Bunun seçilmesi durumunda transactional replicationda da aynı merge replicationda olduğu gibi çift yönlü bir etkileşim sağlanmış olur. Yani üye sunuculardaki değişiklikler publishera da yansıltılmış olacaktır. Eğer Snapshot yada Transactional modelini kullanıyorsanız yani tek taraflı bir etkileşim modeli söz konusu ise SQL Server da subscriber sunucuların default değeri READ ONLY olarak düzenlenmektedir. Bunun sebebi ise Subscriber tarafındaki bir kullanıcının yanlışlık bir veri üzerinde değişklik yapması durumunda publsiher ile subscriber sunucu arasında veri tutarsızlığı oluşturacaktır.
Yukarıdaki hangi replication türünü seçersek seçelim öncelikli yapılması gereken işlemin publisher ile subscriber tarafındaki verilerin senkronize edilmesi gererkir. Bu noktda publisherın full backup'ı alındıktan sonra subscriber sunuculara restore edilmese gerekecektir.
Son olarak replication işlemleri tarafında çalışan agentlardan size bahsetmek istiyorum. Tüm bu yukarıda anlattığım işlemler SQL Server Agent servisi ve bunun altında çalışan bağımsız agentlar tarafından yönetilir. Snapshot Agent, yedek db yi hazırlamak amacıyla publisher tarafındaki verilere erişip bunları kopyalanmak üzere hazırlar ve bu agent distributor sunucu üzerinde çalışır. Bütün replication türlerinde aktif olarak çalışır.Distribution Agent ise snapshot'ın kopyaladığı verilere erişerek bunları subscriber sunuculara gönderir. Eğer bu aktarım işleminde pull yöntemi kullanılıyorsa agent subscriber sunuclar üzerinde çalışır, eğer push yöntemini kullanılıyorsa agent distributor üzerinde çalışır. Snapshot ve transactional replicationlar da kullanılan agent'tır. Log Reader Agent ise sadece transactional replication da çalışır ve publisher veritabanına ait log dosyasını dinleyerek distributor sunucuya aktarır. Bu agent distributor tarafında çalışmaktadır. Merge Agent da durum biraz daha farklı aslında, distribution agent'ın yaptığı işleri merge replicationda merge agent tarafından yapmakta. Merge replicaiton kullanıldığında veri aktarımı için distribution agent devreye girmez ve bu noktada işleri merge agent gerçekleştirir. Publisher ve subscriber arasında yayın senkronizasyonu sağlayan bu agent Pull yönteminde subscriber üzerinde, push yönteminde publisher üzerinde çalışır.
0 yorum :
Yorum Gönder