Replication (Sürekli Kullanılabilirlik - 3)

SQL Server Replication

Merhaba arkadaşlar,

Bu makalemde, SQL Server Replication teknolojisinin kavramsal olarak yapısını irdeleyeceğiz. Ayrıca, Replication yöntemlerinden de bahsedeceğim.

Sürekli Kullanılabilirlik (High Availability) konusunda şimdiye kadar SQL Server Failover Clustering ve Database Mirroring’ ten bahsetmiştim. Bunların avantaj ve dezavantajlarından, özelliklerinden ve hangi durumlarda kullanılabileceğinden kısaca bahsetmiştim. Replication konusu ile, Sürekli Kullanılabilirlik yazı dizimin üçüncü bölümünü tamamlamış olacağım. Dördüncü bölüm ise Log Shipping konusunda olacak ve böylelikle Sürekli Kullanılabilirlik konusunu tamamlamış olacağız. En sonunda, bu teknolojilerin birlikte nasıl kullanılabileceklerinden ve genel olarak duruma göre birbirlerine karşı üstünlüklerinden ve dezavantajlarından bahsedeceğim. Ayrıca, Log Shipping konusunun sonunda değişik senarolar da kurgulayacağım. Böylece, hangi teknolojinin nerede kullanılabileceği daha anlaşılır bir hale gelecek umarım.

Makalemde yer yer terimlerin Türkçe ve İngilizcelerini karışık şekilde kullanacağım. Böylece bu terimlerin daha iyi öğrenilebileceği kanısındayım. İki dildeki terimlere aşina olmanızı uygun görmemin nedeni, yazılımların ingilizce olması ve bunların anlaşılabilmesinin de türkçe olarak daha kolay olabilmesi. Umarım işe yarar.


KONU BAŞLIKLARI:

- Replication ve Elemanları
- Publisher, Distributor ve Subscriber
- Replication Teknolojisinde Kullanılan Agent’ lar
- Replication Yöntemleri


REPLICATION YÖNTEMLERİ ve ELEMANLARI

Replication’ ın temel olarak üç yöntemi var, bunlar:

- Snapshot Replication
- Transactional Replication
- Merge Replication’ dır.

Her yöntem, ayrı ayrı seçenekler sunar. İhtiyacımıza göre hangisini kullanabileceğimizi öğrenmek için bu konularda, kendi başlıklarında söz edeceğim.

Fakat daha önce, Replication yapısını oluşturan öğelerden bahsetmek istiyorum. Replication yapısını genel olarak “Yayımevinin yayınladığı makalelere üye olan ve bu yayınları dağıtıcı sayesinde alan aboneler” şeklinde düşünebilirsiniz.

Publisher (Yayıncı) : Yayınlanacak olan makaleleri (Article), yayın (Publication) şeklinde yayınlanmak üzere üzerinde barındırır.

Distributor (Dağıtıcı) : “Publisher” daki “Article” ları, “Subscriber” lara ulaştırır.

Subscriber(Abone) : “Publisher” ın yayınladığı “Article” lara abone olarak, “Distributor” vasıtasıyla yayınları alır.

Publication (Yayın) : Bunu bir gazete gibi varsayın, “Article” lar da bu gazetenin makaleleri.

Article (Makale) : Table, Stored Procedure, View gibi nesneleri makalelere örnek olarak verebiliriz. Yukarıdaki örnekte de söylediğim gibi, Publication’ lar, makalelerden oluşur. Bir tane bile makaleniz olsa, bu, Publication şeklinde Publisher tarafından yayınlanır.

Burada anlattıklarımı, bir de görsel olarak aşağıdaki Şekil-1’ de anlatmanın daha yararlı olacağını düşünüyorum.

Şekil-1

Yukarıdaki Şekil-1’ de gördüğünüz gibi, “Publication_1” isimli bir yayınımız var ve bu yayın 4 makaleden (Article) oluşuyor. Bu Yayını (Publication) ise, Yayıncı (Publisher) yayımlıyor. Dağıtıcı (Distributor), yayını yayıncıdan alıp, ya iterek (Push) ya da abonelerin kendisinden yayını çekerek (Pull) yayınlama işlemini gerçekleştiriyor.

Bu arada, biliyorum bazen çok sıkıcı olabiliyorum. Aynı terimleri defalarca yazıyorum, ama maksadım bu terimlerin kafanızda daha belirgin şekilde yer etmesidir.


REPLICATION TEKNOLOJISINDE KULLANILAN AGENT’ lar

Yukarıda bahsetmiş olduğum yayınlama, itme, çekme gibi işler, Agent’ lar vasıtasıyla yapılıyor. Replication yapısında beş adet Agent bulunmaktadır. Her Agent aslında SQL Server’ dan bağımsız olarak uygulama şeklinde çalışırlar. Yani her Agent aslında bir uygulama (exe) dosyasıdır. Biraz da bu Agent’ lardan başlıklar halinde bahsedelim. O zaman inanıyorum ki işlevleri ve yapıları daha iyi anlaşılacaktır.

