SQL Server

SQL Server Replikasyon Bölüm-1

Sql_Replication_01

Merhabalar ,
Bu makalemizde SQL serverlar arasında Data Replicationun un nasıl yapıldığını inceliyor olacağız ilk olarak konuyu tam olarak açıklayabilmek adına bazı kavramlardan bahsediyor olacağım ;

Replication Nedir ?

Sunucu-istemci mimarisinden bahsedebileceğimiz yapılarda, sunucu(lar) ve abone(ler) arasında rutin ya da sürekli bir şekilde veritabanı içindeki nesneleri eşitleme imkanı sağlayan bir yöntemdir.
Daha açık bir dille; yayıncı(Publisher) bir veritabanı seçersiniz, yayıncı veritabanında yayınlayacağınız objeleri(Article’ları) belirlersiniz ki bu objeler tablolar,stored procedureler v.s. olabilir; daha sonra yayıncı veritabanındaki bilgilerin aynısını ve daha sonra olabilecek tüm değişiklikleri almak üzere, yayıncı veri tabanına aboneler(subscribers) atarsınız. Dolayısıyla, kaynak veri tabanınızın aynısı, sürekli yenilerek, başka bilgisayarlarda da tutulmuş olur.

Replication Hangi Durumlarda Kullanılır?

Örnek olarak Mağazalar Zinciri olan bir şirketi düşünün ve bütün alt şubelerinin Merkezdeki Master SQL DB den stok durumu, ürün bilgileri …. vs gibi bilgileri sorguladıklarını düşünün böyle bir durumda onlarca yahut yüzlerce şubeden sizin merkezinizdeki SQL Server binlerce sorgu gelecek bu sorgular hem networkünüzü hemde SQL DB serverınızı büyük oranda yoracak ve dar boğaza düşürecektir.
Yahut master SQL DB inizin sürekli güncel kopyasını almanız gerekiyor ise ve bunu otomatize ederek yapmak istiyorsanız SQL serverlar arası Replication a ihtiyaç duyarız.

Replikasyonun Katmanları

Replikasyonda üç tane katman vardır ;

Yayıncı(Puplisher), dağıtıcı(Distributor), abone(Subcriber). Hemen aklınıza, “Bir replikasyon için en az üç bilgisayara mı ihtiyaç var?” sorusu gelebilir. Bunun cevabı “hayır” dır.Çünkü replikasyonda, yayıncı seçtiğiniz bilgisayarı aynı zamanda dağıtıcı yapabiliyorsunuz.

Yapıyı biraz grafiksel olarak aktarmak gerekirse aşağıdaki şemada replication için oluşturulmuş ideal bir topoloji örneği vardır Burada az önce bahsettiğimiz Publisher(Yayıncı) makine Bilgileri Distributor(Dağıtıcı) ya gönderiyor Dağıtıcı makine ise subscriber(Abone)lara dağıtma işini yapıyor aynı senaryo çift yönlü olarak ta çalışabilmektedir. Böylelikle alt lokasyonlarda da sql DB e veri giri yapılıyor ise bu veriler Publisher a kadar ulaşabiliyor.
re01

Replikasyon içerisindeki bilinmesi gereken terimler

Publisher (Yayıncı): Üye veritabanlarına veri gönderen merkezi sunucu ya da veritabanı. Replikasyondaki kaynak verinin bulunduğu yerdir.
Subscriber (Abone): Merkezi veritabanından verileri alan sunucu ya da veritabanı. Abonele varsayılan olarak merkezi veritabanının salt-okunur (read-only) kopyasına sahiptir ancak farklı bir konfigürasyonla abonelerde de değişikliğe izin verilebilir veya yapılan değişiklikler merkezi veritabanına yansıtılabilir.
Distributor (Dağıtıcı): Yayıncı ile abone arasındaki veri akışını yöneten sunucu. Bu amaçla < ı>distribution isimli veritabanına sahiptir. Bu veritabanında veri ve şema bazında yapılmış değişiklikler tutulur. Bir veritabanı sunucusu aynı anda hem publisher hem de distributor rolünde olabilir.
Article (Makale): Yayıncı tarafından yayınlanan içerik. VTYS’de üye sunuculara gönderilecek veritabanı nesneleridir (table, view, stored procedure). Makale koleksiyonu publication (yayın)olarak tanımlanır.
Push ve Pull Subscription (Abonelik gönderme ve çekme): Push subscription’da distributor verileri subscriber veritabanına kopyalar. Bu yöntemde işin yükünü distributor çeker. Pull subscription’da ise subscriber kendisi distributor’dan verileri çeker yani işin yükü abonelere

