Merge replication et al - please help a newbie...

Hi,
Hope you can help me with this one. Advice greatly appreciated. We
have a web application on a server (lets call it server "A"). Its
talking to a DB server (lets call it server "B"). We want to backup
server "B" so that in the event "B" fallsover - the backup server (lets
call it "C") will kick in and carry on from where "B" left off. When
"B" is up it will automatically sync any new transactions logged to "C"
The application on "A" will detect if "B" is down and automatically
switch to "C".
Once "B" is fixed and up and running - "C" will automatically re-sync
with "B" and everything will be grand again.
After looking at various failover models from transactional
replication to log shipping I think that merge replication will do the
trick (because I think it will fulfill all the requirements). The boss
does not want to use failover clustering due to expense.
Can anyone out there please advise on any suggestions/comments/things
to set or watch out for before we begin this process? Any user
experiences/advice much much appreciated.
Thanking you,
Al.For optimal performance use bi-directional transactional replication. While
merge replication will work it adds latency to each DML and the syncs will
take typically over a minute - so your exposure to data loss is greater.
With bi-directional transactional replication it could be seconds.
Note that you really should be using clustering for this.
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<almurph@.altavista.com> wrote in message
news:1156779259.621228.78930@.i3g2000cwc.googlegroups.com...
> Hi,
> Hope you can help me with this one. Advice greatly appreciated. We
> have a web application on a server (lets call it server "A"). Its
> talking to a DB server (lets call it server "B"). We want to backup
> server "B" so that in the event "B" fallsover - the backup server (lets
> call it "C") will kick in and carry on from where "B" left off. When
> "B" is up it will automatically sync any new transactions logged to "C"
> The application on "A" will detect if "B" is down and automatically
> switch to "C".
> Once "B" is fixed and up and running - "C" will automatically re-sync
> with "B" and everything will be grand again.
> After looking at various failover models from transactional
> replication to log shipping I think that merge replication will do the
> trick (because I think it will fulfill all the requirements). The boss
> does not want to use failover clustering due to expense.
> Can anyone out there please advise on any suggestions/comments/things
> to set or watch out for before we begin this process? Any user
> experiences/advice much much appreciated.
> Thanking you,
> Al.
>|||Thanks Hilary,
I heard about translational replication but *not* bi-directional
replication. I take it "works both ways" if you take my meaning. That
is, if B fails and C records some transactions it will sync those back
to B if and when B comes online again. I thought that transactional
replication would not do this.
I know I should be clustering but its expensive and I have buydget
limitations.
Thanks though for your feedback.
Al.|||On 29 Aug 2006 03:25:42 -0700, almurph@.altavista.com wrote:
>Thanks Hilary,
> I heard about translational replication but *not* bi-directional
>replication. I take it "works both ways" if you take my meaning. That
>is, if B fails and C records some transactions it will sync those back
>to B if and when B comes online again. I thought that transactional
>replication would not do this.
> I know I should be clustering but its expensive and I have buydget
>limitations.
> Thanks though for your feedback.
Bidirectional was in SQL2K but the wizards wouldn't do it, you had to
read BOL and script your own commands. Don't know if the SQL2005
wizard is smarter. There are of course the usual complications for
identity fields and such, for replication. You can easily spend more
company money on your time setting up and managing replication, than
you might spend on clustering. Though, the bidirectional replication
looks pretty elegant, from about 10,000 feet of altitude.
J.