Friday, March 30, 2012

Replication technology question - please help a newbie!

Hi everyone,
I have a question about the replication technology on SQL Server 2000.
Lets say that we have 2 servers (names A & B foir convenicce). Server
"A" is the primary and "B" the backup server.
There exists a transactional replication process - a Central
Publisher/Distributor Model between these servers with "A" acting as
the publisher/distributor and "B" acting as the subscriber,
specifically a "pull" type subscriber.
Lets say Server "A" goes down and "B" kicks in as the backup.
Eventually "A" gets working again. My question is will server "B"
automatically sync any transactions logged in the down time period back
to "A"? Or is there something I'm misiing or not understanding about
this technology?
Any comments/corrections/suggestions really, really appreciated.
Thanking you,
Al.Replication is not primarily designed for fail over. Look at it more like a load balancing
technology. You can offload some work from A onto B, like reporting stuff.
Specifically, B doesn't "kick in as the backup". B is always available for usage, regardless of
whether A is up or not. If you do modifications on B, there is no process of getting those
modification back to A. Transactional is one-way. There are a couple of options with transactional,
"immediate updating" and "queued updating". The later might new to 2005, I'm not sure.
AFAIK, immediate updating means you can modify B and triggers on the tables in B will connect to A
and with assistance of DTC modify A. Modifications on B will not be possible if A isn't up, since
modifications will fail due to these triggers. I might be simplifying a bit, so make sure you read
BOL for more tech details.
Above is for transactional replication. There is Merge as well, which *could* me more suitable for
you, but as Merge is "update anywhere", you should only use it where conflicts and conflict
resolution is acceptable. Again, more info in BOL.
For 2000, I'd suggest Clustering or Log shipping. 2005 adds Database Mirroring, whish is a bit like
log shipping ++. All these three technologies are specifically designed for fail over scenarios.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<almurph@.altavista.com> wrote in message
news:1156759017.702930.219920@.i3g2000cwc.googlegroups.com...
> Hi everyone,
>
> I have a question about the replication technology on SQL Server 2000.
> Lets say that we have 2 servers (names A & B foir convenicce). Server
> "A" is the primary and "B" the backup server.
> There exists a transactional replication process - a Central
> Publisher/Distributor Model between these servers with "A" acting as
> the publisher/distributor and "B" acting as the subscriber,
> specifically a "pull" type subscriber.
> Lets say Server "A" goes down and "B" kicks in as the backup.
> Eventually "A" gets working again. My question is will server "B"
> automatically sync any transactions logged in the down time period back
> to "A"? Or is there something I'm misiing or not understanding about
> this technology?
> Any comments/corrections/suggestions really, really appreciated.
> Thanking you,
> Al.
>|||Tibor,
Thanks a million fof that. The boss is not too keen on clustering
due to the expense but I had never heard of log shipping technology
before. I've done some googleing and have come up trumps.
Thanks once again,
Al.|||This should be a good starting point for comparstion of technologies and methods:
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/sqlhalp.mspx
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
<almurph@.altavista.com> wrote in message
news:1156770100.831789.299900@.h48g2000cwc.googlegroups.com...
> Tibor,
> Thanks a million fof that. The boss is not too keen on clustering
> due to the expense but I had never heard of log shipping technology
> before. I've done some googleing and have come up trumps.
> Thanks once again,
> Al.
>

No comments:

Post a Comment