Replikasyon Türleri

Snapshot Replication:
Static replication olarak ta bilinen Snapshot Replication en basit replikasyon türü olup her defasında kaynak veritanındaki tüm verileri bağlı abonelere toplu olarak yükler. Snapshot replication’da daha önce abonelere hangi verilerin gönderildiğine bakılmaz. Bu işlemi full backup’ın karşı tarafa restore edilmesi gibi düşünebiliriz. Merkezi veritabanından her defasında tüm data article’leri çıkarması ve abonelere taşıması hem zaman hem de kaynaklar açısından maliyetli olabilmektedir. Bu yüzden bu modeli az transaction işlemlerinin yapıldığı VTYS’lerde veya üyelerin sil baştan yapılandırılması gereken durumlarda kurmak daha elverişli olacaktır.

Transactional Replication
Dynamic replication olarak ta bilinen bu yöntem Snapshot Replication’tan farklı olarak incremental modele sahiptir yani sadece son yapılmış replikasyon işleminden bu yana gerçekleşmiş değişiklikleri üye veritabanlarına adım adım yansıtır. Bunu da merkezi veritabanındaki log dosyasını dinleyerek gerçekleştirir. Değişiklikler üyelere gerçek zamanlı gönderilebildiği gibi belli peryotlarda da gönderilebilir. Bu yöntem çok yoğun transaction işlemlerinin yapıldığı sistemlerde tercih edilir.

Peer-to Peer Replication

SQL Server 2008 ile hayatımıza girin bu replikasyon türü aslında erişilebilirlik konusundan çok alternatif bir replikasyon yöntemi olarak tartışılsa da uç uca replikasyonun sağladığı önemli fayda tüm transaction’ların bir uçtan bir uca tüm server’larda uygulanmasıdır.

Network trafiğini kontrol ederek load balancing (yük dengeleme) yapabilen bu yöntemin yüksek performans ve ölçekleme (scalability) sağlayabilmesi yanında bu yapıda kontrol edilmesi gereken önemli konu özellikle identity özelliği taşıyan alanlarda tutarsızlıkların oluşmaması ve transaction’ların sağlıklı işlerliğinin devamı için düzenli kontroller yapılması durumudur.

Merge Replication

Transactional Replication gibi incremental özelliğe sahip olan bu yöntem çift yönlü bir replikasyon sunar yani hem publisher tarafındaki değişikliği subscriber’a yansıtır hem de subscriber tarafındaki değişikliği publisher’a yansıtır. En karmaşık yapıya sahip olan bu yöntemde veri çakışmaları yaşanabilmektedir.

Bu yöntem genellikle birden fazla üyenin bulunduğu topolojilerde bir üyenin yaptığı değişikliği hem merkeze hem de diğer üyelere yansıtılması durumunda veya kullanıcıların online/offline çalışabildiği projelerde (bağlantısız ve mobil uygulamalar) tercih edilir. Merge Replication’dan farklı olarak bir veri üzerindeki tüm değişiklikleri değil sadece son değişikliği karşı tarafa gönderir. Örneğin bir kayıt üzerinde 5 kere düzenleme yapıldıysa Transactional Replication’da bu 5 günceleme de karşı tarafa yansıtılır fakat Merge Replication’da sadece son güncelleme gönderilir.

Replikasyon Agent’leri

