What is the thought on replicating over WAN links.
I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
like a local copy of the DB. So I would like to set up one-way replication.
The ISP says that replication is resource intensive. We have a 768K
Fractional T-1 they tell me that replication would suck up all that
bandwidth? There aren't a lot of updates that go on the DB in a day over
time there are a lot of updates but on a typical day there aren't a terrible
lot.
So I'm trying to gauge whether the ISP is right or if they aren't really
sure in what they are telling me. I would just
like to have a local copy of our DB on-site in-case the ISP's site goes down
for whatever reason.
Thanks,
Geo
Hi Marc
If you are applying normal transactional replication and don't have a lot of
transactions then your line would be more than adequate. The only bandwidth
intensive process would be when you initialize and apply a 1.2 GB snapshot
accross the line. Then SQL will use as much bandwidth as possible.
We've run transactional replication successfully on 256k lines without it
having a huge impact on the line. Again depending on the transaction volumes.
Regards
Cube
http://www.sqlserver.co.za
"marc" wrote:
> What is the thought on replicating over WAN links.
> I have a DB hosted at an off-site ISP it is about 1.2 GB in size. I would
> like a local copy of the DB. So I would like to set up one-way replication.
> The ISP says that replication is resource intensive. We have a 768K
> Fractional T-1 they tell me that replication would suck up all that
> bandwidth? There aren't a lot of updates that go on the DB in a day over
> time there are a lot of updates but on a typical day there aren't a terrible
> lot.
> So I'm trying to gauge whether the ISP is right or if they aren't really
> sure in what they are telling me. I would just
> like to have a local copy of our DB on-site in-case the ISP's site goes down
> for whatever reason.
> Thanks,
> Geo
>
>
Showing posts with label isp. Show all posts
Showing posts with label isp. Show all posts
Friday, March 23, 2012
replication question
My situation:
I have a DB hosted by a 3rd party ISP. I want to replicate that DB locally
with in my office on our local server, mainly for backup purposes. I then
want to replicate that backup DB to a development DB for testing purposes.
Basically I'll have a LIVE DB hosted at the ISP. A backup version of the
LIVE
DB on our local server (peace of mind really) Then a development DB for
testing
purposes.
The Publisher will be the DB at the ISP.
Question 1. Is this a doable or a reasonable solution. I figured
transaction replication
from LIVE to BACKUP. Then Snapshot from BACKUP to
DEVELOPMENT.
It isn't absolutely necessary to have the most recent
data on the development db
since I will only be using it for testing purposes. But
would be nice to draw from
real data, almost live situations.
Question 2. Can a DB or server be both a Publisher and a Subscriber in this
case the BACKUP DB
would be both?
Thanks,
George
George,
this is possible - it is known as republishing. In your case my preference
would be to use merge between the live system and the Backup system, as it
is ideal for this sort of high latency situation. This would allow you to
have the Backup system as the publisher (with merge, the
publisher/subscriber metaphor doesn't especially hold), as you can then
control the configuration settings locally, and I'd have the live system as
a push subscriber. The other system is used as a testing system and the data
could become incompatible with replication from the Backup system, so I
wouldn't use replication to transfer to this box. Instead, I'd use a backup
and restore of the whole database - Backup to Test.
HTH,
Paul Ibison
|||I'd use transactional as
1) it offers better performance
2) it doesn't add a GUID key to every table.
The con of transactional replication is that you need a PK on every table you wish to replicate, and with republishing transactional is more sensitive to schema changes. By more sensitive I mean you have to drop your publications and subscriptions, make c
hanges and re-build again.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
sql
I have a DB hosted by a 3rd party ISP. I want to replicate that DB locally
with in my office on our local server, mainly for backup purposes. I then
want to replicate that backup DB to a development DB for testing purposes.
Basically I'll have a LIVE DB hosted at the ISP. A backup version of the
LIVE
DB on our local server (peace of mind really) Then a development DB for
testing
purposes.
The Publisher will be the DB at the ISP.
Question 1. Is this a doable or a reasonable solution. I figured
transaction replication
from LIVE to BACKUP. Then Snapshot from BACKUP to
DEVELOPMENT.
It isn't absolutely necessary to have the most recent
data on the development db
since I will only be using it for testing purposes. But
would be nice to draw from
real data, almost live situations.
Question 2. Can a DB or server be both a Publisher and a Subscriber in this
case the BACKUP DB
would be both?
Thanks,
George
George,
this is possible - it is known as republishing. In your case my preference
would be to use merge between the live system and the Backup system, as it
is ideal for this sort of high latency situation. This would allow you to
have the Backup system as the publisher (with merge, the
publisher/subscriber metaphor doesn't especially hold), as you can then
control the configuration settings locally, and I'd have the live system as
a push subscriber. The other system is used as a testing system and the data
could become incompatible with replication from the Backup system, so I
wouldn't use replication to transfer to this box. Instead, I'd use a backup
and restore of the whole database - Backup to Test.
HTH,
Paul Ibison
|||I'd use transactional as
1) it offers better performance
2) it doesn't add a GUID key to every table.
The con of transactional replication is that you need a PK on every table you wish to replicate, and with republishing transactional is more sensitive to schema changes. By more sensitive I mean you have to drop your publications and subscriptions, make c
hanges and re-build again.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
sql
Subscribe to:
Posts (Atom)