By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,442 Members | 1,358 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,442 IT Pros & Developers. It's quick & easy.

SS2005 Merge Replication through message queue

balabaster
Expert 100+
P: 797
I have an odd scenario whereby I have two SQL 2005 Servers separated by a firewall and the only means of them talking is via a 3rd party message queueing server. I have a database on each of the SQL servers that needs to be replicated in both directions...this network architecture is not of my doing and security dictates that this cannot change.

In my test environment I've just started investigating how exactly I'm going to approach this and have got as far as setting up multiple instances of SQL 2005 Server and setting up merge replication to successfully keep the two databases synchronized.

At this point, I'm stuck...it seems to me the manner in which merge replication works, I'm not going to be able to use this mechanism to replicate through the message queue, I'm wondering if anyone can give me any relevant input.

Thanks in advance
Feb 27 '08 #1
Share this Question
Share on Google+
5 Replies


balabaster
Expert 100+
P: 797
No takers? I guess I should clarify my question. In the event that my two SQL Servers cannot talk to each other directly, how do I go about achieving synchronicity between my two databases? Can replication be made to work in a disconnected fashion? Or should I be considering alternative solutions?
Feb 27 '08 #2

ck9663
Expert 2.5K+
P: 2,878
Can you try installing a third-party solution on a third machine that can access both? If they can not access each other directly, can you setup a third machine and run everything from there? Like:

If ServerA <----> ServerB is not possible, try:

ServerA <---- ServerC ---> ServerB

(Those arrows represents connections)

-- CK
Feb 27 '08 #3

balabaster
Expert 100+
P: 797
Can you try installing a third-party solution on a third machine that can access both? If they can not access each other directly, can you setup a third machine and run everything from there? Like:

If ServerA <----> ServerB is not possible, try:

ServerA <---- ServerC ---> ServerB

(Those arrows represents connections)

-- CK
Sadly the network is set up in such a way that the only communication between the two subnets is through a messaging queue which is the only hole through the firewall. There's no possibility of setting up machines in a manner that can bypass this. Corporate security guidelines dictate that any and all communication between the two subnets goes through the message queue. I was wondering if there was any way to transmit the transaction log through the message queue and integrate changes on both sides and thus keep the databases synchronized this way.
Feb 27 '08 #4

ck9663
Expert 2.5K+
P: 2,878
I'm not sure if the logs would be sufficient enough to do it. How about a third-party application like an ETL? Sounds to me that even if your environment is the same (same sql server) you might end up doing (as if) an integration.

-- CK
Feb 28 '08 #5

balabaster
Expert 100+
P: 797
I'm not sure if the logs would be sufficient enough to do it. How about a third-party application like an ETL? Sounds to me that even if your environment is the same (same sql server) you might end up doing (as if) an integration.

-- CK
Okay, it looks like I'm going to have to write some custom mechanism to do this which will sync data in a handful of the tables - that is, those tables which are likely to change on a daily basis as the application is maintained. Other tables will have to be maintained manually. I was hoping that the mechanism would allow for a more organic evolution of the database such that any and all changes would be synched but it seems that the security constraints of the network topology prevent such a solution from being put in place.
Feb 28 '08 #6

Post your reply

Sign in to post your reply or Sign up for a free account.