MariaDB Packaging Notes

There are some changes in the packaging of MariaDB that though should be aware of.

These changes were necessary to continue offering a solid quality MariaDB package that reflects the massive improvements being made by the MariaDB developers, and these changes also reflect what is taking place in the Fedora world and what I suspect is likely for RHEL/CentOS 8.

The MariaDB packaging layout now in LibreLAMP is essentially the same as current Fedora except I provide a compatibility package for the older libraries, Fedora does not.

Shared Libraries

CentOS 7.5 ships with following MariaDB packages:

  • mariadb-5.5.56-2.el7
  • mariadb-bench-5.5.56-2.el7
  • mariadb-devel-5.5.56-2.el7
  • mariadb-embedded-5.5.56-2.el7
  • mariadb-embedded-devel-5.5.56-2.el7
  • mariadb-libs-5.5.56-2.el7
  • mariadb-server-5.5.56-2.el7
  • mariadb-test-5.5.56-2.el7

The 5.5 series is actually quite old, but that is the series that packages in CentOS 7 and EPEL for CentOS 7 build against. They contain the following shared libraries:

  • libmysqld.so.18 (mariadb-embedded package)
  • libmysqlclient.so.18 (mariadb-libs package)

Previously, LibreLAMP offered newer versions of MariaDB but the shared libraries remained the same, giving compatibility with CentOS and EPEL software linked against them.

With MariaDB 10.2 and forward, that is no longer possible, and the mariadb-libs package no longer exists.

The libmysqlclient shared library is simply no longer built at all. The libmysqld shared library is still built but it has been versioned and it not compatible with the previous ABI.

MariaDB C Connector

This is a new package with a separate source tarball from the main MariaDB code. It is intended as an API compatible replacement for the libmysqlclient.so.18 library, most code designed to build against libmysqlclient.so.18 will build against libmariadb.so.3 from the MariaDB C connector.

I can not expect CentOS or EPEL to rebuild their packages against libmariadb.so.3 because they do not ship that library. I did however rebuild the packages in LibreLAMP that linked against libmysqlclient.so.18 to instead link against libmariadb.so.3 and in all but one case, it was straight forward. The case that was not straight forward was Net-SNMP. That required a patch created from their development branch and should be in the next official release of Net-SNMP without needing to patch it.

Allegedly, libmariadb.so.3 is ABI binary compatible with libmysqlclient.so.18 so I could in theory provide a symbolic link, but there have been a few reported cases where it was not truly ABI compatible.

Those cases allegedly have been fixed but I can not guarantee they will stay fixed, nor do I like the concept of a symbolic link for a shared library.

Also, the symbolic link solution would only solve the libmysqlclient.so.18 problem, not the libmysqld.so.18 problem, so it would only be a partial solution.

Embedded Server

The libmysqld.so.18 library is only needed by applications that have a need for an embedded SQL server, and there are actually not many of them. Mostly they seem to be Desktop applications, like the AmoroK media player.

Still though, the library is needed on some systems and the newer version in MariaDB 10.2.x (libmysqld.so.19) does not even claim to be compatible with the old one, so a symbolic link would never work as a solution.

Rebuilding packages against the newer version of the embedded server library would only be a possible solution for RPMs packaged by LibreLAMP, not for CentOS or EPEL packages.

Compatibility Package

This is the solution I went for. Since MariaDB 10.1.x still builds the correct version of the libraries for packages in CentOS 7 and EPEL for CentOS 7, I took my existing RPM spec file for MariaDB 10.1.x, removed all the stuff from it that is not needed, updated to latest patch release in that series, and created a compatibility package.

In addition to the shared libraries, it also has the contents of the common and errmsg packages for that version of MariaDB as they are needed for the embedded server library.

If your system has software linked against those libraries (and it probably does) this compatibility package will automatically be installed on update, allowing those packages to still properly function while still allowing you to update to MariaDB 10.2 and enjoy the benefits.

Notes

