4

I'm interested in using MMR (http://mysql-mmm.org/) 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?

imaginative
  • 1,941
  • 9
  • 32
  • 48

7 Answers7

1

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!

David Gardner
  • 1,499
  • 2
  • 13
  • 25
0

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.

womble
  • 95,029
  • 29
  • 173
  • 228
0

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.

Roy
  • 4,256
  • 4
  • 35
  • 50
0

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.

MattyB
  • 993
  • 4
  • 6
0

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.

LapTop006
  • 6,466
  • 19
  • 26
0

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).

Graeme
  • 343
  • 1
  • 6
  • 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 08 '09 at 17:03
-2

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

http://kbase.redhat.com/faq/docs/DOC-5648

Rajat
  • 3,329
  • 21
  • 29