Replikasyon modelinde süreç Sql Server Agent servisi ve bunun altında çalışan bağımsız agentler tarafından yönetilir. SQL Agent C:\Program Files\Microsoft SQL Server\90\COM altında bulunan bu agentleri çalıştırarak işlemleri yürütür. Bu agentler şunlardır;
Snapshot Agent (Snapshot.exe): Yedek veritabanını hazırlamak amacıyla kaynak veritabanındaki nesnelerin şemasını ve veri dosyalarını hazırlayıp snapshot klasörüne ekler. Tüm replikasyon yöntemlerinde etkili olup distributor tarafında çalışır.
Distribution Agent (distrib.exe): Snapshot klasörüne erişip şema ve verileri üyelere kopyalarak onları ilklendirir ve distribution veritabanındaki değişiklikleri abonelere aktarır. Aktarım işlemi pull (çekme) yöntemini kullanıyorsa bu agent, distributor üzerinde, push (gönderme) yöntemini kullanıyorsa distributor üzerinde çalışır. Snapshot ve transactional replication’da kullanılır.
Log Reader Agent (Logread.exe): Sadece Transactional replication’da çalışıp publisher veritabanına ait transactional logları okuyup dağıtıcıya (distribution database) aktarır. Bu agent, dağıtıcı tarafında çalışır.
Queue Reader Agent (qrdrsvc.exe): Aboneler tarafında Microsoft Message Queue’da (MMQ) veya SQL Server’in kendisine ait kuyrukta bekleyen değişiklikleri yayıncıya aktarmak için kullanılır. Dağıtıcıda çalışan bu agent Transactional replication’da seçmeli olarak çalışır. Bu agent’in devreye girmesi için “Queued Updating” seçeneğinin aktifleştirilmesi gerekir.
Merge Agent (replmerg.exe): Snapshot ve transactional replication yöntemlerinde abone veritabanının ilklendirilmesi, distribution veritabanındaki değişikliklerin abone veritabanına yansıtılması Distribution Agent tarafında yapılmaktaydı. Distribution Agent, Merge Replication yönteminde devreye girmez. Distribution Agent’in yaptığı bu işi Merge Replication’da Merge Agent üstlenir. Yayıncı ve ona ait aboneler arasında yayın senkronizasyonu sağlayan bu agent, Pull (çekme) yönteminde, subscriber üzerinde, push (gönderme) yönteminde publisher üzerinde çalışır.
Bu agent’lerin hangi replikasyon yönteminde devreye girdikleri aşağıdaki tabloda gösterilmiştir.
re02

Distribution Database
Distribution veritabanı yayıncı ile ona bağılı aboneleri veri ve şema düzeyinde senkronize etmek için kullanılır. Bu amaçla abonelere yansıtılmayı bekleyen transactionları saklar. Transactionlar aboneler tarafından başarılı bir şekilde alınıp restore edilinceye kadar distribution veritabanında saklı tutulur. Distribution veritabanındaki bazı önemli sistem tabloları şunlardır;
MSmerge_history: Abonelerin önceki güncellemeleri hakkındaki bilgiyi içerir.
MSmerge_agents : Merge agent’leri hakkındaki bilgileri içerir.
MSdistribution_agents: Distribution agent’leri hakkında bilgi içerir.
MSdistribution_history : Distribution agent’lerin geçmişteki işlemlerini içerir.
MSlogreader_agents : Yerel dağıtıcıdaki log reader agent’ler hakkında bilgi içerir.
MSlogreader_history : Log reader agent’lerinin geçmişteki işlemlerini içerir.
MSrepl_commands: Replike edilmiş komutları içerir.
MSrepl_errors: Başarısız olmuş replikasyon işlemlerini içerir.
MSrepl_transactions: Replike edilmiş her transaction için tek satır içerir.
MSrepl_version : Tek bir satıra sahip olup mevcut replikasyonun sürümü hakkında bilgi verir.
Makalenin buraya kadar olan kısmında SQL serverda Replikasyona dair Terminoloji yi anlatmaya çalıştım bu kadar ön bilgiden sonra artık SQL Replikasyon işlemine başlayabiliriz.

Serdar Bayram

Bu yazı blog üzerinde Serdar Bayram tarafından hazırlanıp paylaşılmıştır. 2009 yılında açılan blogum kısa zaman içerisinde paylasımları ile dikkat cekip büyük bir izleyici kitlesine sahip olmuştur.

2 Yorum

  1. Merhaba,
    Emeğinize sağlık. Bir sorum olacak. Son paragrafta bahsettiğiniz Distribution Database nasıl oluşturuluyor?

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu