July 30, 2008 at 12:51 pm
Hi ,
I am new to replication , I have 3 servers A,B,C .A Server is Publisher , B and C are Subscribers. If there is a table with Employee with primary key. If we try to insert record at publisher and subscriber at same time/ before synchronizations starts , what would be the effect .
My understanding was As we insert the record at same time or before the synchronizations starts on both the servers , as it is the primary key column , I am expecting the synchronizations to fail.
please correct me if I am wrong. or some one help me in finding a good resource for betting understanding of such scenarios.
Thanks
Nirmal
July 31, 2008 at 4:29 am
If you add the same PK value on the publisher and subscriber before synchronisation, it will result in a conflict. What happens next depends on the conflict handler you've chosen. But why would you want to do that? In merge replication the best practice is creating PK which are unique to each replication partner, either by adding column to the PK which identifies the server or if you use IDentity columns use ranges for each server.
See here[/url] for more info about Identity ranges
[font="Verdana"]Markus Bohse[/font]
July 31, 2008 at 5:13 am
In merge replication the best practice is creating PK which are unique to each replication partner
I agree in principal, but that will allow duplicates in the underlying business key (e.g. employee_no), even though the PK (employee_id) is unique.
If you didn't have a database, and everything was done manually, how would you handle the same situation? You need to reproduce the same scenario with your conflict handler.
December 16, 2010 at 11:05 am
Hi All,
I have 3 servers and want to apply merge replication for this as A to B to C to A.
Can some one please guide me how to implement this ?
Sharad
December 16, 2010 at 11:30 am
Hi All,
I have 3 servers and want to apply merge replication for this as A to B to C to A.
Can some one please guide me how to implement this ?
I think there are two options:
1] To set up as A as Publisher and B,C as subscriber OR
2] In this case is it possible to set up as A - publisher & B, C as subscriber.I want to set up A publisher & B subscriber and again to make B As Publisher C subscriber.
I am not sure for 2nd point. PLease provide me more details on this ASAP.
Sharad
December 16, 2010 at 12:05 pm
sharad-1144828 (12/16/2010)
Hi All,I have 3 servers and want to apply merge replication for this as A to B to C to A.
Can some one please guide me how to implement this ?
I think there are two options:
1] To set up as A as Publisher and B,C as subscriber OR
2] In this case is it possible to set up as A - publisher & B, C as subscriber.I want to set up A publisher & B subscriber and again to make B As Publisher C subscriber.
I am not sure for 2nd point. PLease provide me more details on this ASAP.
Sharad
Option 1 would be the standard way to do that. I don't believe that option 2 would work but have not tried it with merge. It does work with transactional though but that doesn't have the conflict resolution tables, etc. Again, my guess is that it won't. If during your research you find differently please post back with the information and source.
Out of curiosity, why would you want to use Option 2?
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 16, 2010 at 9:41 pm
Hi David,
Thanks for ur feed back.
Yes, You are right 2nd option wld not possible.
HOwever in first option i think it will take lot of I/O which will affect the performance of the server.
Do you have any idea for this how to control or maintain the performance in merge replication, because in merge replication it always take more I/O which slow downs the server performance.
Sharad
Go Green Print Less
December 17, 2010 at 6:31 am
Unfortunately no I don't. Merge replication is by nature more expensive than other types of replication. Still viable is using transactional with updateable subscriptions. That however doesn't allow for the conflict resolution that you have with merge. If the data is mutually exclusive, i.e. you can guarantee that a record will only be updated on 1 server at a time (very common with user connection information, etc) then peer-to-peer would be recommended. If you need true merge though it can be expensive.
I will say that rebuilding the indexes on the merge replication tables (metadata tables) regularly will help with overall performance. I'll dig around a bit and see if I have anything else on this. We have moved away from it with our busier tables so it is not as big an issue any longer for us presently. I'll reply back if I find anything.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply