all groups > sql server replication > february 2005 >
You're in the

sql server replication

group:

Secondary server - Best practice


Secondary server - Best practice Paul Ibison
2/28/2005 7:51:39 AM
sql server replication:
This article might help a bit:
http://www.replicationanswers.com/Standby.htm
For bidirectional replication there are several options:
merge, transactional with updating subscribers and
snapshot with upd subscribers. I would recommend
transactional with queued updating subscribers for your
scenario. It copes well with identity columns, won't
change the table schema, and to reverse the changes when
the production box is later available, you can run the
queue reader agent.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Secondary server - Best practice Jorge Martinez
2/28/2005 11:00:56 AM
Hi to everyone.

We are a small company that cannot afford having a cluster (low budget).
Instead, we are looking for alternatives to have two SQLServers, one of them
configured as a secondary server, so if the former must the put offline
(mantainance, for example) the latter can "hear" user requests.

This is the idea:

SERVER A: MAIN - Contains main SQLServer 2000 Enterprise instance that
attends users requests
SERVER B: BACKUP - Constaint copy all Server A's sql data
PROCEDURE: When putting A offline (install service packs, etc), let B attend
users (they can read AND write in B). When A is back online again, let B
update data on A and A assume as the main server.

We are NOT looking to realize the recovery procedure in an automated fashion
(I read that is very difficult without a cluster). Looking for solutions we
came to:

1) Use SQLServer built-in replication
2) Use sync/async replication at filesystem level (with 3rd-party software)
3) Other?

I read a lot about sql replication but I can't find the right combination of
features (transactional/merge/log shipping). They all seem to be one-way
only (A --> B, but then users can't write to B).

So lot's of questions arise but I would like to hear about your experience:
1) The previous procedure is possible when using SQLServer replication?
2) Will data be consistent or a constistency-check would be necessary to
that all records were replicated?
3) Is sync/async replication at filesystem robust enough? (will I lose
data?)

All of your help would be appreciated.
Thanks a lot,
Jorge

AddThis Social Bookmark Button