merge replication in place of p2p replication?

  • I am wondering if its possible to set up a peer to peer replication (with three nodes or potentially more) using merge replication instead, in which case will make sure the data is partitioned and there is no conflict resolution required. The main reason is I dont want to get into the cost of enterprise edition.

    Dose anyone see any problem with this approach?

    Thanks,

    Kathleen

  • I suppose you could set up one server as a publisher and the other two as subscribers, then enforce the ranges that each subscriber is allowed to update with triggers specific to each subscriber. It's ugly, but it would work.

    Kendal Van Dyke
    http://kendalvandyke.blogspot.com/[/url]

  • Thanks for the reply!

    The way I was thinking is to set up merge replication between A and B, then B and C, and then A and C. I dont have any experience with replication other than transactional replication. So is it pretty tricky to set up? I figure to use an application layer to assign the update commands to the right server, instead of using triggers, because with P2P, you have to do it this way also.

  • I would keep it simple - one server as publisher, the other two as subscribers. Run the merge agents every minute, or even continuously, to keep latency at a minimum. In this scenario updates made to one server won't show on the other two for up to two minutes, so make sure that's acceptable.

    It's not difficult to set up, but you will have to add a GUID column to each table that you're replicating the first time you take a snapshot - that action will lock the table so watch out if you have big tables because it can take a while.

    Kendal Van Dyke
    http://kendalvandyke.blogspot.com/[/url]

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply