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 have 2 CentOS linux servers in separate data centers on each site of the country. These linux machines run a small web sites on Apache with a MySQL backend. There currently is no VPN connectivity between them at this time and the only way they can communicate is through public IP space.

The question I have is what would the best way to make them redundant in the event if one of them fails the other will take over (master / slave relationship)? I would like to be able to do this with the two servers I currently have without adding a 3rd. I am guessing I would need to create a VPN between the two then use something like DRDB for MySQL.

What would you recommend?

share|improve this question
up vote 5 down vote accepted

MySQL has replication capabilities built in - no need for DRBD. See here.

This replication occurs over the normal MySQL protocol, on TCP port 3306. The native protocol supports TLS encryption, but a VPN might not be a bad idea, either, in light of recent vulnerabilities. Up to you!

From there, you'll just need for your application that's utilizing MySQL to be aware of both servers in some way, or work out some other kind of failover mechanism depending on your application - sounds like you have a local instance of your web application in each location, so just pointing each to its local MySQL instance may do the trick.

Be careful, though - if you're replicating in both directions, you likely don't want both MySQL servers being written to at the same time; conflicting changes could be made to the different servers.

share|improve this answer
THis shoud work for MySQL, but what about apache and the scenario when one of servers go down. Honestly I think it will be really hard for him to avoid the thirds server if he really wants a full redundant system. – golja Jul 15 '12 at 1:07

DRDB only really works as a failover solution. As Shane says, MySQL replication is much more sensible approach. While you could implement this as master/slave you've then got the complications of promoting the slave when you detect an outage. A better solution is to use master-master replication.

But there are limits to the effectiveness of this - replicated writes are implemented by a single thread - so the 'slave' has to work harder than the master to apply them. There is inevitably a delay - although usually this is small enough not to be an issue.

Althouh mysql supports SSL encryption, it doesn't provide a great deal of functionality for tuning access control. It's trivial to set up stud or stunnel to wrap a specific port in SSL. And the replication connection(s) are held open, so the bandwidth overhead is very low. Or even just restrict access to the MySQL port to the remote IP address using iptables.

But you've still got to address the problem of detecting failures and fencing the failed node. Presumably you're doing round-robin balancing across the HTTP servers - in which case clients will tend to stay on the same servers for the duration of the session. The webservers will get the best performance from the local DBMS instance - so should only try to access the remote system when you detect an outage on the local system. Don't worry about trying to automate the recovery - as long as you can script it.

Do read up carefully on MySQL replication - if you do the groundwork then conflicting writes should be very, VERY rare.

share|improve this answer
Multimaster replication across a high-latency, low-capacity link is pretty much guaranteeing conflicting writes. – womble Jul 15 '12 at 0:52
Multimaster across the internet? Really? Yes, it reduces the likelihood of conflicting writes, but the performance will be very, very poor, especially if you use a commit based mechanism. – symcbean Jul 16 '12 at 8:25

DRBD has the major drawback that communication will not be encrypted. So go for mySQL-replication.

In your setup I would not use any automatic clustering, since I can see no safe way to avoid split-brain situations.

But you can trigger manually a script that will

  • Promote the secondary MySQL to Master
  • Put on your logical IP that is used for contacting your service
  • Start your webserver on that IP

On the other side you have to prevent the startup if it comes back online - and you need a strategy for fallback.

share|improve this answer
You can run DRBD over a VPN if you need to, but DRBD isn't designed for high-latency links anyway. – womble Jul 16 '12 at 8:26
@womble Feasible with protocol A and a buffer of 8 MB. Although I would not recommend that at all. – Nils Jul 17 '12 at 15:38
8MB buffer? That would last less than a half a second at the sort of sustained I/O rates seen in a decent database server. – womble Jul 17 '12 at 22:40

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.