Replication ile ilgili bi kaynak, bi anlatim, bisi lazim

[reyou]

selamlar,

hemen ozet geciyorum,

A serveri var almanyada,
B serveri var amerikada,
C serveri var cin de.

simdi diyelim B,C serverlari bombos su anda, ve sadece A serveri aktif durumda, ve surekli olarak raporlar calisiyor veri alisverisi oluyor vs..

Amacimiz su,

1- A serverindaki tum bilgileri B,C serverilarina copy et
2- Copy islemi bittikten sonra A,B,C serverlarinin identical olmasina dikkat et.
3- turkiyedeki biri almanya serverina, brezilyadaki amerikadakine, hindistandaki biri cin serverina ulassin
4- turkiyedeki biri almanya serverina ulastigi zaman yaptigi bir update (mesela password degistirdi) B,C serverlarindada update olmasi lazim
5- ozetin ozeti, A,B,C serverlari her daim nasil guncel tutulur?


bunlari bana anlaticak kaynak, kitap, bkz vs neler olabilir?

sizde cevaplarsaniz cok ii olur tabi

[GE-TA]

Merge replication. A'dan publication yaratacaksın. B ve C'den bu publication'a subscription'lar yaratacaksın. 3'lü merge replicationlar biraz sorunludur yalnız. Conflict winner'a karar vermek her zaman kolay olmuyor. Veri yüküne göre distribution'u farklı bir makinaya yönlendirmek iyi olabilir.

Tüm db'yi tek bir publication yapmak yerine belki tablo ilişki ve alakalarına ya da güncellenme sıklıklarına göre birden fazla publication ile gruplamayı düşünebilirsin. Böylece bakımı rahat olur ve performans sorunu yaşamazsın.

Replication Id'lerini de dikkatli ayarla.

B ve C boş db'ler ise subscription'u yaratırken snapshot'dan tablo yapı ve dataları yaratılacaktır. Sonra da distribution geri kalan işleri halleder, veri eşleme vs vs.

Çok bela bir iştir yalnız. Yapması kolay da arızaya düşünce çok sıkıntısı var. En kötüsü de tekrar yaratmak zorunda kalma durumu.

Ayrıca tümünün arasındaki bağlantı kopması değil de herhangi birininki koparsa conflict resolve'da Zeus yardımcın olsun.

Belki mimarinizi tekrar düşünmekte fayda var. Replication olmadan da çözüm bulabilirsiniz belki.

edit: Replication olamadan da derken tüm DB'yi replike etmektenseyi kast ediyorum.

[reyou]

Cevap icin tesekkur ederim :)

aslinda mimarinin en temel amaci su,

1- eger A serverini tsunami alir gotururse
B, C devam etsin sonra biz yine B serverindan baska bir A olusturalim.
2- Load Balancing olayi, aslinda tam olarak degil ama amacimiz
Userlar A,B serverlerini kullanirken biz tum raporlari C serveri uzerinde calistiracaz bolelikle performanstan kazanmis olacagiz.

[GE-TA]

Farklı çözümler çıkabilir. Misal raporların kullanıcıları etkilememesi için C makinasına sadece raporların ihtiyaç duyacağı tabloların transactional replikasyonlarını A veya B makinasından almasını sağlayabilirsiniz.

Transactional daha az maliyetlidir. Conflict handling olmadığı için. Taşınacak veri ne kadar büyük bilmiyorum ama distribution için bir D makinasına da ihtiyaç duyabilirsiniz. A'yı ağlatmamak için. (A'nın asıl makina olduğunu varsayıyorum.)

Disaster için FRS de kullanılabilir.

[Gladmir]

Kullanacağınız DB seçimi de önemli. Geographic redundancy istiyorsun bunun yanında active active hatta bir active daha çalışsın diyorsun. Data synch bir kayarsa, ayıkla pirincin taşını. Streams replication bir option, dataguard uzerinden hardware replication başka bir option ama yinede yapıyı değiştirip ilerlemenizde fayda var.

Bu işlerden çok başım ağrıdı, 3 tane DBA eskittim. There is always another solution

[reyou]

GE-TA said:

Farklı çözümler çıkabilir. Misal raporların kullanıcıları etkilememesi için C makinasına sadece raporların ihtiyaç duyacağı tabloların transactional replikasyonlarını A veya B makinasından almasını sağlayabilirsiniz.

Transactional daha az maliyetlidir. Conflict handling olmadığı için. Taşınacak veri ne kadar büyük bilmiyorum ama distribution için bir D makinasına da ihtiyaç duyabilirsiniz. A'yı ağlatmamak için. (A'nın asıl makina olduğunu varsayıyorum.)

Disaster için FRS de kullanılabilir.

birde bu sorun var, A baya bi agliyor anlattigim sekilde :)

Gladmir said:

Kullanacağınız DB seçimi de önemli. Geographic redundancy istiyorsun bunun yanında active active hatta bir active daha çalışsın diyorsun. Data synch bir kayarsa, ayıkla pirincin taşını. Streams replication bir option, dataguard uzerinden hardware replication başka bir option ama yinede yapıyı değiştirip ilerlemenizde fayda var.

Bu işlerden çok başım ağrıdı, 3 tane DBA eskittim. There is always another solution

baska bi sikintida bu, synch kaydigi zaman tam arapsaci oluyo.

Tek bir makineyi A create,update,delete olarak ayarlayip digerlerini read-only olacak sekilde ayarlamak bi cozum olabilirmiki?

bolelikle B,C subscriber olacaklar A icin, en azindan A patlarsa B yi ana olarak ayarlayip yola devam edebiliriz diye dusunuyorum ama sacmaliyoda olabilirim :)

[Gladmir]

Evet, triple active olayından vazgeçip master/slaves kullanmada fayda var ama... geographic redundancy alt yapın ne olursa olsun adam gibi çalışmayan başına sürekli maintainance ve tahmin edemeyecegin bir dolu overhead i olan bir nane, kesinlikle tavsiye etmiyorum.

[Zaybird]

özeti bile uzun.üşendim okumaya.

[hfg]

guzel soruymus yalniz eksik bilgi var gibi. sebebin belli ama ne icin o yok. is sirridir vs.. seyler olabilir ustune gelmek istemiyorum. neticesinde onemli olan kullanici performans'i mi, data safety mi yoksa raporlama performansi mi? diyeceksin ne sacma soru cunku cevap hepsi. ama bu bir denge meselesi. hangisinden ne derece fedakarlik etmelisin? mesela buyuk bir sosyal ag ise, read ve write edecegin database'ler ayri olabilir ve bunlar da farkli ulkelerde farkli yontemlerle sync olabilir. bir de bunun ustune database design'a bagli. 10.000.000 kayit uzerinde kisa surede tablolar olusacaksa hemen hemen tum RDBMS'ler yavaslar. boylelikle senin bir sekilde arsivleme olayina girmen gerekiyor. bunlarin sync'i zor her ne makineye koyarsan koy.

simdi tekrar dusundum de, projenle beraber bir database architect'e basvurmanda fayda var. en temizi.

[reyou]

eheh :)

ben bi bunun ingilizcesini sql forumlarinada soriyim bari,
sonra arastirmalarima devam ediyim,

bisiler bulursam doner yazarim buraya.