Kaj just announced that as of 5.1.25, MySQL Cluster will no longer be included in the normal MySQL packages. Instead, a new branch is being created for MySQL Cluster releases, where the first release is informally called “6.2.15” but the releases are really named “mysql-5.1.23-ndb-6.2.15”. This new branch is based on the MySQL Cluster Carrier Grade Edition of MySQL.
Overall, this seems like a good idea — the needs for releases, schedules, pressures, etc., are at odds between MySQL Cluster and MySQL’s core. I am, however, baffled by the decision of how to release the new product: coupled with MySQL as a single monolithic package with compiled-in storage engine. After all, 5.1 has long been touted to have this amazing new pluggable storage engine architecture. Why not use it?
With Oracle/InnoDB recently announcing that they are decoupling from MySQL and releasing their storage engine as a plugin, this would make so much sense. The only thing I can think of is that MySQL and/or the MySQL Cluster team must think that the pluggable storage engine concept is not workable in its current state or easy enough to use… which I would agree1 with absolutely. However, having a team within MySQL really pushing a product and using the pluggable interface to make their releases would help dramatically to make the interface really usable for the rest of the world.
Why not do it? Let’s hear it…
1 My short-list of gripes, by no way complete: The error message interface sucks, no way to compile a plugin outside of the MySQL source (or even symlink it into the source tree), plugins are tied to an exact version of MySQL server, and no reasonable way to manage plugins in an OS context (RPMs, .debs, etc).
Jeremy Cole 
My main issue with the engine plugin system right now is that the API is not versioned. That is fundamentally borked. This was discussed at the post-MySQLConf storage engine summit at Google, and all players agree it’s borked (no surprise there).
When that’s resolved, they should also be RPM’able without too much fuss.
I don’t mind that I have to compile it next to a MySQL source tree… that’s workable. It’s the lack of API versioning that is the real killer.
It’s actually a bit trickier tahn that (for cluster). For some added features we go quite deep into parts of the SQL server (e.g. adding SQL syntax) or adding fundamental things to the SQL server (batched key access for joins). These aren’t (yet) pluggable parts of the server.
We also have (historically) hooked into all sorts of things rather tightly (e.g. replication), which, when I last tried to make NDB a pluggable engine, caused no end of fun.
I think it’s a good idea to have NDB be pluggable, but it’s one step at a time :)
Stewart, so what you’re saying is the pluggable API is not good enough for NDB?
I’ve heard it’s also not good enough for many of the partner engines, like Nitro and InfoBright.
“Not good enough” is too harsh, it’s just that a bunch of engines (NDB included) do things they “shouldn’t” do.
Also worth noting is that I’m not aware of any cluster customer or user that has
asked for this, and spending the majority of time doing things people ask for feels like a good thing.
dbnewz » Blog Archive » MySQL Cluster fait bande à part
Log Buffer #99: a Carnival of the Vanities for DBAs