MySQL Cluster splits from MySQL — not pluggable?
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).
May 24th, 2008 at 02:53:37
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.
May 24th, 2008 at 04:08:34
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
May 24th, 2008 at 05:39:49
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.
May 24th, 2008 at 20:18:14
“Not good enough” is too harsh, it’s just that a bunch of engines (NDB included) do things they “shouldn’t” do.
May 24th, 2008 at 22:14:49
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.
May 27th, 2008 at 23:35:52
[...] Jeremy Cole apporte son grain de sel à cette annonce et souligne que cette séparation dans les packages peut également être percue comme un “aveu” que le système actuel permettant à MySQL d’accueillir des moteurs “plugable” ne tient peut-être pas toutes ses promesses… Ce que reconnaît à demi-mot Stewart Smith (MySQL software engineer sur le cluster) dans les commentaires : l’opération n’est apparemment pas simple, les moteurs de stockage (NDB compris) effectuant selon lui plus de tâches qu’ils ne devraient. [...]
May 30th, 2008 at 09:56:15
[...] into the clusters is Jeremy Cole, who notes that MySQL Cluster has been split from the main MySQL distribution. “Overall, this seems like a good idea — the needs for releases, schedules, pressures, [...]