While not critical, I do recommend rebuilding software that links against the old versions of the libraries whenever possible.

For the client library, usually you do not need to do anything, the devel package puts the header files in the same place. If you need to explicitly tell it which library to link against, use -lmariadb instead of -lmysqlclient.

Please not the library is in /usr/lib64 and is NOT in a mysql sub-directory.

When building RPM packages, specifying BuildRequires: mysql-devel should still do the right thing. In fact most spec files do not need any modification at all to rebuild and link against libmariadb.so.

However, I do recommend changing it to BuildRequires: mariadb-connector-c-devel and then changing the name of any mysql specific subpackages to reflect that it is specifically being being built against libmariadb and not libmysqlclient. For example, I changed the dovecot package from dovecot-mysql to dovecot-mariadb.

When you do change the name of a package, make sure it obsoletes the old name for anything less than current epoch:version-release and provides the old name for current epoch:version-release. See my anope.spec file for an example. Note that since anope does not have an epoch, it only deals with version and release, but it is near the top of the link spec file.

For the embedded server library, nothing changes except the library location is now in /usr/lib64 and is NOT in a mysql sub-directory.

There is not a devel package to accompany the compatibility package, if you really need to link against the libraries, build against the devel packages provided by CentOS.

TokuDB Engine

While I started with the Fedora source RPM for MariaDB 10.2.15, I did deviate in the building of TokuDB. TokuDB is a database engine that you probably should not use unless you know you need it. It is really only beneficial for write-intensive high-performance environments. The rest of us should probably stick with InnoDB or if we want to be cool, use the Aria engine that when finished will replace InnoDB as the default engine in MariaDB. (off topic - Aria is usable and very crash resistant, but is not yet finished, e.g. it does not yet have transaction support)

Use of TokuDB is only a supported configuration when it is used with jemalloc for memory allocation, but that is not how Fedora builds it.

There are two reasons Fedora does not build it for use with jemalloc:

  1. Fedora 27 and earlier (and CentOS 7) have the older version of the jemalloc shared library, libjemalloc.so.1. This version only works well with x86_64, but Fedora supports many other platforms.
  2. Starting with Fedora 28, Fedora ships with libjemalloc.so.2 and it looks like that might be what will be in RHEL/CentOS 8. The updated jemalloc works better with other platforms, but it is not API compatible and when TokuDB in MariaDB builds against it, the test suites fail badly.

So what Fedora does, it just does not build the TokuDB engine against jemalloc. It seems to work fine, but…

Fedora is NOT enterprise Linux, and the environments where TokuDB is a beneficial engine - write-intensive high-performance environments - they are unlikely to be using Fedora. Enterprise database solutions that charge their customers lots of money, such as Percona Server, when they use TokuDB it seems to always have jemalloc support.

I have to conclude that “works in Fedora” without jemalloc does not mean it would work well in the environments where TokuDB is actually beneficial.

So since LibreLAMP only produces packages for x86_64 where libjemalloc.so.1 does work well, I build the TokuDB engine to link against it.

Note that it is just a memory allocator, if for whatever reason you switch to a build of MariaDB where TokuDB is not linked against jemalloc, your database itself will be fine.

Future Proofing

My suspicion is that within a year or so, the necessary code changes to the TokuDB engine in MariaDB will include proper support for the new API provided in libjemalloc.so.2 and tests will no longer fail. Since newer versions of jemalloc work better on a wide variety of hardware platforms, I suspect that is where the future of TokuDB in MariaDB lies.

As such, I already package that library for LibreLAMP so that when the code does catch up, MariaDB packaged for LibreLAMP will make use of it.

Cracklib Plugin

Previous builds of MariaDB for LibreLAMP and the CentOS builds of MariaDB do not include the cracklib plugin.

I decided to build it. If you want to enable it, edit the file /etc/my.cnf.d/cracklib_password_check.cnf and un-comment the line for loading it.

If you have a lot of users, e.g. you offer WordPress hosting accounts, you probably should enable it.