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'm interested in using MMR ( for high availability and replication purposes. The problem is, I'm also interested in using Linux-HA for other services, such as Apache. The two overlap when it comes to certain things, such as swapping virtual IP interfaces etc.

Does anyone have a similar setup and have some best practices/solutions for the problem above?

share|improve this question
Interesting question. +1 – Roy Nov 2 '09 at 15:52
up vote 1 down vote accepted

Are the other services on the same machines?

If not then you don't have any overlap (Linux-HA on one set of machines with a virtual IP, and MMR on another set of machines)

If there are other services then perhaps consider virtualization or moving them to other machines, as this will simplify the network interface management (you don't be able to get clashes between the two virtual-IP management methods).

Just make sure that the virtualized masters are on separate hosts, otherwise a failure of the host machine will cause you to lose all your MySQL instances anyway!

share|improve this answer

I use the Linux HA tools for as much as possible, and the MySQL components for as little as possible. I don't trust the MySQL stuff as far as I can throw it.

share|improve this answer

It seems plausible that you could define seperate VIP interfaces for each of the two.

I've been unable to find references on similar configurations, so I think you're just gonna have to work your way through and do a lot of testing.

In genereal however, I'm very sceptical of any multi master replication technology. I'd think hard on whether I could make due with a single master in a failover configuration.

share|improve this answer

Linux-HA and MMR individually can be complicated to get working. If your primary concern is interaction the easiest way to limit it is disparate hardware / networking. If that is not possible the complexity per box will increase. So best practice is to split up your virtual addresses and ip addressing as much as possible so that you can focus the configuration of both Linux-HA and MMR on a subset of interfaces and can worry less about them interfering with each other. I would also think hard as to whether you need master-master replication. It can be very complicated, and complexity is prone to failure.

You may be better served with master slave, or degraded service in the event of primary failure. If you still need master/master you may want to look at postgres (although the mmr options are numerous). I also hate to mention it but would be remiss if I didn't, but in my experience if MMR matters and cannot be solved architecturally or through some other means you may want to look at a commercial database such as Oracle or DB2, both of which implement log based MMR via shared storage and are very reliable.

share|improve this answer

It works fine for us.

However it's critical to have a separate VIP per service, although in theory you don't need it we've found it just works with seperate VIP's and can be a bit odd without.

share|improve this answer

We've got a production cluster that may be similar to what you're interested in:

  • MySQL MMM to keep databases in sync between both servers.
  • OCFS2 on top of DRBD 0.8 in multi-master mode to keep web files and configuration files in sync between both servers.
  • Keepalived on redundant firewalls in front of the web cluster, which keeps track of which servers are up and evenly distributes client connections between them.

It's reasonably simple to implement and keep running, and provides excellent performance. Keepalived can be a little fiddly because it doesn't put super userful errors into syslog about broken configurations, but once you've got it working it's rock solid. DRBD is about the best non-SAN solution for keeping whole filesystems in sync between machines, and OCFS2 is (in our tests) the best performing open source clustered filesystem, and it's setup is real easy as well.

The only real caveat with this is that if a user's connections are being directed at one server, and then they get switched to the other server, it'll lose Apache / PHP session and state data (unless that's all being stored in the database). This isn't a huge deal though, since keepalived has a mode that'll make sure the same client IPs always connect to the same backend servers (assuming they stay up).

share|improve this answer
PHP session data getting kept in the DB is common enough that I'm surprised when it's not the case. Java servlet apps tend to more likely to keep session state in memory, mind.. One problem with apps that need sticky sessions is that you often end up with less "balanced" load-balancing, and can't easily take back-end cluster machines out of the pool without killing some people's sessions, which is annoying. – David Gardner Nov 8 '09 at 17:03

Which OS (Linux) are using ? normally when you have to setup Mysql cluster /Apache i have setup lot of time for our client

| SAN Box |

| | Node1 Node2

services running

VIP Mysql/Apache LVM/GFS/GFS2

and I suggest following link to setup

share|improve this answer
I'm using Ubuntu, but that should not matter much as most practical solutions apply regardless of platform. – imaginative Oct 30 '09 at 19:57
I just wanted to know bcoz most of the time i choose rhel/centos/ubuntu and its work with every one – Rajat Oct 30 '09 at 23:09
-1 The query was about MMR not a MySQL cluster services configuration. – Roy Nov 2 '09 at 15:52

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.