| Markus Renschler 2005-07-25, 3:36 am |
| Hi,
we have a merge replication running in a scenario like yours. The
private server is publisher and distributor. A subscription from there
has been pushed to the remote server. Replication works in both ways
although the remote server is not able to initiate any connection to the
local one.
Markus
pjm wrote:
> 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.
>
|