SQL Server Data Replication (Veri Yineleme) – I

SQL Server’in sürekli kullanılabilirlik için desteklediği işlemlerden biri de replication modelidir. Replication kısaca verileri merkezi konumdan alıp farklı konumlarda yedekleme işlemidir. SQL Database Replication modelinde kullanılan kavramları açıklayıp bu modelin nasıl oluşturulacağını örneklendirelim. Replication yöntemi tüm SQL Server’in tüm sürümlerinde gerçekleştirilebilir. Express sürümü, Merge ve Transactional replication yöntemlerinde sadece subscriber olarak kullanılabilir.
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 verilmiş olur.

Replikasyon Topolojileri (Modelleri)
Replikasyon topolojileri, bu yöntemdeki başrollerin (yayıncı, dağıtıcı, abone) sayısını ve fiziksel konumlarını temsil eder.
Central publisher (Merkezi yayıncı): En çok kullanılan topoloji olup bir sunucu yayıncı ve dağıtıcı diğer sunucu veya sunucular abone/aboneler olarak yapılandırılır.

Central subscriber (Merkezi abone): Tek abone/çoklu yayıncı modeline sahip olup data warehouse sistemlerinde kullanılan bir topolojidir. Birden fazla sunucu/veritabanı verilerini tek bir sunucu/veritabanına replike eder.

Central publisher with remote distributor (Merkezi yayıncı/Uzak dağıtıcı): Bu topolojide < ı>distribution veritabanı publisher dışındaki başka bir sunucuda bulunur. Bu topoloji yoğun replikasyon işlemlerin olduğu sistemlerde Publisher’in iş yükünü azaltmak için tercih edilir.

Publishing subscriber: Çift yönlü bir topoloji olup yayıncı sunucu/veritabanı aynı zamanda başka bir sunucunun abonesi olarak tasarlanır. Bu senaryoda iki sunucu aynı veriyi yayınlar. Bu model zayıf veya maliyetli bağlantıya sahip abonelere yayın yapılacağı kullanışlı olur.

Central distributor (Merkezi dağıtıcı): Birden fazla yayıncının yayınını abonelerine dağıtan tek bir dağıtıcının olduğu topolojidir.

Replikasyon Türleri
SQL Server sisteminde üç temel replikasyon türü bulunmaktadır;
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 :D ynamic 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.

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.

Transactional ve Merge replikasyonların snapshot replikasyondan temel farkı sadece değişiklikleri abonelere yansıtmaları ve veri yerine transaction ifadelerini abonelere taşımalarıdır. Snapshot ve Transactional replikasyonlar tek taraflı oldukları için bu yöntemlerde abonelerin salt okunur olarak düzenlenmesi daha anlamlı olacaktır. Aksi takdirde yayıncı ve üyeler arasında veri bütünlüğü sağlanamayabilir. Bununla birlikte Transactional replication yönteminde “Updatable Subscriptions for Transactional Replication” seçeneği aktif yapılarak üyelerdeki değişiklik de merkeze yansıtılabilir.
Hangi replikasyon türünü seçersek seçelim öncelikle yayıncı ile üyeleri şema/veri düzeyinde senkronize etmek gerekir. Bunun için yayıncının full backup’ı alınıp üyeler restore edilir. Bu işlem veritabanı yöneticisi tarafından manual yapıldığı gibi SQL server tarafından replikasyonun ilk adımı olarak ta yapılabilir.
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.

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.
Bu makalede replikasyonla ilgili terminolojiyi anlatmaya çalıştık. Sonraki makalede SQL 2000 ve 2005 üzerinde replikasyon türlerinin nasıl kurulacağını örneklendireceğiz.
Kaynakça:
< ı>msdn.microsoft.com
www.sbeeh.com
www.databasejournal.com
www.dell.com

SQL Server Data Replication (Veri Yineleme) – I” üzerine 8 düşünce

  1. Ferit Uludağ

    Ahmet bey, biz sql tabanli bir muhasebe programı kullanıyoruz. 5 senelik veriler programda kayıtlı ve yedekleme yaptığımızda 650 mb civarı bir veri kaydediliyor. Dolayısıyla program yavaş islemekte. Bu bahsedilen Replication işlemi ile gecmis 4 senelik verileri inaktif etme ve programı daha hizli kullanabilme şansımız var mıdır ???

    Cevapla
  2. Ahmet Kaymaz Yazar

    Ferit,Replication teknolojisinin amacı veritabanını iyileştirmek, performansını ölçmek değildir. Sadece iki veritabanı sistemi arasında tek/çift yönlü veri akatarımı yapmaktır. Bahsettiğin sayıda verileri SQL Server için çok büyük bir yük değildir. Fakat SQL Server’den ziyade muhasebe veritabanını gözden geçirmek gerekir. Yani veritabanı bakımı yapmak lazım. Ya da bu tür programlar tarafında arşivleme yapmak lazım. Yani eski kayıtları başka bir yere alabilirler.

    Cevapla

Bir cevap yazın

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

Time limit is exhausted. Please reload CAPTCHA.