You seem to have an incorrect picture of what clustering does. Clustering
is a fail-over technology, not a load-balancing technology. Each instance
of SQL server lives on only one cluster host node at a time. If the host
fails, the instance is shifted to another node. While all host nodes have
physical connections to the shared storage, the cluster service arbitrates
ownership so that only one host has access and control of the disk
resource(s) at any time.
If you want a stand-by server, Log Shipping is the most likely technology to
keep a warm stand-by system up to date, especially if they are
geographically separate. Replication can be used as well, but it does not
transfer schema and non-row information such as stored procedures and views
and thus has very limited usefulness..
I suggest purchasing the SQL 2000 Resource Kit and reading the High
Availability section very carefully. That will give you a much better
overview of what the various technology pieces offer and how to put them
together in an effective manner. After that, I suspect you will have some
detailed questions and we (the user community) will be happy to address
them.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
"Dave LLoyd" <dlloyd2000 (AT) hotmasl (DOT) com> wrote
Quote:
Hi,
Can anyone point me in the right direction for some good information on
real
life scenarios in clustering SQL 2000? I'm basically looking at have 2
servers with SQL server installed on both in a load balanced situation.
What
would be the most common way to ensure that data was kept identical on
both
servers if the hardware was completely seperate? Would I need to use the
SQL
Replication or is there other software that could be used to replicate the
files? Or do most people just used shared disks in a cluster. Basically
whats the best way to replicate SQL servers that are on completely
seperate
hardware?
Thanks for any help,
Dave. |