Sql server 2008 rep...
 
Bildirimler
Hepsini Temizle

Sql server 2008 replication tamam sorun iptali  

  RSS
 Anonim

Merhaba 4 adet iss 2 adet sql 2008 r2 serverim var

2 iss ve 1 sql üsküdarda   2 iis ve 1 sql kadıköyde

sql ller Transactional Replication yapılmış durumda üsküdar
sql Distributor ve publisher olarak kadıköyde

subscriber olarak çalışıyor. replicationda sıkıntım yok.

Bu arada kadıköydeki iss kullanılmıyor yedek domainleride ayrı ama
aynı site

ben üsküdardaki issi kapatıp kadıköydeki domaini açınca ve
replikasyonuda iptal edince

 kadıköydeki subscriber vt primary key hatası veriyor
verdiği hata

 Msg 2627, Level 14, State 1, Line 1

Violation of PRIMARY KEY constraint 'PK_isim'. Cannot insert
duplicate key in object 'dbo.isim'.

The statement has been terminated.

ben replicationu durdurduğumda bu hatayı alıyorum.

benim istediğim rep durunca kadıköy deki vt aynen  kaldığı
yerden devam etsin. ama olmuyor hatam nedir acaba.

 

Not: pubsisherde article ayarlarında tabloların id, id schema
defauldata binding vb true yaptım ama olmuyor.

ayrıca pk alanları not for replicaiton yes yaptım. bu sefer de id ler tutmuyot  üsküdarda silinmiş id leri kadıköyde veriyor(repi kesince) 

 ayrıca merge rep. yaptığımda idlerin çakışması çok yüksek ihtimal oyüzden uzak duruyorum yapımda 🙂

 

Lütfen acil cevap

Alıntı
Gönderildi : 21/03/2014 22:40
oldmember
(@yavuzfilizlibay)
Üye

Merhaba

-skiperror parametresi ile hataların önüne geçebilirsiniz

Detaylar için: http://www.mssqltips.com/sqlservertip/2469/handling-data-consistency-errors-in-sql-server-transactional-replication/  

CevapAlıntı
Gönderildi : 21/03/2014 23:51
 Anonim

benim replikasyon devam ederken sıkıntım yok. agenti durdurduğumda veya replicationdan  subsicriberi sildiğimde .replikasoyon yapılmış vt ye veri yazmaya devam etmek istiyorum. onda da şu sorunu alıyorum. pk alanlarında kaldığı yerden devam etmiyor. silinmiş id leri tekrar vermeye çalışıyor.

öerneğin kullanıcID1 den 100 e kadar ama ralarında silinmişlerde var. id eklerken 101 değilde 35 id veriyor böyle bir durum var. 35 daha önce silinmiş bir kayıt. 

CevapAlıntı
Gönderildi : 22/03/2014 11:58
Bekir Mert GULTEKIN
(@BekirMertGULTEKIN)
Üye

Replikasyonda id yönetimi auto olarak set edildiğinde publisher tarafında yönetilir replikasyonu kaldırdığınızda bu durum ortadan kalkar. Şu an ki sorununuz için bir çözüm sunamayacağım fakat 2 noktada replikasyon için p2p transactional replication uygulanabilir. Fakat databaseyi 1. noktada sıfırdan oluşturup id.leri 1,2 olarak set edip p2p replikasyonu aktif edilir, bu işlemden sonra databasenin scripti alınır ctrl+f ile script içindeki identityler 2,2 olarak replace edilir ve 2. noktada bu script ile yeni database oluşturulur ve bu nokta replikasyona dahil edilir. Bu şekilde id çakışmasının önüne geçilir ve 2 nodeda aynı anda çalışılabilir. Bu noktada update-update, update-delete conflict oluşabilir fakat aynı satırda aynı anda 2 nodda çalışma ihtimali yoksa gayette sağlıklı çalışır. Bu arada Transactional replicationda subscription tarafına replikasyonu kaldırsanızda  veri girilmesi sağlıksız bir durum. Merge replicationıda incelemenizi öneririm, mergede tabloları yayınlarken id yönetimini doğru set edebilirseniz internet üzerinden replike konusunda en sağlıklısıdır diyebilirim. P2p.de bağlantı sorunlarında 3 günü geçtiğinde replikasyon bozuluyor tekrar kurmak gerekiyor fakat bu seferde vt.de veri olduğu için replikasyonu tekrardan kurmak yukarıdaki gibi id set etmek mümkün olmuyor. Bu 3 gün süreyi uzatmak mümkün fakat veri girişi çok ise distrubition doasyasınin boyutu fazlaca büyüyor.

Replikasyon konusu başlı başına bir konu. Internetteki kaynaklara bakınca çok cazip ve kurulması kolaymış gibi görünüyor, cazip olduğu doğru ama kolay bir işlem olmadığı kesin. Replikasyonu high availibility için düşünüyorsanız log shipping ve mirroringi de incelemenizi öneririm, bu ikisi nispeten daha kolay ve sorunsuz. 

