Load Balance SQL Server [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

This is just an attempt to improve the performance of sql server.

We have a single Windows Server 2008 server with an instance of Sql Server 2008 Enterprise edition. The binary files for SQL Server, The OS files, MDF files, LDF files all reside on a single disk.

In the past we used NLB to provide load balancing for IIS. We had 2 Windows Server 2008 machines and the same website was configured on both the 2 machines and there was a separate machine providing data to the websites.Users would access the virtual IP address and depending on the current load on each node, the cluster would divide the traffic.

Now I want to know if I can try the same for load balancing SQL Server traffic.What I plan is:

1. Install 2 instance of SQL server on 2 separate machines.
2. Place the MDF, LDF files on a shared media such as SAN, RAID 5 which are visible to both the two instances and attach the MDF and LDF on both the two instances.
3. Make a cluster out of the two nodes and let the application access the cluster IP address.

In this case, just as IIS, the cluster would divide the traffic among the 2 nodes and since a single MDF and LDF is being accessed, I guess there wont be any synchronization problem.

My question is:

1. Will this actually improve the performace of SQL server ?
2. Will it have any other implications (we use a lot of transactions in the code)?

Answer 1

Two or more instances of SQL server can not share the same MDF/LDF files. Each SQL server needs exclusive access to it's own database files. So you can not load balance SQL server in this way.

There are basically three options to handle this. Possibly there are even more, but these are the three most commonly used.

Option 1: Master-Slave

One option is to set up multiple SQL server instances in a master slave scenario. One database server is the master and that is the database to which you write all data and changes. The slaves sync with the master and you let the web servers use the slaves for read operations. As most websites usually read more data than they write this helps to increase your database throughput. You will have to change the code of your websites to make it work with separate databases for read and write operations. The slaves can be behind a load balancer so your code would only need to support one write database server and one read database server. When reading, the load balancer will distribute the load evenly across all slaves.

Option 2: Sharding

In this scenario you distribute the data across multiple database servers. A simple example is a user database distributed across two database servers. All users with a odd UserID (e.g. 1, 3, 5, etc.) are stored on database server 1 and all users with an even UserID (e.g. 2, 4, 6, etc.) are stored on database server 2. This has the advantages that on average, each database server takes approximately half the load. This also scales very well as you can add more and more database servers and distribute the data more and more with your own custom schema. Your code will have to be changed to support multiple database servers but if you have a good multi-tier design you will have to change one tier to support this model.

Option 3: Don't use a SQL database

Use a non-SQL database solution. These are becoming more and more popular under the commong name: NoSQL. This means 'Not Only SQL'. It doesn't mean you shouldn't use SQL at all, but it means: don't use it for everything. There are a lot of other database systems which have advantages (and disadvantages) over SQL which might be a solution for your problem. A good read is the blog post: 35+ Use Cases for Choosing Your Next NoSQL Database.

Which option you choose depends on your application and database model. You could use both scenario's at the same time as well. E.g. sharding for the user database and master-slave for the orders table (in a web shop). If you require transaction support or have a lot of join operations, you will have to take this into consideration when deciding on which scenario to take. Scaling databases is a pretty complex topic and there isn't one solution for all problems.