SQL Server’da Peer-to-Peer (P2P) Transactional Replication, verilerin birden fazla sunucu (node) arasında neredeyse gerçek zamanlı olarak senkronize edildiği, yüksek düzeyde ölçeklenebilirlik ve erişilebilirlik sağlayan bir replikasyon türüdür.
Standart replikasyonun aksine, burada “Yayıncı” (Publisher) ve “Abone” (Subscriber) ayrımı keskin değildir; her sunucu hem veri gönderen hem de veri alan bir “eş” (peer) konumundadır.
P2P replikasyon, Transactional Replication altyapısını kullanır. Fark olarak her subscriber aynı zamanda publisher’dır. Bir düğümde yapılan herhangi bir INSERT, UPDATE veya DELETE işlemi, diğer tüm düğümlere dağıtılır. Veri sadece merkezden dağılmaz, her düğümden her düğüme çift yönlü bir trafik vardır. Her düğümdeki işlem günlüklerini (Transaction Logs) okuyarak değişiklikleri yakalar. Yakalanan bu değişiklikleri ağdaki diğer tüm eşlere (peers) iletir.
Kullanım Senaryoları:
- Okuma Yükünü Dağıtma (Read Scalability): Uygulamanızın dünya genelinde kullanıcıları varsa, veriyi her bölgedeki yerel sunucuya replike ederek kullanıcıların en yakın sunucudan hızlıca veri okumasını sağlayabilirsiniz.
- Yüksek Erişilebilirlik (High Availability): Bir sunucu çöktüğünde, uygulama trafiği anında diğer eş sunuculardan birine yönlendirilebilir.
- Coğrafi Olarak Dağıtık Sistemler: Şubeler arası veri tutarlılığı sağlamak için idealdir. Örneğin, New York ve Londra ofislerinin aynı veritabanı üzerinde çalışması gerekirse kullanılır.
Faydaları:
- Okuma işlemlerini farklı sunuculara yayarak ana sunucunun yükünü hafifletir.
- Transactional altyapı sayesinde veriler milisaniyeler içinde diğer sunuculara ulaşır.
- Bir düğümde bakım yaparken veya bir arıza yaşandığında sistem diğerleri üzerinden çalışmaya devam eder.
- Kullanıcılar kendi bölgelerindeki sunucuya eriştikleri için ağ gecikmesi (latency) minimuma iner.
Dikkat Edilmesi Gereken Kritik Noktalar
- Bu özellik yalnızca SQL Server Enterprise sürümünde mevcuttur.
- Aynı satırın iki farklı sunucuda aynı anda güncellenmesi durumunda çakışma yaşanabilir. SQL Server 2008 ve sonrasında “Conflict Detection” özelliği gelse de, uygulamayı bu çakışmaları önleyecek şekilde tasarlamak (örneğin her bölgeye belirli ID aralıkları atamak) en sağlıklı yoldur.
- Tablolarda Primary Key olması zorunludur ve her düğümdeki veritabanı şeması birebir aynı olmalıdır.
Kurulum işlemine geçmeden önce bazı bilgiler vermek gerekirse kurulumdaki en önemli farklardan biri her subscriber’da distributor olması gerektiğidir. Transactional Replication kurulumun makalesinde yapmış olduğumuz distributor yapısını mevcut olan ikinci sunucumuza da ekliyoruz. İlgili makaleden ilk sunucu için Distribution yapısı olduğu için ikinci sunucu için bu işlemi yapmıyoruz.
Bilgi olması açısından ssql server kurulumunda database engine role’ünün yanına replication role’ünün eklenmesi gerekmektedir. Bu özellik seçilmezse replication servisleri yüklenmez ve sihirbazlar çalışmaz.
En az iki farklı SQL Server Instance gereklidir.
- Publisher (Yayıncı): Verinin asıl sahibi.
- Subscriber (Abone): Verinin kopyalanacağı yer.
- Not: İsterseniz “Distributor” (Dağıtıcı) rolünü üçüncü bir sunucuya verebilirsiniz, ancak genellikle Publisher ve Distributor aynı sunucuda yapılandırılır.
Not: Instance isimlerinin farklı olması bir engel değildir. Hatta karışıklığı önlemek için farklı olması önerilir. Ancak sunucuların birbirini Host Name (veya SQL Instance Name) üzerinden çözümleyebilmesi şarttır.
İlk olarak oluşturacağımız yapıya değineceksek iki sunucuda Distributor konfigürasyonunun yapılandırılması gerekmektedir. S1 sunucusunda Transactional Replication kurulumu yaparken bu işlemi yaptığım için tekrar yapma gereği duymuyorum. 2. sunucu için Distributor yapısını oluşturuyoruz.
Replication mekanizmasının “postacısı” olan Distribution veritabanını oluşturma adımıdır. SSMS üzerinde “Replication” klasörüne sağ tıklayıp “Configure Distribution” diyoruz.
Gelen ekranda Do not show this page again’i tıklayarak next diyoruz.
Bir sonraki ekranda aşağıdaki gibi seçim yaparak Distributor’ü kurulum yaptığımız sunucuda oluşturuyoruz. Arka planda distribution veritabanıda oluşacak. Next diyerek ilerliyoruz.
Gelen ekranda sql server agent servisinin otomatik başlaması için Yes diyiyoruz.
Dağıtımın yapılacağı bir klasör yolu (Network Share) belirtilir. Değişiklikleri takip eden logların ve ilk kurulumdaki veri setinin (snapshot) tutulacağı bir depo oluşturmak için. Replication sistemi veriyi nereye yazacağını ve nereden dağıtacağını bilemez, sistem çalışmaz. Bunun için S1 sunucusu üzerinde önceden yapılandırılan paylaşım yolu belirtilir.
Oluşturulan paylaşım klasörüne sql server engine ve agent servis hesaplarına full kontrol yetkisi verilmesi gerekmektedir.
S1 sunucusu üzerinde ReplicationFolder klasörünü Snapshot folder kısmına oluşturulan paylaşım klasörü yazılır.
Bir sonraki ekranda aşağıdaki gibi distribution veritabanının data ve log dosyalarının hangi path’lerde tutulacağı bilgilerini girip next diyerek ilerliyoruz. Hiçbir değişim yapmadan default şeklinde bırakıyorum.
Bir sonraki ekranda bu distribution veritabanının hangi Publisher’ın kullanacağını belirliyoruz. Biz Publisher ve distributor’ın aynı instance üzerinde kuracağımız için aynı instance’ı seçili bırakıp next diyerek ilerliyoruz.
Seçili olan Configure Distribution yapısını gördükten sonra Next diyoruz. İkinci seçeneği işaretlerseniz yapılan işlemin scriptini alabilirsiniz.
Finish diyerek yapılan işlemler tamamlanır.
Kurulum işlemleri gerçekleştikten sonra sistem veritabanları içerisinde distrubution veritabanının görülmesi gerekmektedir.
Bu yapıyı oluşturduktan sonra karşılıklı iki tarafta tablomuzu kullanacağımız bir tablo oluşturalım. Tablomuzu 1. instance üzerinde oluşturmuş oluruz.
S2 sunucusunda Distributor yapılandırmamız bittikten sonra S1 sunucusundaki instance’a geçerek aşağıdaki gibi Replication bölümünde Local Publications’a sağ tıklayarak New Publication diyoruz.
Gelen ekranda Do not show this page again’i tıklayarak next diyoruz.
Gelen ekranda hangi veritabanımızı replica edeceksek seçim işlemi yapılmaktadır. İlgili veritabanı seçimi yaptıktan sonra Next denilir.
Gelen ekranda aşağıdaki gibi Peer to Peer Replication’ı seçerek Next diyoruz.
Gelen ekranda article olarak hangi nesne seçimini yapmak istiyorsak ilgili nesne seçimi yapılmaktadır.
Bir sonraki ekranda article’ları soruyor. Başlangıçta oluşturduğumuz dbo.PeerToPeerTable tablosunu seçip Next diyoruz.
Bir sonraki ekranda aşağıdaki gibi Create the publication seçili iken next diyerek ilerliyoruz.
Gelen ekranda Publication’a bir isim veriyoruz ve finish diyerek publication kurulumunu tamamlıyoruz.
Başarılı bir şekilde kurulumu gerçekleştirmiş olduk.
Transactional Replication’dan farklı olarak Snapshot Agent’ı yapılandırmadık ve filtreleme yapmadık. Filtreleme Peer To Peer Transactional Replication’da desteklenmiyor. 1.sunucudan 2.sunucuya olan aktarımıda backup restore yöntemi ile yapıyoruz. Restore sonrasında replike etmeyeceğiniz tabloları 2.sunucudan silmelisiniz.
Şimdi aşağıdaki gibi oluşan publication’a sağ tıklayarak Configure Peer-To-Peer Topology… seçeneğini seçiyoruz.
Açılan ekranda aşağıdaki gibi 1.instance’ı seçiyoruz.
Gelen ekranda aşağıdaki gibi Add a New Peer Node diyoruz.
İkinci sunucumuza bağlantı sağlanır.
Gelen ekranda aşağıdaki seçimleri yapmış oluruz.
1. Seçenek: Push Subscriptions
Verinin dağıtılma emri ve yönetimi merkezden (Distributor) kontrol edilir. Veri, Subscriber’a “itilir”.
- Yönetimi çok daha kolaydır. Replication Monitor üzerinden tüm akışı tek bir merkezden izleyebilirsin. Eğer sunucuların aynı local network üzerindeyse en mantıklı yoldur.
- Bu seçeneği seçmezsen, her bir abone (subscriber) kendi işini kendi takip etmek zorunda kalır. 10 tane aboneneniz olduğunu düşünürseniz, 10 ayrı yerden yönetim yapmanız gerekir.
2. Seçenek: Pull Subscriptions
Abone sunucu, belirli aralıklarla “yeni veri var mı?” diye merkez sunucuya sorar ve veriyi kendisi “çeker”.
- Eğer ana sunucun (Publisher) donanımsal olarak çok zayıfsa ve 1. seçeneği seçersen, replication trafiği ana sunucuyu iyice yorabilir.
- Eğer Publisher/Distributor sunucun üzerinde çok fazla yük (CPU/RAM) varsa ve bu yükü hafifletmek istiyorsan veya Subscriber sayısı çok fazlaysa (yüzlerce abone gibi) tercih edilir.
Gelen ekranda bağlantımızın sağlandığı görülmektedir. Next deyip bir sonraki adıma geçiyoruz.
Bir sonraki ekranda 2.instance’daki Log Reader Agent’ın kullanıcı hesaplarını soruyor. 2.instance normalde subscriber ama Peer-To-Peer Replication’da her subscriber aynı zamanda publisher olduğu için bu bilgileri doldurmamızı istiyor. Buraya gireceğimiz kullanıcı hesabı için makalenin başında anlattığımız Log Reader Agent için set edeceğiniz kullanıcının minimum haklarını vermelisiniz. Aşağıdaki ekranda sağ taraftaki …. Ya tıklayarak ilgili kullanıcı seçimimizi yapıyoruz.
Biz iki instance üzerinde de aynı windows account’u kullanıyoruz ve bu account’a belirttiğimiz yetkileri daha önce verdik. Bu yüzden aşağıdaki gibi bir seçim yapıyoruz.
Ok deyip işlemlerimizi tamamlıyoruz. Next dedikten sonra gelen ekranda her iki instance üzerindeki subscription’lar için gerekli güvenlik ayarlarını yapmamız gerekiyor. Yukarda anlattığım şekilde sağ taraftaki …. Üzerine tıklayarak Run under the SQL Server agent service account..’u seçerek devam ediyoruz.
Gerekli seçimleri yaptıktan sonra aşağıdaki gibi bir ekran gelmeli.
Bir sonraki ekranda I restored a backup of the original publication database… ile başlayan kısmı seçiyoum ve 1.instance’dan 2.instance’a veritabanını backup restore yöntemiyle aktarırken aldığım backup’ın path’ini gösteriyorum.
Finish diyerek başarılı bir şekilde kurulum işlemi yapılır.
Kurulumumuz bu şekilde tamamlanmış oluyor. 1.Sunucudaki tabloya bir kayıt eklediğinizde 2. sunucuda görebileceksiniz. 2.sunucuda bu kaydı update ettiğinizde ise değişikliklerin 1.sunucudaki tabloya yansıdığını fark edeceksiniz. Aynı anda 1.sunucu ve 2.sunucu aynı satırı update etmeye çalışırsa conflict olacaktır. Oluşan conflictleri aşağıdaki şekilde görebilirsiniz.
Başka makalede görüşmek dileğiyle..
Gıybet etmeyin. Hucurat-12
