We have a client that would like to have their (Remote) web server
SQL2K instance set-up for 2-way replication against their internal
private SQL2K instance (Local). The problem is their network security
department won't allow *any* TCP/IP socket connections to be
initiated from the Remote SQL2K server through the firewall to their
internal Local server. However outbound connections, initiated from the
Local server (i.e. Local -> Firewall -> Remote), are allowed.
Can SQL Server support 2-way replication under this sort of firewall
restriction?
I imagine the Remote web server SQL2K instance would need to be
configured as the Publisher (listening on port 1433) and the Local
SQL2K instance a Subscriber. The Local Subscriber would then be
configured to connect periodically to the Publisher for updates. When
the Subscriber is connected all queued data deltas (on either server)
would be replicated between them to insure both instances are
synchronized. The Subscriber would then disconnect. (or not?)
Would the distributor process need to run on the Remote or Local
server? Would we need to run merge or transactional based replication?
More info:
- The network connection between servers should hardly
ever be down.
- Not all tables in the database schema need to be
replicated, just a subset.
- To begin with the tables will be empty on both servers,
so we don't need to worry about an initial snapshot.
- We hope to use SQL2K's Auto Identity Range Management
to ensure unique keys do not collide.
Thanks for any feedback you can offer.
Good to hear that it can work Markus,
Do you see any problems in running a very short period between data
merge pushes? Say every minute or even less?
Will SQL2K prevent a new merge from running if one is already in
progress?
-Paul
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment