Hi,
Got a conundrum, we use SQL Standard in the following bi-directional merge replication scenario:
subscribtor <-LAN-> publisher <-WAN-> re-publisher <-LAN-> subscribtor
Identities are manually managed on each of the servers so that no collision can occur during replication. And I cannot modify the application at this time.
The old setup has just the 2 publisher in a single merge replication scenario. I thought that adding 2 more servers would help unload some of the writes especially since some tables are transient but still need to be replicated in case one side of the application crashes but not the other.
----
At the moment we are doing load testing as we are prepping a migration from 2005 to 2012. With the current production load the system copes barely and we start seeing deadlocks as well as merge replication being deadlocked on the WAN side. As this is in the test environment which has a fifth of the power of the future prod environment I am not that much bothered by it. At the moment this load represents up to 10 000 writes and I guesstimate about 10 times that in read every minutes per server. So around 40 000 writes a minute overall.
However I still want to improve things so that we can handle a few times the amount above before starting to see deadlocks. For instance I had hopped to filter the table so only 10 minutes dated data would be replicated though the links as we don't require real time synchronization. But as getutcdate is non deterministic, can't use it in a filter or pre-computer partitions.
----
So, is it possible to only send data in a merge replication that is dated in the past ? Lots of timestamp in the tables so it be perfect.
Is it also possible to not lock whole tables in the merge replication process so that for instance inserts can still happen ? I do have a few table that only get inserts.
---
Thanks,