September 20, 2014

MySQL and plugin binaries

It seems there is interesting problem with compatibility of MySQL binaries and binaries of third-party plugins.

I personally found and there is confirmation from InnoDB team that current InnoDB-plugin binaries do not work with lastest 5.1.24-rc binaries. It was very charming move from MySQL side to release new incompatible binary on the second day after the announce of InnoDB plugin. I do not think it was intentional, but still looks funny and shows broken communication between teams.

The more interesting becomes from Sergei Golubchik presentation on MySQL Conference, where Sergei says that in current API “versioning binds a plugin binary to specific server release”. That simply means that InnoDB has to release binary for each binary of MySQL. I suppose it should be changed, otherwise there will be total madness with versions – InnoDB 1.0.0 binary for MySQL 5.1.23, 5.1.24, …, InnoDB 1.0.1 binary for MySQL 5.1.23, 5.1.24, 5.1.25… etc.

Even when that is fixed I am looking forward to have good mess with double versioning and problems like ”
MySQL version 5.X.Y does not work with InnoDB version 1.N.M, you need to upgrade InnoDB to version 1.N1.M1 or MySQL to version 5.X1.Y1″.

About Vadim Tkachenko

Vadim leads Percona's development group, which produces Percona Clould Tools, the Percona Server, Percona XraDB Cluster and Percona XtraBackup. He is an expert in solid-state storage, and has helped many hardware and software providers succeed in the MySQL market.

Comments

  1. “It was very charming move from MySQL side to release new incompatible binary on the second day after the announce of InnoDB plugin.”

    Vadim,

    you have worked at MySQL for quite a long time, and so you must know that a build is not instantaneous, but takes several days, possibly weeks, as it involves building and executing extended test suites on all the platforms supported by MySQL. The tagging of MySQL 5.1.24rc and subsequent builds were planned and executed long before the InnoDB announcement.
    The conspiracy theory is groundless.
    You may argue that the plugin interface is tightly coupled with the server version, and it’s true. It’s the same problem that you face when using PBXT plugins, for example.
    If you know how to fix this problem, feel free to contribute the solution. (http://forge.mysql.com/contribute/)

    Best regards

    Giuseppe

  2. Jay Pipes says:

    Giuseppe, Vadim,

    I think the solution is to have a MYSQL_PLUGIN_API_VERSION (or MYSQL_PLUGIN_SE_API_VERSION for storage engines, for example) which does not depend on the MYSQL_SERVER_VERSION… seems simple enough to me.

    -jay

  3. Vadim says:

    Giuseppe,

    Sure, I know building process of MySQL and that’s why I said it was not intentional.

  4. Vadim says:

    Jay,

    Yes, that probably is OK if plugin API is not changed a lot in incompatible way.

  5. peter says:

    Vadim,

    In the perfect world it would be great to have SE Interface version which is same for Major MySQL version – say 5.1 6.0 etc. But with the way things are right now I’m not expecting it to handle any time soon.

    So the question should be what can be done to ease the pain on Storage Engine Vendors (which kind of includes us with Sphinx Storage Engines) and avoid surprises as Innodb got with their plugin release.

    I think what would be important is to involve vendors in QA process. Innodb should have working with MySQL to ensure their plugin at least builts with MySQL 5.1.24 (I’m not speaking about binary compatibility)

    For community storage engines such as PBXT process some kind of similar to Linux Kernel could be established – Community is to provide their storage engine to MySQL so it can be built ant minimally tested with new version release. If it breaks – Community should get an alert about it to be able to fix things quickly.

    Similar process can be employed with Commercial storage engine vendors but in more formal fashion.

Speak Your Mind

*