I’ve been thinking recently about the failure scenarios of MySQL replication clusters, such as master-master pairs or master-master-with-slaves. There are a few tools that are designed to help manage failover and load balancing in such clusters, by moving virtual IP addresses around. The ones I’m familiar with don’t always do the right thing when an irregularity is detected. I’ve been debating what the best way to do replication clustering with automatic failover really is.

I’d like to hear your thoughts on the following question: what types of scenarios require what kind of response from such a tool?

I can think of a number of failures. Let me give just a few simple examples in a master-master pair:

Problem: Query overload on the writable master makes mysqld unresponsive

Do nothing. Moving the queries to another server will cause cascading failures.

Problem: The …

Updated the release, sure it’s only been a matter of hours but I added the standard cnf files for 2,4,8 and 16GB server installations. Also added the rhcluster-wrapper script that can be used to run just about anything on the active database node when using mysql in an active/passive setup.

Download here:  http://code.google.com/p/monolith-toolkit/

Today I decided to package all of my various scripts together into a useful toolkit. Some are perl, some are shell script. These scripts are, in general, one off scripts that I wrote in order to get things done that weren’t available at the time. Now they’re nicely organized and will receive updates at the google code repo.

So far the toolkit includes the following scripts:

• mt-backup-parallel -> the parallel backup script I wrote about in my last post
• mt-check-replication -> script to report on replication status for slave servers
• mt-check-rhcluster-filesystems -> reports on redhat cluster filesystems (for mysql active/passive clustering)
• mt-connections-log -> logs connections to mysql to disk, reports on threshold overages
• mt-flush-tables-sequence -> runs through schema.tables to …

Continuent is probably best known for its database clustering technology for MySQL, as well as PostgreSQL, but the company has for some time had its sights set on expanding beyond open source databases and enabling horizontal database scalability.

It has just taken a major step towards delivering on both counts with the launch of Tungsten, its new stack of open source middleware technologies designed to enable low-cost databases to scale horizontally for database failover and continuity.

Tungsten includes includes Sequoia, the existing …

Spinn3r is hiring for an experienced Senior Systems Administrator with solid Linux and MySQL skills and a passion for building scalable and high performance infrastructure.

About Spinn3r:

Spinn3r is a licensed weblog crawler used by search engines, weblog analytic companies, and generally anyone who needs access to high quality weblog data.

We crawl the entire blogosphere in realtime, remove spam, rank, and classifying blogs, and provide this information to our customers.

Spinn3r is rare in the startup world in that we’re actually profitable. We’ve proven our business model which gives us a significant advantage in future product design and expanding our current customer base and feature set.

We’ve also been smart and haven’t raised a dime of external VC funding which gives us a lot …

I’m going to be migrating to using ZooKeeper within Spinn3r for a myriad of reasons but this one is especially powerful.

One could use ZooKeeper to configure external monitoring systems like Munin and Ganglia.

ZooKeeper enables this with its support for ephemeral files.

If you have an external process like a webserver, database, robot, etc you can have it create a ephemeral file which registers its services and presence in the cluster.

For example:

/services/www/www32.mydomain.com/80

Would represent a machine named www32.mydomain.com.

You can then have munin connect to ZooKeeper and enumerate files in /services/www and have a cron script continually …

A

A

A