Hi,
Thanks for all of your answers!
I checked SQL Server Cluster and it doesn't support load balancing -
only failover clustering (so in a SQL cluster only one of the nodes
handling the same database is active).
I also thought of having only a single database and many application
servers (IIS or something else), but that still leaves the database
server a bottleneck and a single point of failure.
So the idea I came up with is to have several SQL servers with
replication for high availability, and do the load balancing via the
application - every two parties that initiate a chat will be
associated with one of the SQL servers so indeed every chat takes
place in one database, but if something fails, the application will be
able to switch to another SQL server.
What is your take on that? Am I missing anything?
Best regards,
R. Green
On Apr 17, 4:27 pm, "nospam" <bradtkeS...@veriSPAMzon.netSPAMwrote:
Stay as far a way from relplication if latency is an issue.
I would suggest you look at the cluster version of SQL Server.
Basically, you program your application to refer to a single SQL Server.
However, the cluster "server" is actually several SQL Servers which do the
load balancing and fail-over availability for you.
"RonaldGreen" <zzz...@gmail.comwrote in message
news:11*********************@l77g2000hsb.googlegro ups.com...
Hi,
I have this theoretical problem: Say that I need a chat server that
also has a database where it saves all conversations. However, I need
several servers for availability and load balancing.
Now arises the problem of how to synchronize the servers in the
shortest interval (synchronize databases that is). I'm not sure that
merge or peer-to-peer replication in sql 2005 is the best solution for
synchronization (because it still has a 6-10 seconds latency).
Suggestions anyone?
Thanks in advance,
R.Green- Hide quoted text -
- Show quoted text -