CevapAlıntı
Gönderildi : 22/03/2014 17:51
 Anonim

Cevaplar için herkese teşekkür ederim. Uzun süreli değil belli bir kaç gün için bir yapı oluşturduğum için replikasyondaki amacım. 1. noktada bir float atak veya başka saldırı olup kullanılamaz halegelirse 2. noktayı kullanmak. Ben şu şekilde bir çözüm geliştirdim belki başka arkdaşlara yararı olur.

vt deki tablolardaki pk alanlarına tipi int ve auto olanlarda not for replicaition alanlarona "yes" diyoruz. replikasyon bittiğinde subsicriber deki tabloların içine girip not for replication "no" yapıyoruz. busefer idler düzeliyor. Benim tablo sayım 5 olduğu için zaman almıyor ama bunun toplu bir yolu varsa öğretirseniz sevinirim

CevapAlıntı
Gönderildi : 24/03/2014 12:04
 Anonim

[quote user="Bekir Mert GULTEKIN"]

Replikasyonda id yönetimi auto olarak set edildiğinde publisher tarafında yönetilir replikasyonu kaldırdığınızda bu durum ortadan kalkar. Şu an ki sorununuz için bir çözüm sunamayacağım fakat 2 noktada replikasyon için p2p transactional replication uygulanabilir. Fakat databaseyi 1. noktada sıfırdan oluşturup id.leri 1,2 olarak set edip p2p replikasyonu aktif edilir, bu işlemden sonra databasenin scripti alınır ctrl+f ile script içindeki identityler 2,2 olarak replace edilir ve 2. noktada bu script ile yeni database oluşturulur ve bu nokta replikasyona dahil edilir. Bu şekilde id çakışmasının önüne geçilir ve 2 nodeda aynı anda çalışılabilir. Bu noktada update-update, update-delete conflict oluşabilir fakat aynı satırda aynı anda 2 nodda çalışma ihtimali yoksa gayette sağlıklı çalışır. Bu arada Transactional replicationda subscription tarafına replikasyonu kaldırsanızda  veri girilmesi sağlıksız bir durum. Merge replicationıda incelemenizi öneririm, mergede tabloları yayınlarken id yönetimini doğru set edebilirseniz internet üzerinden replike konusunda en sağlıklısıdır diyebilirim. P2p.de bağlantı sorunlarında 3 günü geçtiğinde replikasyon bozuluyor tekrar kurmak gerekiyor fakat bu seferde vt.de veri olduğu için replikasyonu tekrardan kurmak yukarıdaki gibi id set etmek mümkün olmuyor. Bu 3 gün süreyi uzatmak mümkün fakat veri girişi çok ise distrubition doasyasınin boyutu fazlaca büyüyor.

Replikasyon konusu başlı başına bir konu. Internetteki kaynaklara bakınca çok cazip ve kurulması kolaymış gibi görünüyor, cazip olduğu doğru ama kolay bir işlem olmadığı kesin. Replikasyonu high availibility için düşünüyorsanız log shipping ve mirroringi de incelemenizi öneririm, bu ikisi nispeten daha kolay ve sorunsuz. 

[/quote]

Mergeyi yaptım güzel çalıştı fakat 1. noktada idler 1 den 2. noktada idler +5000 koyup öyle başlıyor.yani 5001 den başlıyor . 2 tarafa aynı anda 25000 insert geldiğinde ve arada replication başladığında id ler çakışıyor ve sistem çöküyor.Bunun önüne geçemedim. p2p için 2. noktayıda publisher ve subsiriber mi yapıyoruz internette p2p için çok açıklayıcı kaynak bulamadım. 

CevapAlıntı
Gönderildi : 24/03/2014 12:09
Bekir Mert GULTEKIN
(@BekirMertGULTEKIN)
Üye

Mergede articleleri ilk yayınlarken id aralığını belirtebiliyorsunuz. Örneğin ben şöyle yapıyorum publishere diyorumki publicationda 2.000.000, subscriber tarafında 1.000.000 kullan diyorum.  Bu şekilde publisher tarafı 1'den başlayıp 2.000.000'a kadar gidiyor, abone tarafı ise 2.000.001'den başlıyor 3.000.000'e kadar diğer abone 5.000.001'den başlıyor 6.000.000'e kadar gidiyor. (5 milyondan başlaması thresoldla alakalı, eşikle yani)

P2P'de 2 tarafta distributor ve 2 tarafta publisher ve subscriber. 2 nokta için konfigüre etmek zor değil isterseniz boş bir zamanda remote desktop ile bağlanarak kurabiliriz bu arada siz de izleyerek konuya hakim olursunuz.

CevapAlıntı
Gönderildi : 25/03/2014 22:26
Paylaş: