At last year’s LDAP-Con event, Ludo from OpenDS and Howard from OpenLDAP presented on the work that they’d done on using MySQL Cluster as the scalable, real-time data store for LDAP directories (going directly to the NDB API rather than using SQL). Symas now provide their implementation (back-ndb) for OpenLDAP.

You can view the charts at http://www.mysql.com/customers/view/?id=1041

I’ve been offline (mostly) for the past week while at Tracker School and over the next few days I’ll be catching up on what happened while I was out. You guys were busy. As I pulled into my garage after a long drive this song came on shuffle and I wanted to share it with you guys — Nina Simone’s Feeling Good:

I’ll be speaking on MySQL Users Conference 2010. Talk: MySQL Architecture Design Patterns for Performance, Scalability, and Availability, 11:55am Thursday, 04/15/2010. Details.

Last week the new version 8.5 of dim_STAT was shipped. Along with other new features, there is a new Add-On was introduced since this version: innodbMUTEX. The data collecting by this Add-On are based on the "show engine innodb mutex" output. And it's not only able to scan the "standard" output, but also the "extended" output as well (by extended I mean if with debug options or with a little bit of hacking you'll force InnoDB to print other mutex wait values - they are already present within a code, but by default enabled only for debugging currently). For example in my case I wanted to analyze if in every case a mutex having the highest number of waits/sec will be also having the highest waited time.. - And it was not always true :-) But at least it's true for the rollback segment mutex:

Other previously introduced Add-Ons were also updated (mysqlSTAT, mysqlLOAD, innodbSTAT), and you may get more details about them from …

One of the things I preach about a lot is good monitoring of your database servers; having tools in place to tell you both what good looks like and when things go bad is critical for large scale success. But sometimes you just need to monitor a momentary process, where setting up a check in your normal monitoring software is overkill. In these cases one tool that can help out is the watch command.

Case in point, the other day I needed to back up a fairly large partitioned table (about 1.3TB on disk). The plan? A quick little script to pg_dump each of the partitions (about 325). Feed the script through xargs -P so I don't swamp the box, but I get some concurrency out …

Brian got interviewed by O’Relly recently, and part of it quoted him as saying this:

When everything doesn’t fit onto a computer, you have to be able to migrate data to multiple nodes. You need some sort of scaling solution there… MapReduce works as a solution when your queries are operating over a lot of data; Google sizes of data. Few companies have Google-sized datasets though. The average sites you see, they’re 10-20 gigs of data.

Users shouldn’t need to put that data onto multiple machines anyway. In fact, I don’t think we need a multi-machine solution for the common case at all. We need software that can scale up with today’s hardware. 37signals likes to run boxes with half a terabyte of RAM. Are we there yet with MySQL and InnoDB? No. Postgres? No. Anything …

One of the key features of NoSQL is the fact that its schema-less. Awesome. Of course I could just dump a serialized string of my "document" into an RDBMS and I could end up with more or less the same, but the big difference of course is that NoSQL (to me key-value stores do not fall under the NoSQL umbrella) still supports non hacky ways to interact with individual values inside a document as well as indexing. But while at first it might seem great to not have at the database enforce a specific schema, the app developer better have a good idea of his schema. Otherwise one developer might call a field "is_active" the next one might call it "isActive" and another one "enabled". I have little to no experience with CouchDB, MongoDB etc. but I am not really all that thrilled about schema-less for the above reason, what I want is no-cost-for-schema-changes, I do want a schema!

This is why I was quite thrilled back when IBM come out with top …

I just got a sneak peak at Domas’s slides for his High Concurrency MySQL session next Tuesday.  With apologies to the fine folks presenting at the same time as him, in my opinion you really don’t want to miss his presentation if you care at all about concurrency.  Lots of details about MySQL best practices and how real world problems have been solved.

I've been to (only?) 2 previous MySQL conferences. I never spoken before, I actually tried to avoid it plus I didn't feel I had any hardcore topics worthy of presenting. Last year all MySQL Sales Engineers were told to submit a talk, so I submitted one that I knew would not be accepted ("no vaporware rule"), and it wasn't. Hey, I obeyed our boss more than my collagues who didn't submit anything! I did feel that for me it was a more useful way to spend time with my customers who were at the conference, and just network.

read more

I’m preparing the code for my MySQLConf 2010 session “MySQL Proxy meets: Memcache” where I’ll present how to replicate from MySQL to memcache by using the MySQL Proxy.

Part of it will be using the semi-sync replication support for MySQL 5.5 to implement a synchronous MySQL-to-Memcache replication. All I need is the network protocol definition for semi-sync …

The semi-sync replication is a implemented as replication plugin and lives in:

plugins/semisync/

The master sends a binlog event with a indication that it wants to get a reply for it. Compare these two events:

[0000]  28 00 00 01|00|00 00 00 00 04 01 00 00 00 27 00  (.............'.
[0010]  00 00 00 00 00 00 20 00 14 01 00 00 00 00 00 00  ...... .........
[0020]  6c 6f 63 61 6c 2e 30 30 30 30 30 31              local.000001

… and now with semi-sync:

[0000]  2a 00 00 01|00|ef 00|00 00 00 00 04 …