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 run a mysql server that hosts around 50Gb of data (primarily for around 250 websites), and am wondering what my options are for setting up a redundant MySQL cluster? The primary purpose would be that I could take one server down for maintenance or reboot, without affecting database availablity - and secondarily that there would be some kind of hot failover in case of problems with the live server.

My understanding is that mysql-cluster requires that the DBs be entirely contained in memory, and with so much data, that is not a practical option.

share|improve this question
up vote 3 down vote accepted

What you need is replication. While a lot of people use MySQL replication, I've dealt with it enough (dozens of high capacity production MySQL instances) to know it's not a winning option. It's pretty fragile, and will fail at inconvenient times. Now, I'm leaning towards using a block replication solution such as DRBD to make the MySQL stores consistent.

As far as the failover goes, again MySQL replication doesn't deal with this particularly well. While failing over from master to slave is a fairly automatable operation, dealing with the aftermath (getting replication running again the other way) is always a manual process, requiring poking and prodding to ensure that everything works right. Whichever replication method you choose, I use heartbeat to detect whether everything's working right and when the currently active server falls over, making sure that an orderly takeover of resources occurs.

share|improve this answer

Check out mmm for automated failover. Be sure to set up the two servers as masters, so you have bidirectional replication. Also if you are using autoincrement, make sure you set it up so that you don't have clashes for entries (see this article for details).

Finally, use Maatkit to ensure that there are no inconsistencies between the servers.

share|improve this answer

We have been using DRBD / Heartbeat for awhile now, and it's pretty good, but not ideal for a virtual-server situation (which we have), because it should have multiple connections between the servers, and in a virtual environment, all the connections (serial, ethernet, etc.) are essentially carried over the same wire - so when one times out, they all time out. (I realize I could put a real serial cable on there, but then I would no longer be able to migrate my VMs between hosts - an ability which I don't want to give up)

In this situation I occasionally get a case where neither server can see the other, and they both become "Primary" at the same time (a situation called split-brain, which is a headache to recover from)

But it's definitely a better solution than binlog replication which we were using before that - and from the comments so far it sounds like a more robust solution than mysql-cluster as well.

share|improve this answer

As of mysql 5.1, mysql cluster data (although not its indices) can be stored on disk: What's new in MySQL 5.1

However I would agree with womble that given many of the limitations of mysql-cluster/ndb and the frailty of replication, I would hesitate it to consider either to a general purpose solution. For a single database with a well understood usage model and a real DBA that works with the developers? possibly. But not for a general purpose database server cluster that supports many different applications.

Instead I would want to use either the DRBD approach or just throw money at the problem and use a SAN. No solution that I am aware of is perfect.

share|improve this answer
Tell me what you mean by "throw money at the problem and use a SAN" - as this is already running on a SAN – Brent May 5 '09 at 13:42

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.