Snapshot Agent (snapshot.exe) : Snapshot Agent, Replication’ ın tüm yöntemlerinde kullanılan bir Agent’ tır. Tabloların ve diğer nesnelerin Şema (Schema) ve veri dosyalarını hazırlar. Snapshot dosyalarını depolar ve Dağıtım (Distribution) veritabanına, eşleşmeler (senkronizasyon) hakkındaki bilgileri kaydeder. Snapshot Agent, Dağıtıcı (Distributor) ‘nın üstünde çalışır. Yani Dağıtıcı görevi hangi SQL Server sunucusundaysa, Snapshot Agent da orada çalışır.

Log Reader Agent (logread.exe) : Log Reader Agent, sadece Transactional Replication yönteminde kulanılır. Yayıncının (Publisher) yayınladığı veritabanının Transaction Log’ unda bulunan ve Replication işlemi için işaretlenen kayıtları, Dağıtıcı (Distributor) görevini yapan SQL Server’ daki Dağıtım (Distribution) veritabanına taşır. Transactional Replication kullanılarak yayınlanan her veritabanının, Dağıtıcı’ da çalışan ve Yayıncı’ ya bağlanıp verileri alan Log Reader Agent’ ı vardır.

Distribution Agent (distrib.exe): Distribution Agent, Snapshot Replication ve Transactional Replication ile birlikte kullanılır. Başlangıç bilgilerini Abone’ ye (Subscriber) uygular; ayrıca Dağıtım (Distribution) veritabanında bulunan işlemleri de abonelere aktarır. Eğer Replication veri aktarma şekli olarak çekme (Pull) şekli kullanılırsa, Distribution Agent, Abone’ lik yapan SQL Server sunucusunda çalışır; Eğer itme (Push) kullanılırsa, o zaman da Dağıtıcı görevini üstlenen SQL Server’ da çalışır.

Merge Agent (replmerg.exe): Merge Agent, sadece Merge Replication yönteminde kullanılan bir Agent’ tır. Distribution Agent’ ın Snapshot Replication ve Transactional Replication’ da yaptığı görevi yapar. Başlangıç bilgilerini Abone’ ye uygular ve Dağıtım veritabanında bulunan işlemleri de abonelere aktarır. Her Merge Replication abonesinin, Yayıncıya ve Aboneye bağlayıp verileri güncelleyen kendi Merge Agent’ ları vardır. Gene Distribution Agent’ ta olduğu gibi veri aktarma yolu olarak Çekme yöntemi kullanılırsa Merge Agent Abone’ de çalışır, eğer İtme yöntemi kullanılırsa da Dağıtıcı’ da çalışır. Merge Agent, varsayılan olarak, değişiklikleri Abone’ den Yayıncıya gönderir ve Yayıncı’ daki veritabanında yapılan değişiklikleri de Abone’ nin veritabanına yansıtır.

Queue Reader Agent (qrdrsvc.exe): Queued Updating seçeneği ile birlikte Transactional Replication’ da kullanılır. Bu Agent, Dağıtıcı’ da çalışır ve Abone’ de yapılan değişiklikleri Yayıncıya aktarır. Distribution Agent ve Merge Agent’ ın aksine, sadece bir Queue Reader Agent örneği vardır.


PUBLISHER, DISTRIBUTOR ve SUBSCRIBER

SQL Server Replication teknolojisini SQL Server’ ın tüm sürümlerinde kullanabilirsiniz. Fakat kullandığınız sürüme göre, bazı kısıtlamalar vardır. Genel olarak aşağıdaki tabloda bu kısıtlamaları bulabilirsiniz.




SQL Server sürümleri arasındaki farkları daha ayrıntılı görmek için şu adresi ziyaret edebilirsiniz:
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx

Duruma göre, Replication kurulumlarında Publisher ve Distributor bir SQL Server sunucusu üzerinde konuşlandırılabilir. Bu, sisteminizdeki yük miktarına bağlı olarak değişir. Eğer sisteminizdeki yük fazla değilse ve SQL Server sunucunuz hem Publisher hem de Distributor görevlerinin yükünü kaldırabilecekse, o zaman Replication topolojinizi bu yönde şekillendirebilirsiniz. Yani Yayını, Yayıncı yayınlar ve dağıtır. Yalnız bu, Dağıtıcı’ nın aradan kalktığı anlamına gelmemektedir. Sadece Yayıncı ve Dağıtıcı’ nın aynı SQL Server üzerinde konuşlandırılacağı anlamına gelir. Sistem, gene aynı şekilde işler. Bu şekilde, merkezde bir SQL Server sunucusu kullanmış olursunuz. Bu da hem donanım, hem de lisans tasarrufu sağlar. Fakat yükün fazla olduğu ortamlarda, Publisher ve Distributor görevlerini ayrı ayrı SQL Server sunucularında gerçekleştirmek kaçınılmazdır.

