Clustered VS Replication in WAN

[xiao]

We have two SQL servers, one in NY, one in Illinois, and we
want to sync them. Suppose we have a T1 line as backbone,
which one is a better solution for us, Clustered or SQL
replication ? Your help will be greatly appreciated!
Xiao

[tammy moisan]

from your email, i think you may not fully understand what a clustered server is. a clustered server has only one copy of the data and two machines looking at it. so you are not really producing two identical databases. you are just allowing two machines to control one set of data. additionally, i have never tried to put the two servers in different locations and do not think it is possible because i beleive it has to have a physical connection to the data storage box.

while replication could keep them close, there would be a significant overhead on your (i am assuming) production machines that you are trying to keep in sync. the best method would be log shipping. logs can be shipped from one server to the other so the same thing happens in the same order on both server and can be shipped as often as you like. this is part of creating a standby server, but you can use the standby server for your other office, as long as the other office's changes do not need to be replicated back to your office's server.

hope this helps.


------------
xiao at 6/4/01 10:59:13 AM


We have two SQL servers, one in NY, one in Illinois, and we
want to sync them. Suppose we have a T1 line as backbone,
which one is a better solution for us, Clustered or SQL
replication ? Your help will be greatly appreciated!
Xiao

[Jeff Putnam]

Hmm.. I think you haven't clustered in a while.. to quote from Microsoft:

Mirrored disks: A more flexible alternative is to let each server have its own disks, and to run software that "mirrors" every write from one server to a copy of the data on at least one other server. This is a great technique for keeping data at a disaster recovery site in synch with a primary server. A large number of disk mirroring solutions are available today; examples for the Windows NT Server environment are available from Network Specialists (NSI), Octopus, Veritas, and Vinca. Many of these mirroring vendors also offer cluster-like high-availability extensions that can switch workload over to a different server using a mirrored copy of data. However, mirrored-disk failover solutions cannot deliver the scalability benefits of clusters. It is also arguable that they can never deliver as high a level of availability and manageability as shared-disk clustering since there is always a finite amount of time during the mirroring operation in which the data at both servers is not 100 percent identical.

"Shared nothing": In response to the limitations of shared-disk clustering, modern cluster solutions employ a "shared nothing" architecture in which each server owns its own disk resources (that is, they share "nothing" at any point in time). In the event of a server failure, a shared-nothing cluster has software that can transfer ownership of a disk from one server to another. This provides the same high level of availability as shared-disk clusters, and potentially higher scalability since it does not have the inherent bottleneck of a DLM. Best of all, it works with standard applications since there's no special disk access requirements. Examples of shared-nothing clustering solutions include Tandem NonStop, Informix Online/XPS, and Microsoft Cluster Server.


------------
tammy moisan at 6/4/01 2:48:20 PM

from your email, i think you may not fully understand what a clustered server is. a clustered server has only one copy of the data and two machines looking at it. so you are not really producing two identical databases. you are just allowing two machines to control one set of data. additionally, i have never tried to put the two servers in different locations and do not think it is possible because i beleive it has to have a physical connection to the data storage box.

while replication could keep them close, there would be a significant overhead on your (i am assuming) production machines that you are trying to keep in sync. the best method would be log shipping. logs can be shipped from one server to the other so the same thing happens in the same order on both server and can be shipped as often as you like. this is part of creating a standby server, but you can use the standby server for your other office, as long as the other office's changes do not need to be replicated back to your office's server.

hope this helps.


------------
xiao at 6/4/01 10:59:13 AM


We have two SQL servers, one in NY, one in Illinois, and we
want to sync them. Suppose we have a T1 line as backbone,
which one is a better solution for us, Clustered or SQL
replication ? Your help will be greatly appreciated!
Xiao