Quantcast
Channel: SQL Server Replication forum
Viewing all articles
Browse latest Browse all 4054

Chaining replication

$
0
0

I have multiple (remote) databases to aggregate into a single back office database.

The obvious scenario is to use merge replication in push mode (security rules on the remote dbs prevent the faster pull mode from being used).

However, our WAN connections are terribly flaky, with high latency and packet loss, sometimes going offline for days.

I have a *feeling* that transactional replication from the remote dbs to the back office would be a better option but cannot quantify why it may be the better option, especially considering the Agent Profile options are largely similar.

So I have been trying to setup a proof of concept for each scenario:

1) Remote merge/push into the back office - Done.

2) Remote transactional/push into a proxy database at the back office site, then merge/pull the proxys into the back office db - can't seem to get this one working. Each hop will work in isolation. The initial snapshot for the merge of the proxy to the back office works but it never updates. The proxy receives the updates but they never propagate to the back office db.

3) Remote merge/push to a proxy, merge/pull all the proxies. Cannot setup the second hop as the wizard tells me it's not allowed :-/ However there are posts here that say this *is* possible :-/

The replicated data is a simple push of non-overlapping data where the data is not altered in the back office (although it is set to allow alterations at the subscriber or the second subscription kills the replication completely with a trigger).

So the questions I am asking are:

a) Does transactional replication have any advantages over merge replication over the flaky WAN?

b) How do I get the proxy database to participate as both a subscriber and a publisher?

Thanks in advance.



Viewing all articles
Browse latest Browse all 4054

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>