We also need to clearly state what version of Galera Cluster is merged inside of our MariaDB releases. Now that we only have one, its relatively easy. But going forward, the documentation needs to improve. /cc: Daniel Bartholomew

Will Codership aim to also get wsrep used by other database systems?

The issue I see is that the versioning will be regarded as confusing by users, similar to how it went with InnoDB.
If Galera is MariaDB-only, then it makes sense to sync the versioning (i.e. Galera would use the MariaDB version numbers).

I see Galera become a key and critical part of MariaDB in terms of use, anything other than tight integration in this and other relevant factors is a recipe for disaster (and a potential repeat of history).

The flaw is caused by the fact that we currently don't build the galera library at all, we just use packages that codership provides (but we make them available from MariaDB repos). Codership only provides debs and rpms, so do we.

To fix this, we'll need to start building galera on our own. If we do this, garbd will get built also, we'll just need to remember to include it into the package.

The downside of including galera library into the main mariadb tgz is that we won't be able to replace the library on fly, should Codership release a new version between releases of MariaDB Galera cluster. It's worth consideration whether we want to provide it as a part of the main tgz or as a separate tgz available on MariaDB downloads page.

In reality, it's just one single .so file, so in the event someone wants/needs to upgrade the Galera library only without upgrading all of MariaDB, it should be pretty easy to do that, from a purely practical standpoint. The question of how that replacement library might be packaged is another one.

But I think the binary tarball should include everything you need to get the whole system up and running, meaning that it should include the Galera library, too.

Most of these same arguments could be made for storage engines, too, couldn't they? What if someone wants to upgrade XtraDB or InnoDB or some other thing without having to upgrade the server? No emphasis has ever been placed on that kind of workflow and I see the situation with Galera being pretty similar.

Tarball available here since May - http://downloads.skysql.com/archives/SkySQL/skysql-enterprise/1/1.2/1.2-2/skysql-mariadb-galera/

Sorry I missed this bug.
/iz

MDEV-4999 was marked as a duplicate of this one.

The bug was originally assigned to Rasmus, because there is a question whether we continue trying to rely on Codership release builds/packages or start building everything we need ourselves. I suppose we have already started moving in the latter direction by fixing the Wheezy problem (MDEV-4229), but we are not quite there yet, so I am assigning it back to Rasmus to make the decision.

After that, we will probably need some buildbot-related work to make it pull the right code (download the last released source tarball?) and build it on the same machine where we build our tarballs; then, server bintar creation should be modified so that garbd goes to the <basedir>/bin, and the library to <basedir>/lib (at least I don't see a better solution).

We still don't have an automatic process baked in to buildbot, but for the MariaDB Galera Cluster 5.5.38 and 10.0.12 releases (and actually, I'm pretty sure I did it for the recent 10.0.11 release already) I'm manually adding the files to the bintars. I don't want to close the issue until it's automatic, but for the next releases the issue will be resolved. Once I've got the bandwidth to do some buildbot config hacking, it won't be too hard to get things automatic, and then I'll close.

I spent some time yesterday when working on the MariaDB Galera 5.5.39 release to add a step to my release prep script that automatically adds the files to the bintars as part of prepping them for release. As new versions of Galera are released they'll be incorporated into the bintars of the next MariaDB Galera release automatically.

This task is now finished, AFAIK, so closing.