October 8, 2009 at 10:54 pm
Dear all,
We have 2005 merge replication setup with 3 databases with 3 different machines and want them to sync with each other. Can one database setup with both publisher and subscriber by using 2 different merge replication? Thanks a lot.
Best regards,
Wallace Chan
October 9, 2009 at 1:20 am
Chan Wai Yin (10/8/2009)
Dear all,We have 2005 merge replication setup with 3 databases with 3 different machines and want them to sync with each other. Can one database setup with both publisher and subscriber by using 2 different merge replication? Thanks a lot.
Best regards,
Wallace Chan
not exactly sure what you are after, but you can do what they call same server replication. a server can act as subscriber and publisher, you can set up different publications from different machines.
if you can post your replication topology or what you expect to be on each machine, we can help you further
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
October 9, 2009 at 2:19 am
Hi,
Thank you for reply. Our goal is to make 3 databases on 3 different servers can synchronize with each other when any one of the server is down.
Database A in Server A (publisher) -> Database B in Server B (subscriber) using real time merge replication
Database B in Server B (publisher) -> Database C in Server C (subscriber) using real time merge replication
Database C in Server C (publisher) -> Database A in Server A(subscriber) using real time merge replication
Therefore, if the above scenario is possible, each server database should be both publisher and subscriber as well.
Is this cyclic merge replication possible? Thanks a lot.
Best regards,
Wallace
October 9, 2009 at 3:13 am
Chan Wai Yin (10/9/2009)
Hi,Thank you for reply. Our goal is to make 3 databases on 3 different servers can synchronize with each other when any one of the server is down.
Database A in Server A (publisher) -> Database B in Server B (subscriber) using real time merge replication
Database B in Server B (publisher) -> Database C in Server C (subscriber) using real time merge replication
Database C in Server C (publisher) -> Database A in Server A(subscriber) using real time merge replication
Therefore, if the above scenario is possible, each server database should be both publisher and subscriber as well.
Is this cyclic merge replication possible? Thanks a lot.
Best regards,
Wallace
hmm interesting, have you looked at peer to peer replication, one of the advantages of it, it deals with the problem of single point of failure. each node can act as a publisher and subscriber so you eliminate the single point of failure situation.
Regarding your topology, on each server is the publication referring to a different database?
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
October 9, 2009 at 3:57 am
Hi,
Thank you for your reply. We have noticed on Peer-to-Peer Transactional replication before but since SQL 2005 version this P2P replication cannot handle resolve conflict(and need to upgrade to SQL 2008) so due to the effort of migration we are still using SQL 2005 now.
>>Regarding your topology, on each server is the publication referring >>to a different database?[/quote]
Not exactly know your question. Our replication on each database on each server is point to different database on different server. i.e. Database A at Server A (publisher) -> Database B at Server B (subscriber). Hopes this answer the question. Thanks a lot.
Best regards,
Wallace
Silverfox (10/9/2009)
Chan Wai Yin (10/9/2009)
Hi,Thank you for reply. Our goal is to make 3 databases on 3 different servers can synchronize with each other when any one of the server is down.
Database A in Server A (publisher) -> Database B in Server B (subscriber) using real time merge replication
Database B in Server B (publisher) -> Database C in Server C (subscriber) using real time merge replication
Database C in Server C (publisher) -> Database A in Server A(subscriber) using real time merge replication
Therefore, if the above scenario is possible, each server database should be both publisher and subscriber as well.
Is this cyclic merge replication possible? Thanks a lot.
Best regards,
Wallace
hmm interesting, have you looked at peer to peer replication, one of the advantages of it, it deals with the problem of single point of failure. each node can act as a publisher and subscriber so you eliminate the single point of failure situation.
Regarding your topology, on each server is the publication referring to a different database?
October 9, 2009 at 9:42 pm
Hi,
We have encountered another question that when we re-run tha snapshot job in Server A due to resolve conflicts, soon afterwards Server B prompt us to need to run snapshot job in Server B, then after finish running snapshot job in Server B, Server C prompt us and need to run snapshot job in Server C. After finish running snapshot job in Server C, Server A prompt us and need to rerun snapshot job in Server A again! Hence it result in infinite loop and re-run snapshot job in 3 server never end.
Can we disable Server C to Server A snapshot job but still make Server C to Server A replication still function properly? Thanks a lot.
Best regards,
Wallace
Chan Wai Yin (10/9/2009)
Hi,Thank you for your reply. We have noticed on Peer-to-Peer Transactional replication before but since SQL 2005 version this P2P replication cannot handle resolve conflict(and need to upgrade to SQL 2008) so due to the effort of migration we are still using SQL 2005 now.
>>Regarding your topology, on each server is the publication referring >>to a different database?
Not exactly know your question. Our replication on each database on each server is point to different database on different server. i.e. Database A at Server A (publisher) -> Database B at Server B (subscriber). Hopes this answer the question. Thanks a lot.
Best regards,
Wallace
Silverfox (10/9/2009)
Chan Wai Yin (10/9/2009)
Hi,Thank you for reply. Our goal is to make 3 databases on 3 different servers can synchronize with each other when any one of the server is down.
Database A in Server A (publisher) -> Database B in Server B (subscriber) using real time merge replication
Database B in Server B (publisher) -> Database C in Server C (subscriber) using real time merge replication
Database C in Server C (publisher) -> Database A in Server A(subscriber) using real time merge replication
Therefore, if the above scenario is possible, each server database should be both publisher and subscriber as well.
Is this cyclic merge replication possible? Thanks a lot.
Best regards,
Wallace
hmm interesting, have you looked at peer to peer replication, one of the advantages of it, it deals with the problem of single point of failure. each node can act as a publisher and subscriber so you eliminate the single point of failure situation.
Regarding your topology, on each server is the publication referring to a different database?
[/quote]
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply