Will having 3 servers + load balancer help in my situation?

They want to make more money off you, it's that simple.

First things first: taking a backup makes your DB inaccessible? Either you've got a very poor backup solution, or you have serious I/O issues on the server. It's most likely I/O. I'd look at getting this fixed first of all. If you're on a VPS then your host might be able to assign raw LUN mappings to you, rather than giving you a virtual disk on a shared, abstracted LUN.

If they're not going to set up MySQL replication, then you're going to either be on your own, or charge you a fortune for it. I'm not familiar with MySQL replication (only MSSQL) but I'm guessing this is not a trivial task and needs to be undertaken by someone who knows what they're doing. If you're not going to be duplicating your SQL server, only your web server, then I fail to see how this is going to help your site.

Thirdly, you've not given us any details about the database, so this is just a stab in the dark, but perhaps there are places you can optimise inside your DB. An Opteron 2212 and 8Gb of RAM is not a slow system. We've got 400 concurrent users 18 hours a day hammering out over 500,000 requests a day on our portal resulting in 10s of millions of queries on a 30Gb database and it runs beautifully on a machine on similar spec. Well designed indexes can save you a lot of money, time and headaches.

I think there's a lot of other avenues to look at first, before deciding to go down the load balancing path, especially if you're going to cluster SQL servers. There is one point that they got right though - if one server goes down, you do have instant failover (if your load balancer is configured correctly), but even if you don't have failover, you do have backups (hence the first point) so its probably not the end of the world.

While I appreciate Farseeeker's perspective and believe that it does have value, I would suggest that their only motive may not be only to make money from you.

It sounds like that may be offering close to an ideal solution or at least a more professional solution than what you have implemented now. Nevertheless, it may still be over-engineered for your needs. That is partially a business question. Is the additional expense justified?

The high loads require substantially more research. Rhetorically.. Is it read queries? Can they be optimized? Is your schema optimized? If it is write queries, you might need to scale up or out. Otherwise, you could consider archiving the data that is no longer necessary.

A common solution for backing up MySQL databases is using a slave relicant and then taking a snapshot of it, which prevents DB locking. While I/O contention is a possible cause, using mysqldump or mysqlhotcopy often introduces some level of locking. Other solutions include Xtrabackup. Chances are there is room for substantial improvement with your backup solution.

While what they propose is certainly closer to ideal and better than what you have now, whether or not it is justified is up for you to decide. You can likely get more bang for your buck and reduce recurring expenses by improving what you have now, as that will solidify your platform for future growth.

You should be able to run a backup on that machine without locking the database. I would take a look at other backup options. What are you using now?

Unless your concurrent user load is the problem, a load balancer+servers will cause you more problems than solutions. Depending on your database usage (what kind of I/O? Mostly reads? Mostly writes?) there are several ways to optimize your database. MySQL replication is not difficult to set up, but I don't think it is a solution for your problem.

You seem to be arguing that the source of your performance problems is exclusively the load from the mysql server - while the proposed solution would handle the HTTP load more effecticely it seems to do nothing for the mysql problem. Are you sure that the DBMS is the cause of the problems when you're not doing backups?

I disagree with Farseeker - mysql replication for the purposes of getting a consistent backup is very simple to set up (simple master-slave replication). It does seem a waste to not take advantage of the potential load-balancing capability - but combined with the backup reuirement, this would make the config rather complicated.

You should be able to run a backup on that machine without locking the database.

? Wow. How? Every DBMS I've used can potentially lock during a backup - including Oracle and Sybase. Certainly locking is far less frequent with the more recent c-isam engines in MySQL - but it still exists.

You are mentioning a high amount of writes for a web application, are you sure its 65:35? If you have high MySQL-load, then your issue wouldn't be solved by extending the amount of servers, since you cannot distribute database writes in an easy manner without (usually) heavy modifications to your code.

You have a few options:

1. Optimize your database, as suggested by the other answers. That means, make sure all data is indexed correctly.

2. Cache your results on the webserver. There are different strategies for this, one of the easiest being to write down generated HTML into a file that you just read and output if cache is not invalidated. Serializing PHP objects into files is another. Read up on different caching techniques for your platform (I'm guessing PHP?)

3. Use another backup solution. If you only use MyISAM tables, look into mysqlhotcopy. It's usually MyISAM tables that gives you trouble because of complete table locks on backup.

4. Take backup from a slave-database, residing on another machine, but your provider tells you they cannot do this? Seems incompetent to me.