Hey Brad. You are right that Mosix won't solve the HA issue. Mosix is
for computational clustering really, which is completely different and
unrelated to HA.
There are several ways to setup MySQL in a HA and high-performance
cluster. The exact method depends on the characteristics of your load
and your budget. Let's assume a low budget.
With performance in mind, one simple method is to assume most of your
work is actually done via SELECTs (e.g., in JOINS, etc). If this
assumption is true, then you do something like:
<----------------- writes -----------------------|
mysql-write --> replication --> mysql-read1 --> <--> clientA
--> replication --> mysql-read2 --> LB <--> clientB
--> replication --> mysql-read3 --> <--> clientC
So your clients connect to a load-balancer (e.g., LVS, CoyotePoint)
that then connects to one of several MySQL servers that are dedicated
to SELECT statements. For writes, a client connects directly to
mysql-write.
The good thing about this layout is that it's not that expensive in
terms of HA software or hardware, and you have a lot of redundancy for
your SELECTs. However, writes are bottlenecked at the mysql-write
server, and if that server fails you can't update the database. Also,
you have the issue that your code has to know that it uses one MySQL
host for writes and another for reads.
Why not perform writes to all the MySQL servers and bypass this
"split" between read and write servers? Well, unless things have
changed drastically, doing multi-master replication with MySQL isn't a
good idea. It is doable, but I always had problems with this in a
cluster environment. And when things go wrong in this configuration,
things GO VERY WRONG AND ITS HARD TO FIX as far as cleaning up the
data goes.
MySQL, the company, has a product for "true" multi-master replication
I believe, but the last I saw the database had to fit into memory to
use it.
Now, I'm assuming your budget is limited. So, an idea if you want to
also have HA for mysql-write in this system that still doesn't
require a huge expense is to do the following:
mysql-write1 --> replication --> mysql-read1 --> <--> clientA
--> replication --> mysql-read2 --> LB <--> clientB
--> replication --> mysql-read3 --> <--> clientC
|
--> replication --> mysql-write2
With this system, you still have master/slave replication (which is
just plain safe). You point your LB at mysql-write and mysql-write2
and clients use one LB VIP for writes (i.e., they do UPDATE, INSERT,
DELETE to mysql-write) and another LB VIP for reads (SELECT). If the
LB detects a failure at mysql-write1, it switches to mysql-write2. The
LB should be configured to *ONLY* switch if mysql-write1 fails, and
then to require manual steps to switch back from mysql-write2 to the
primary at mysql-write1. This ensures you don't have a client that
writes to one server, and some clients that write to another, with
replication not catching all the data. So this configuration does HA
and performance for your reads and HA only for your writes.
Now, we are breaking out our MySQL servers into "read" and "write"
groups because you said "performance and HA" and I assumed "budget".
If you have real money to throw at this, then you don't necessarily
need to do the split, but it's not cheap. If you just want HA, then
things get simpler:
mysql1 -----------------------------> LB <--> client
| |
--> replication --> mysql2 --
In this situation, the LB is configured to only use mysql1. If it
fails, it uses mysql2. A manual step is required to switch from mysql2
back to mysql1 when you fix whatever problem was on mysql1 and resync
the databases.
When doing replication, be sure to setup automated monitoring of your
MySQL logs. Replication CAN AND WILL FAIL at times, and if you don't
watch for this, you are going to get a hard lesson.
Finally, I did an 8-hour tutorial on LVS at USENIX a few years ago. My
presentation is probably outdated a bit, but should be mostly
accurate. It's at:
http://www.puryear-it.com/publications.htm
Does this help?
---
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author:
"Best Practices for Managing Linux and UNIX Servers"
"Spam Fighting and Email Security in the 21st Century"
Download your free copies:
http://www.puryear-it.com/publications.htm
Sunday, January 14, 2007, 3:07:58 PM, you wrote:
> On 1/11/07, michael dolan <michaeldolan at gmail.com> wrote:
>>
>> I didn't even know what MOSIX was. I had to go look it up at
>> wikipedia<http://en.wikipedia.org/wiki/Mosix>
>> :
>> *MOSIX* is a management system for a Linux cluster or a Grid of Linux
>> clusters that provides a Single-System
>> Image<http://en.wikipedia.org/wiki/Single-System_Image>(SSI). In a MOSIX
>> cluster/Grid there is no need to modify or to link
>> applications with any library, to copy files or login to remote nodes, or
>> even to assign processes to different nodes - it is all done automatically,
>> like in an SMP
> and specifically, openmosix is the open source version of mosix:
> *openMosix* is a free <http://en.wikipedia.org/wiki/Free_software>
> cluster<http://en.wikipedia.org/wiki/Computer_cluster>management
> system that provides single-system
> image <http://en.wikipedia.org/wiki/Single-system_image> (SSI) capabilities,
> e.g. automatic work distribution among
> nodes<http://en.wikipedia.org/wiki/Node>.
> It allows program
> processes<http://en.wikipedia.org/wiki/Process_%28computing%29>(not
> threads
> <http://en.wikipedia.org/wiki/Thread_%28computer_science%29>) to
> migrate to machines in the node's
> network<http://en.wikipedia.org/wiki/Computer_network>that would be
> able to run that process faster (process
> migration<http://en.wikipedia.org/w/index.php?title=Process_migration&action=edit>).
> It is particularly useful for running parallel and intensive
> input/output<http://en.wikipedia.org/wiki/Input/output>(I/O)
> applications. It is released as a Linux
> kernel <http://en.wikipedia.org/wiki/Linux_kernel> patch, but is also
> available on specialized LiveCDs
> <http://en.wikipedia.org/wiki/LiveCD> and
> as a Gentoo Linux <http://en.wikipedia.org/wiki/Gentoo_Linux> kernel choice.
> However, after doing some research it won't really help in the situation I
> need it. With apache as the web server.
> Basically, we require more high-availability and load-balancing than raw
> processing power. Openmosix provides
> the raw processing power, but doesn't do much for the other two. In
> addition, openmosix doesn't work with apache or
> mysql (or any other shared memory application). There is a patch to attempt
> to resolve this issue, but as best as I can tell
> it is in no way ready for production.
> So, this leaves me still looking for a cluster solution to cluster apache
> and mysql. Any suggestions?
> i've been looking over the Linux virtual server project and JBoss clustering
> (not apache).
> http://www.linuxvirtualserver.org/
> http://www.jboss.org/developers/projects/jboss/clustering
> any suggestions or experiences are welcome.
> bb