Bu arada, veri aktarma yöntemi olarak İtme (Push) ve Çekme (Pull) yöntemlerine de bu noktada tekrar değinmek istiyorum. Neden ve neye göre İtme ve Çekme yöntemlerini kullanırız? Nedeni şu, Eğer dağıtım işiyle ilgili Agent’ ın (Yukarıda da bahsettik: Distribution veya Merge Agent) yükünü Distributor’ a yüklemek istiyorsak, Push kullanıyorduk; yani veri Distributor vasıtasıyla Publisher’ dan alınıyor ve Subscriber’ lara doğru itilmek suretiyle gönderiliyoruz. Eğer Distributor görevini ifa eden SQL Server’ daki bu yükü azaltmak istersek, o zaman Pull yöntemini kullanarak bahsini ettiğimiz Ditribution ve Merge Agent’ ın Subcriber’ lar üzerinde çalışmasını sağlıyoruz. Böylece yük sadece bir noktada toplanmamış oluyor, yükü abonelere dağıtıyoruz. Fakat Distributor bu görevi rahatlıkla ifa ediyor ise ve kısa ve orta vadede de geniş çaplı bir büyüme beklenmiyorsa, o zaman bu Agent’ lar Distributor üzerinde çalıştırılabilir; böylece Distribution ve Merge Agent’ larının yükleri güçsüz Abone cihazlarına yüklenmemiş olur.


REPLICATION YÖNTEMLERİ

Bu başlık altında, hangi Replication yönteminin ne işe yaradığını, ne amaçla kullanılabileceğini ve belli başlı özelliklerini anlatacağım.


Snapshot Replication:
Snapshot Replication yönteminde, kaynaktaki veriler olduğu gibi hedefe aktarılır. Kaynak veritabanında yapılan değişiklikler takip edilmez. Yani Snapshot Replication’ da, yapılan değişikliklere göre bir aktarma söz konusu değildir. Snapshot Replication, aşağıdaki durumlar söz konusu olduğunda kullanılmalıdır:

- Veri, nadir olarak değişiyorsa;

- Replication ile aktarılan verilerin güncelliğinin, Publisher’ daki verilere
nazaran eski olması kabul edilebiliyorsa;

- Replication için küçük miktardaki veriler kullanılıyorsa;

- Eğer kısa bir süre içerisinde, çok fazla veri değişikliği
gerçekleştiriliyorsa.

Bu Replication yönteminin kullanılabileceği bir örnek vermek istiyorum. Meselâ bir ürün listeniz var. Ürünleriniz senede bir veya iki kez güncelleniyor ve güncellendiklerinde de ürün listesinin %70’ i veya daha fazlası değişiyor. İşte bu durumda, Snapshot Replication kullanılabilir. Çünkü sürekli bir şekilde veri değişikliği yapılmıyor, ayrıca veri değişikliği yapıldığında da veriler büyük miktarda değişiyor.

Bir örnek daha verelim, meselâ küçük boyutlarda bir tablomuz var. Bu tablomuzun her gece saat 12’ de güncellenmesi gerekiyor. Tablo boyutu küçük olduğundan dolayı ve güncellemenin sürekli veya tam zamanlı değil de, geceden geceye yapılması gerektiğinden dolayı Snapshot Replication bu durum için idealdir.

Eğer veri boyutu büyük olsaydı veya güncellemelerin sürekli takip edilmesi gerekseydi, o zaman Snapshot Replication senaryolarımız için uygun olmayacak ve diğer Replication yöntemlerini düşünecektik.


Transactional Replication:
Transactional Replication, Şema ve verilerin tamamının abonelere gönderilmesiyle başlar. Daha sonra, Publisher’ daki veritabanında yapılacak olan değişiklikler nerdeyse gerçek zamanlı olarak abonelere aktarılır. Publisher’ daki veritabanında yapılan değişiklikler, aynen değişiklik sırasına göre Abone’ lerde de uygulanır. Böylece, veri tutarlılığı garanti edilmiş olur. Transactional Replication, daha ziyade sunucular arası kullanılan bir Replication yöntemidir.

Transactional Replication’ ın kullanımı, aşağıdaki durumlarda uygun olacaktır:

- Eğer Publisher’ da gerçekleşen değişikliklerin, gerçekleşir gerçekleşmez
Subscriber’ lara iletilmesini istiyorsanız;

