Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i wanted to buy 2 dedicated servers, and have one for holding the mysql database and the other one for running the web application, im not sure if thats a good idea.

p.s. in terms of accessing data i was going to do database replication, having the slave database on the webserver, and the master obviously in the mysql server!!


share|improve this question
up vote -1 down vote accepted

Generally this is a good idea. Having your database replicated on another machine, should increase your overall uptime - but usually only, if they are at different data centers. Most of the time that one of my sites was not available was the data centers fault (power and backup-power failure, data connection loss, switch got killed...), only few unscheduled downtimes were on the machines or my account. But this will most likely give you less performance...

In terms of security, separating database and webserver to different machines in different data centers having a backup of the other machines data available should be good.

In terms of performance, separating application and database to different machines in the same data center will be ok - but then you dont need replication. A usual backup should be sufficient, running a slave on your application server will eventually slow down your overall performance. If you run this setup, you could probably spare the extra server. Depending on your acutal database queries, you might be able to add extra application server later on without adding another database server. Then the hot standby solution via MySQL slave might be an option.

share|improve this answer
As I said before and symcbean states, you don't really need the extra db server for this setup. It really depends on your application, but having one, that does a lot of writing, you need the extra db server, if more than one application server exists. I would start with a single machine hosting application and db server, if the load is high, move away the application and add additional machines. If you want failover security, that would be another question.... – MaoPU Sep 10 '10 at 9:11
btw: what is the -1 for? – MaoPU Sep 13 '10 at 19:18

Generally, yes having your DB and Web servers separate is a good idea. You don't need to have yet another DB server on the web server, just have your application directly connect to the DB server.

share|improve this answer
yes it better for performance? – Solomon Saleh Sep 10 '10 at 4:03
Small load you won't see much performance, large load yes. It really gives you an easier way to scale out when the time comes. – Zypher Sep 10 '10 at 4:09

No, this is a dumb idea. It will make your application run slower and less reliably than the alternative....

Set up both machines as webserver and database server. One as the mysql master, the other as the slave. The add round-robin DNS. If you like you can weight the website address on the machine hosting the slave to push more of the traffic there.

For a fully transparent failover approach a master-master approach may be better - you can still implement update affinity for one node and web request affinity for the other if you really want.

This allows you to:

  • split the load evenly and controllably across the two systems
  • improve the availability of the system by several orders of magnitude
  • simple and fast recovery from a terminal outage on either node

Seperating the functionality across the 2 nodes means that you now have 2 single points of failure. If you model the probability of failure for the 2 approaches, with say a probability of failure of 0.001, then using equivalent nodes, the probability of failure resulting in the system being unavailable is 0.001 x 0.001. OTOH, for the stacked approach the probability of failure resulting in the system being unavailable is 0.001 + 0.001

Having to go across the network every time you need to read from the database (for most applications db reads are much more frequent than writes) is usually at least 10 times slower than access a local service.

share|improve this answer

p.s. in terms of accessing data i was going to do database replication, having the slave database on the webserver, and the master obviously in the mysql server!!

I don't think replication onto the webserver is of much performance benefit but it does setup a nice recent copy of the database which is a data safety benefit but in no way a replacement for backups and this is as long as the extra load doesn't hinder the web app's performance.

If you do go with replication, be sure the web app is already capable of being used with (or being designed for) MySQL replication. The key concern is how replication is eventually consistent meaning the slave can potentially be some time behind the master so should not be considered a source of authoritative data.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.