- Eğer toptan değil de, her veri değişikliğinin tek tek Abone’ de uygulanmasını
istiyorsanız (Örn: Publication’ daki bir tabloda bulunan bir veri, Abonelere
ulaştırılmadan önce 5 kere değişmişse, her değişiklik sırasıyla Abone’ de de
uygulanır. Yani sadece 5nci değişiklik yapılmaz.);

- Eğer Publisher’ da çok sık olarak Insert, Update ve Delete işlemleri
uygulanıyorsa;

- Eğer Publisher veya Subscriber, SQL Server değil de Oracle gibi başka bir
uygulama ise.

Transactional Replication varsayılan olarak tek taraflı çalıştığı için, yani Publisher’ dan Subscriber’ a gönderilen veriler sadece Publisher’ da günellenebildiği için ve Subscriber’ daki veritabanında yapılacak değişikliklerin Publisher’ daki veritabanına bir etki yapmayacağı için Subscriber’ daki verilere Salt Okunur olarak davranılmalıdır. Aksi takdirde, Publisher’ daki verilerle Subscriber’ daki veriler birbirlerini tutmayacaktır.

Transactional Replication’ da, Subscriber’ ların da veri güncellemesi yapabileceği bir biçim vardır. Updatable Subscriptions for Transactional Replication yöntemi kullanılarak, Abone’ lerin de güncelleme yapması ve bu güncellemelerin Publisher’ a da yansıtılması sağlanabilir. Fakat bu yöntem daha ziyade arada sırada değişiklik yapılan Abone’ lerde kullanılmalıdır.

Bir de, SQL Server 2005 ile birlikte gelen yeni bir yöntem olan Peer to Peer Replication yöntemi mevcuttur. Bu yöntem ise her noktadaki bilgilerin aynı olması ve her noktanın hem Publisher hem de Subscriber gibi davranmasını istediğinizde kullanılabilir. Aynı satır, her seferinde sadece bir nokta tarafından değiştirilebilir.


Merge Replication:
Merge Replication da, Transactional Replication gibi tipik olarak Yayın nesnelerinin Şema ve verilerin Abone’ lere gönderilmesiyle başlar. Devamında Publisher’ da ve Subscriber’ da yapılacak Şema ve veri değişiklikleri, Trigger’ lar vasıtasıyla takip edilir. Abone, Yayıncı ile yapacağı veri eşleştirmesini, ağa bağlandıktan sonra yapar; son eşleştirmeden bu yana kendinde (yani Abone’ de) ve Yayıncı’ da yapılan tüm değişiklikler iki tarafa da işlenir ve eşleştirme yapılmış olur. Merge Replication, daha ziyade Sunucu ve İstemci’ ler arası kullanılan bir Replication yöntemidir.

Aşağıdaki koşullar gerçekleştiğinde, Merge Replication’ ı kullanmak avantajlıdır:

- Bir çok Abone’ nin aynı veriyi değişik zamanlarda güncellemesi ve
değişiklikleri Yayıncıya ve diğer Abonelere yapması gerektiğinde;

- Abone’ lerin veriyi alması, veri üstünde çevrimdışıyken değişiklik yapması ve
daha sonra Yayıncı ile diğer Abonelere eşletirme yapması gerektiğinde;

- Her abonenin, verinin farklı bir bölümüne ihtiyaç duyduğu zaman;

- Transactional Replication’ ın aksine, Abone’ de 5 değişiklik yapıldığında,
Yayıncı’ ya sadece beşinci değişikliğin ardından çıkan sonuç gönderilir. Yani
değişiklikleri sayı ile gösterirsek, bir tablonun 4. satırında 5 defa
değişiklik yapıldı diyelim, Transactional Replication’ da, Yayıncı’ ya
bu beş değişiklik de tek tek gönderilirdi; ama Merge Replication’ da, Abone’
de 1., 2., 3., 4. değişiklik yapılır; ama Yayıncı’ ya, kaydın sadece 5.
değişiklik yapılmış hali gönderilir.

Merge Replication yöntemi, değişik noktalara değişik zamanlardayken ve çevrimdışıyken değişiklik yapma şansı verdiği için, aynı veri iki noktada ve aynı zamanda değiştirilmiş olabilir. İki nokta da eşleştirme yapmaya kalktığı zaman, çatışma (Conflict) yaşanacaktır. Bunun da Merge Replication’ da farklı çözümleri bulunmaktadır. Bu makaledeki konumuz çatışmaları kapsamıyor, başka bir makalede değinirim bu konuya da.

Merge Replication’ ı, el terminallerinin, dizüstü bilgisayarların vs. kullanıldığı ortamlarda kullanabiliriz. Meselâ büyük bir firmanın pazarlamacılarının sabah şirketten çıktığını, gündüz el terminalleriyle bakkallardan ve restaurantlardan sipariş aldığını ve akşam da şirkete gelip, el terminallerindeki verileri veritabanına aktardıklarını düşünebiliriz...


Selamlar!
Ekrem Önsoy