XCode

• Install Xcode from Apple (free registration required):or from your Mac OS X installation disk (macports needs XCode >= 3.1, so if you do not have that version or greater you will need to download the latest version, which is 900+ MB)

You can install the necessary dependencies using either MacPorts or Homebrew.

Using MacPorts

• Download and install the MacPorts dmg image from www.macports.org

• After installing, update it from the terminal: sudo port -v selfupdate

sudo port install cmake jemalloc judy openssl boost gnutls

Using Homebrew

• Download and install Homebrew from https://brew.sh

brew install cmake jemalloc traildb/judy/judy openssl boost gnutls

Your Mac should now have everything it needs to get, compile, and otherwise work with the MariaDB source code. The next step is to actually get a copy of the code. For help with this see the Getting the MariaDB Source Code page.

When building with Mac, you'll need -DOPENSSL_ROOT_DIR=/usr/local/openssl passed as a cmake argument to build against openssl correctly.

_{This page is licensed: CC BY-SA / Gnu FDL}

MariaDB is in Gentoo, so the steps to build it are:

1. Synchronize your tree with

   Copy

   emerge --sync

2. Build MariaDB using

   Copy

   emerge mariadb

_{This page is licensed: CC BY-SA / Gnu FDL}

Build Requirements

To build MariaDB you need the following:

• Visual C++: We currently support Visual Studio 2019 and 2022. Generally we try to support the two most recent VS versions, but build ourselves using the last one. Community editions will work fine; we only use them in our builds. While installing Visual Studio, make sure to add "Desktop Development with C++". Also, make sure to use recent enough Windows SDK - latest Windows 11 SDK is recommended.

• CMake: We recommend the latest release. Older releases might not support your version of Visual Studio. Visual Studio 2019 requires cmake 3.14 at least.

• Git: Required to build newer versions from the source tree.

  • NOTE: run

git config --global core.autocrlf input

after the installation, otherwise some mtr tests will fail

In the "Adjusting your PATH" dialog, choose "Use Git from Windows command prompt", otherwise wrong (mingw64) git and perl will be in your PATH

• Bison from GnuWin32: Bison creates parts of the SQL parser. Choose "Complete package except sources" when downloading.

  • NOTE: Do not install this into your default path with spaces (e.g. under C:\Program Files\GnuWin32); the build will break due to this bison bug. Instead, install into C:\GnuWin32.

  • Add C:\GnuWin32\bin to your system PATH after installation.

• Strawberry perl: Used to run the test suite.ActiveState Perl is another Win32 Perl distribution and should work as well (but it is not as well tested). NOTE: Cygwin or mingw Perl versions will not work for testing. Use Windows native Perl, please.

• Optional: If you intend to build the MSI packages, install Windows Installer XML . If you build MSI with 10.4, also modify your Visual Studio installation, add "Redistributable MSMs" (see MDEV-22555)

• Gnu Diff, needed if you run mysql-test-run.pl tests.

Verify that bison.exe, or git.exe, cmake.exe and perl.exe can be found in the PATH environment variable with "where bison", "where git", "where perl" etc. from the command line prompt.

Building Windows Binaries

The above instructions assume MariaDB 10.2 or higher.

Branch the MariaDB repository, or unpack the source archive. On the command prompt, switch to your source directory, then execute:

mkdir bld
cd bld
cmake ..
cmake --build . --config RelWithDebInfo

The above example builds a release configured for 64 bit systems in a subdirectory named bld. "cmake ..." is the configuration step, "cmake --build . --config Relwithdebinfo" is the build step.

Build Variations

Debug Builds

Building Debug version is done with:

cmake --build . --config Debug

32bit and 64 bit Builds

Build 64 bit binary

Visual Studio 2019-2022 cmake generator will use host architecture by default, that is, with the steps above, cmake will build x64 binaries on x64 machine.

Build 32 bit binary

pass -A Win32 parameter for cMake, like this

cmake .. -A Win32

Historical note: With Visual Studio 2017 and earlier, one had to pass the name of 32bit generator ,e.g cmake .. -G "Visual Studio 15 2017

For a complete list of available generators, call cmake without any parameters.

IDE Builds

Instead of calling "cmake --build" as above, open solution file MariaDB.sln (in older versions, prior to 11.0, MySQL.sln ). When Visual Studio starts, choose Build/Compile.

Building the ZIP Package

cmake --build . --config relwithdebinfo --target package

This is how it is "done by the book", standard cmake target.

MariaDB however uses non-standard target win_package for the packaging for its releases, it generates 2 ZIPs, a slim one with executables, and another one with debuginfo (.PDB files). The debuginfo is important to be able to debug released binaries, and to analyze crashes.

cmake --build . --config relwithdebinfo --target win_package

Building the MSI Package

cmake --build . --config relwithdebinfo 
cmake --build . --config relwithdebinfo --target MSI

Including HeidiSQL in the MSI Installer

Starting with MariaDB 5.2.7, it is possible to build an installer which includes 3rd party products, as described in MWL#200. Currently only HeidiSQL support is implemented; it is also included in the official builds. Use the CMake parameter-DWITH_THIRD_PARTY=HeidiSQL to include it in the installer.

Code Signing

MariaDB builds optionally support authenticode code signing with an optional parameter SIGNCODE. Use cmake -DSIGNCODE=1 during the configuration step to sign the binaries in the ZIP and MSI packages.

Important: for SIGNCODE=1 to work, the user that runs the build needs to install a valid authenticode digital certificate into their certificate store, otherwise the packaging step will fail.

Building Packages for MariaDB Releases

The full script to create the release in an out-of-source build with Visual Studio with signed binaries might look like:

mkdir bld
cd bld
cmake .. -DSIGNCODE=1 -DWITH_THIRD_PARTY=HeidiSQL
cmake --build . --config relwithdebinfo --target win_package
cmake --build . --config relwithdebinfo  --target MSI

This command sequence will produce a ZIP package (e.g mariadb-5.2.6-win32.zip) and MSI package (e.g mariadb-5.2.6-win32.msi) in the bld directory.

Running Tests

• Important: Do not use Cygwin bash, MinGW bash, Git bash, WSL bash, or any other bash when running the test suite. You will then very likely use the wrong version of Perl too (a "Unix-flavoured" one on Windows), and spend a lot of time trying to figure out why this version of Perl does not work for the test suite. Use native perl, in cmd.exe , or powershell instead,

• Switch mysql-test subdirectory of the build directory

cd C:\server\bld\mysql-test

• Run the test suite

perl mysql-test-run.pl --suite=main --parallel=auto

Running a Test Under Debugger

Assuming VS is installed on the machine

perl mysql-test-run.pl  <test_name> --vsjitdebugger

If vsjitdebugger does not start, you can edit AeDebug registry key as mentioned in

debug-using-the-just-in-time-debugger?view=vs-2019#jit_errors

Alternatively:

perl mysql-test-run.pl  <test_name> --devenv

(devenv.exe needs to be in PATH)

or, if you prefer WinDBG

perl mysql-test-run.pl  <test_name> --windbg

_{This page is licensed: CC BY-SA / Gnu FDL}

Below are instructions for creating your own Debian repository. The instructions are based on repository-howto.en.html

REPO_DIR={pick some location}
mkdir $REPO_DIR
mkdir $REPO_DIR/binary
mkdir $REPO_DIR/source
cp *.deb *.ddeb $REPO_DIR/binary
cd $REPO_DIR
dpkg-scanpackages binary  /dev/null | gzip -9c > binary/Packages.gz
dpkg-scansources  source  /dev/null | gzip -9c > source/Sources.gz

Using the Debian repository you just created

One needs to add a new file to the /etc/apt/sources.list.d/ directory. For instance a new file called mariadb.list

# sergey's MariaDB repository
#
deb file:///home/psergey/testrepo binary/
deb-src file:///home/psergey/testrepo source/

after which one can run

apt-get update  # Let apt learn about the new repository
apt-get install mariadb-server

and collect bugs :-).

apt-get install will spray output of scripts and servers all over /var/log. It is also possible to set DEBIAN_SCRIPT_DEBUG=1 to get some (not all) of it to stdout.

Cleaning up after failed installation

Run

dpkg --get-selections | grep mariadb
dpkg --get-selections | grep mysql

to see what is installed, and then

dpkg --purge <packages>

until the former produces empty output. Note: after some failures, /etc/mysql and /var/lib/mysql are not cleaned and still need to be removed manually.

_{This page is licensed: CC BY-SA / Gnu FDL}

How to create a source tar.gz file.

First Setup your build environment.

Then use automake/configure/make to generate the tar file:

BUILD/autorun.sh
./configure --with-plugin-xtradb
make dist

This creates a source file with a name like mysql-5.3.2-MariaDB-beta.tar.gz

See also the generic build instructions.

_{This page is licensed: CC BY-SA / Gnu FDL}

Required Tools

The following is a list of tools that are required for building MariaDB on Linux and Mac OS X. Most, if not all, of these will exist as packages in your distribution's package repositories, so check there first. See Building MariaDB on Ubuntu, Building MariaDB on CentOS, and Building MariaDB on Gentoo pages for specific requirements for those platforms.

• git

• gzip

• tar

• gcc/g++ 4.8.5 or later, recommend above 9 or clang/clang++

• GNU make 3.75 or later or Ninja

• bison (3.0)

• libncurses or libncurses6

• zlib-dev or zlib-devel

• libevent-dev or libevent-devel

• cmake above 2.8.7 though preferably above 3.3

• gnutls or openssl

• jemalloc (optional)

• snappy (compression library, optional)

• valgrind (only needed if running mysql-test-run --valgrind)

• libcurl (only needed if you want to use the S3 storage engine)

• libxml2-devel or libxml-dev

• boost

• libaio-devel or libaio-dev

• systemd-devel or systemd-dev

• pcre2-devel (optiona, will be automatically downloaded and installed if not on the system)

• ccache ; Will speed up builds if you are going to use the scripts in the BUILD directory.

• ctags or universal-ctags ; If you plan to use BUILD scripts and local editors

You can install these programs individually through your package manager.

In addition, some package managers support the use a build dependency command. When using this command, the package manager retrieves a list of build dependencies and install them for you, making it much easier to get started on the compile. The actual option varies, depending on the distribution you use.

On Ubuntu and Debian you can use the build-dep command.

# apt build-dep mariadb-server

Fedora uses the builddep command with DNF.

# dnf builddep mariadb-server

If building on Centos 7, use the building MariaDB on Centos instructions.

With openSUSE and SUSE, you can use the source-install command.

# zypper source-install -d mariadb

Each of these commands works off of the release of MariaDB provided in the official software repositories of the given distribution. In some instances and especially in older versions of Linux, MariaDB may not be available in the official repositories. In these cases you can use the MariaDB repositories as an alternative.

Bear in mind, the release of MariaDB provided by your distribution may not be the same as the version you are trying to install. Additionally, the package managers don't always retrieve all of the packages you need to compile MariaDB. There may be some missed or unlisted in the process. When this is the case, CMake fails during checks with an error message telling you what's missing.

Note: On Debian-based distributions, you may receive a "You must put some 'source' URIs in your sources.list" error. To avoid this, ensure that /etc/apt/sources.list contains the source repositories.

For example, for Debian buster:

deb http://ftp.debian.org/debian buster main contrib
deb http://security.debian.org buster/updates main contrib
deb-src http://ftp.debian.org/debian buster main contrib
deb-src  http://security.debian.org buster/updates main contrib

Refer to the documentation for your Linux distribution for how to do this on your system.

After editing the sources.list, do:

sudo apt update

...and then the above mentioned build-dep command.

Note: On openSUSE the source package repository may be disabled. The following command will enable it:

sudo zypper mr -er repo-source

After enabling it, you will be able to run the zypper command to install the build dependencies.

You should now have your build environment set up and can proceed to Getting the MariaDB Source Code and then using the Generic Build Instructions to build MariadB (or following the steps for your Linux distribution or Creating a MariaDB Binary Tarball).

See Also

• Installing Galera from source

_{This page is licensed: CC BY-SA / Gnu FDL}

For some distributions you can build MariaDB from a source RPM. (See also Why Source RPMs (SRPMs) Aren't Packaged For Some Platforms).

You can build it as follows:

using dnf

On RHEL8 you might need to start with:

sudo dnf config-manager --set-enabled codeready-builder-beta-for-rhel-8-x86_64-rpms

Then, on all dnf distributions:

sudo dnf install rpm-build perl-generators
    dnf download --source MariaDB
    sudo dnf builddep MariaDB-*.src.rpm
    rpmbuild --rebuild MariaDB-*.src.rpm

using yum

sudo yum install rpm-build yum-utils
    yumdownloader --source MariaDB
    sudo yum-builddep MariaDB-*.src.rpm
    rpmbuild --rebuild MariaDB-*.src.rpm

using zypper

sudo zypper in rpm-build
    sudo zypper si MariaDB
    sudo rpmbuild -bb /usr/src/packages/SPECS/MariaDB.spec

Or (to avoid building as root):

sudo zypper in rpm-build
    sudo zypper si -d MariaDB
    zypper --pkg-cache-dir=`pwd` si --download-only MariaDB
    rpmbuild --rebuild mariadb/srpms/MariaDB-*.src.rpm

_{This page is licensed: CC BY-SA / Gnu FDL}

Instructions on compiling MariaDB on musl-based operating systems (Alpine)

The instructions on this page will help you compile MariaDB from source. Links to more complete instructions for specific platforms can be found on the source page.

• First, get a copy of the MariaDB source.

• Next, prepare your system to be able to compile the source.

Using cmake

MariaDB 10.1 and above is compiled using cmake. You can configure your build simply by running cmake using special option, i.e.

cmake . -DWITHOUT_TOKUDB=1

To build and install MariaDB after running cmake use

make
sudo make install

Note that building with MariaDB this way will disable tokuDB, till tokuDB becomes fully supported on musl.

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system Debian or any of its direct derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB source repository for the release that interests you. For Ubuntu and its derivatives, see Building on Ubuntu.

Before you begin, install the software-properties-common and devscripts packages:

$ sudo apt-get install -y software-properties-common \
      devscripts

Installing Build Dependencies

MariaDB requires a number of packages to compile from source. Fortunately, you can use the MariaDB repositories to retrieve the necessary code for the version you want. Use the Repository Configuration tool to determine how to set up the MariaDB repository for your release of Debian, the version of MariaDB that you want to install, and the mirror that you want to use.

First add the authentication key for the repository, then add the repository.

$ sudo apt-key adv --recv-keys \
      --keyserver hkp://keyserver.ubuntu.com:80 \
      0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.3/debian stretch main'

The second command added text to the /etc/apt/sources.list file. One of these lines is the repository containing binary packages for MariaDB, the other contains the source packages. The line for the source packages is commented out by default. This can be scripted:

sed -e '/^# deb-src.*mariadb/s/^# //' -i /etc/apt/sources.list

Alternately, open the file using your preferred text editor and uncomment the source repository.

$ sudo vim /etc/apt/sources.list

...
deb [arch=amd64] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.3/debian stretch main
deb-src [arch=amd64] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.3/debian stretch main

Once the repository is set up, you can use apt-get to retrieve the build dependencies. MariaDB packages supplied by Ubuntu and packages supplied by the MariaDB repository have the same base name of mariadb-server. You need to specify the specific version you want to retrieve.

$ sudo apt-get update
$ sudo apt-get build-dep -y mariadb-server-10.3

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

$ git clone --branch 10.3 https://github.com/MariaDB/server.git

The source code includes scripts to install the remaining build dependencies. For Ubuntu, they're located in the debian/ directory. Navigate into the repository and run the autobake-deb.sh script. Then use

$ export DEB_BUILD_OPTIONS=parallel=$(nproc)
$ cd server/
$ ./debian/autobake-deb.sh

After Building

After building the packages, it is a good idea to put them in a repository. See the Creating a Debian Repository page for instructions.

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system Fedora or any of its derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB build in the official repositories.

Installing Build Dependencies

MariaDB requires a number of packages to compile from source. Fortunately, you can use the package in the Fedora repository to retrieve most of the relevant build dependencies through DNF.

# dnf builddep mariadb-server

Running DNF in this way pulls the build dependencies for the release of MariaDB compiled by your version of Fedora. These may not be all the dependencies you need to build the particular version of MariaDB you want to use, but it will retrieve most of them.

You'll also need to install Git to retrieve the source repository:

# dnf install git

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

$ git clone --branch 10.3 https://github.com/MariaDB/server.git mariadb-server

With the source repository cloned onto your system, you can start building MariaDB. Change into the new mariadb-server/ directory and run CMake to prepare the build.

$ mkdir mariadb-build
$ cd mariadb-build
$ cmake -DRPM=fedora ../mariadb-server

Once CMake readies the relevant Makefile for your system, use Make to build MariaDB.

$ make package

_{This page is licensed: CC BY-SA / Gnu FDL}

It is relatively straightforward to build MariaDB from source on FreeBSD. When working with an individual host, you can use Ports to compile particular or multiple versions of MariaDB. When working with multiple hosts, you can use Poudriere to build MariaDB once, then serve it as a package to multiple FreeBSD hosts.

Using Ports

The FreeBSD Ports Collection provides a series of Makefiles that you can use to retrieve source code, configure builds, install dependencies and compile software. This allows you to use more advanced releases than what is normally available through the package managers as well as enable any additional features that interest you.

In the event that you have not used Ports before on your system, you need to first fetch and extract the Ports tree. This downloads the Ports tree from FreeBSD and extracts it onto your system, placing the various Makefiles, patches and so on in the /usr/ports/ directory.

# portsnap fetch extract

In the event that you have used Ports before on this system, run Portsnap again to download and install any updates to the Ports tree.

# portsnap fetch update

This ensures that you are using the most up to date release of the Ports tree that is available on your system.

Building MariaDB from Ports

Once Portsnap has installed or updated your Ports tree, you can change into the relevant directory and install MariaDB. Ports for MariaDB are located in the /usr/ports/databases/ directory.

$ ls /usr/ports/databases | grep mariadb

mariadb-connector-c
mariadb-connector-odbc
mariadb100-client
mariadb100-server
mariadb101-client
mariadb101-server
mariadb102-client
mariadb102-server
mariadb103-client
mariadb103-server
mariadb55-client
mariadb55-server

Note that FreeBSD treats the Server and Client as separate packages. The Client is a dependency of the Server, so you only need to build the Server to get both. It also provides a number of different versions. You can search the available ports from Fresh Ports. Decide what version of MariaDB you want to install, the change into the relevant directory. Once in the directory, run Make to build MariaDB.

# cd /usr/ports/databases/mariadb103-server
# make

In addition to downloading and building MariaDB, Ports also downloads and build any libraries on which MariaDB depends. Each port it builds will take you to a GUI window where you can select various build options. In the case of MariaDB, this includes various storage engines and specific features you need in your build.

Once you finish building the ports, install MariaDB on your system and clean the directory to free up disk space.

# make install clean

This installs FreeBSD on your server. You can now enable, configure and start the service as you normally would after installing MariaDB from a package.

Using Poudriere

Poudriere is a utility for building FreeBSD packages. It allows you to build MariaDB from a FreeBSD Jail, then serve it as a binary package to other FreeBSD hosts. You may find this is particularly useful when building to deploy multiple MariaDB servers on FreeBSD, such as with Galera Cluster or similar deployments.

Building MariaDB

Once you've configured your host to use Jails and Poudriere, initialize a jail to use in building packages and a jail for managing ports.

# poudriere jail -c -j package-builder -v 11.2-RELEASE
# poudriere ports -c -p local-ports

This creates two jails, package-builder and local-ports, which you can then use to build MariaDB. Create a text file to define the packages you want to build. Poudriere will build these packages as well as their dependencies. MariaDB is located at databases/mariadb103-server. Adjust the path to match the version you want to install.

$ vi maraidb-package-builder.txt

databases/mariadb103-server

Use the options command to initialize the build options for the packages you want Poudriere to compile.

# poudriere options -j package-builder -p local-ports -z mariadb-builder -f mariadb-package-builder.txt

Lastly, use the bulk command to compile the packages.

# poudriere bulk -j package-builder -p local-ports -z mariadb-builder -f mariadb-package-builder.txt

Using Poudriere Repositories

In order to use Poudriere, you need to set up and configure a web server, such as Nginx or Apache to serve the directory that Poudriere built. For instance, in the case of the above example, you would map to the package-builder jail: /usr/local/poudriere/data/packages/package-builder/.

You may find it useful to map this directory to a sub-domain, for instance httpspkg.example.com or something similar.

Lastly, you need to configure the FreeBSD hosts to use the Poudriere repository you just created. On each host, disable the FreeBSD official repositories and enable your Poudriere repository as an alternative.

# vi /usr/local/etc/pkg/repos/FreeBSD.conf

FreeBSD: {
      enabled: no
}

Then add the URL for your Poudriere repository to configuration file:

# vi /usr/local/etc/pkg/repos/mariadb.conf

custom: {
      url: "https://pkg.example.com",
      enabled: yes
}

You can then install MariaDB from Poudriere using the package manager.

# pkg install mariadb103-server

_{This page is licensed: CC BY-SA / Gnu FDL}

The following two articles should help you get your Solaris machine prepared to build MariaDB (just ignore the parts about installing buildbot):

• Buildbot Setup for Solaris Sparc

• Buildbot Setup for Solaris x86

Notes

• The BUILD dir contains various scripts for compiling MariaDB on Solaris. The BUILD/compile-solaris-amd64 and BUILD/compile-solaris-amd64-debug are probably the most useful.

• The scripts do not play nice with non-bash shells such as the Korn Shell (ksh). So if your /bin/sh is pointing at ksh or ksh93, you'll want to change it so that it points at bash.

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system Ubuntu or any of its derivatives and would like to compile MariaDB from source code, you can do so using the MariaDB source repository for the release that interests you.

Before you begin, install the software-properties-common, devscripts and equivs packages.

$ sudo apt-get install software-properties-common \
      devscripts \
      equivs

Installing Build Dependencies

MariaDB requires a number of packages to compile from source. Fortunately, you can use the MariaDB repositories to retrieve the necessary code for the version you want. Use the Repository Configuration tool to determine how to set up the MariaDB repository for your release of Ubuntu, the version of MariaDB that you want to install, and the mirror that you want to use.

First add the authentication key for the repository, then add the repository.

$ sudo apt-key adv --recv-keys \
      --keyserver hkp://keyserver.ubuntu.com:80 \
      0xF1656F24C74CD1D8
$ sudo add-apt-repository --update --yes --enable-source \
       'deb [arch=amd64] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu '$(lsb_release -sc)' main'

Once the repository is set up, you can use apt-get to retrieve the build dependencies. MariaDB packages supplied by Ubuntu and packages supplied by the MariaDB repository have the same base name of mariadb-server. You need to specify the specific version you want to retrieve.

$ sudo apt-get build-dep mariadb-10.3

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

$ git clone --branch 10.3 https://github.com/MariaDB/server.git

The source code includes scripts to install the remaining build dependencies. For Ubuntu, they're located in the debian/ directory. Navigate into the repository and run the autobake-deb.sh script. Then use

$ cd server/
$ ./debian/autobake-deb.sh

Further Dependencies

In the event that there are still build dependencies that are not satisfied, use mk-build-deps to generate a build dependency deb to use in installing the remaining packages.

$ mk-build-deps debian/control
$ apt-get install ./mariadb-*build-deps_*.deb

Then, call the autobake-deb.sh script again to build MariaDB.

$ ./debian/autobake-deb.sh

After Building

After building the packages, it is a good idea to put them in a repository. See the Creating a Debian Repository page for instructions.

_{This page is licensed: CC BY-SA / Gnu FDL}

To generate RPM packages from the build, supply the -DRPM=xxx flag to CMake, where the value xxx is the name of the distribution you're building for. For example, centos7 or rocky8 or fedora39 or sles15.

What these do are controlled in the following CMake files:

• cmake/cpack_rpm.cmake

• cmake/build_configurations/mysql_release.cmake

• cmake/mariadb_connector_c.cmake

To build the packages you should execute:

$ umask 0022
$ cmake --build . --target package

See Also

• About the MariaDB RPM Files

• Building MariaDB on CentOS

• Installing MariaDB RPM Files

• MariaDB RPM Packages

_{This page is licensed: CC BY-SA / Gnu FDL}

What are Sanitizers?

Sanitizers are open source runtime error detectors developed by Google that are enabled during the compile step. These sanitizers add extra code during compilation that will throw exceptions when certain errors are detected.

Sanitizers find server bugs bug instrumenting the runtime MariaDB during compile time, and performing runtime checks on the executed test. Sanitizers detect a variety of implementation defects:

The sanitizers for clang are:

• AddressSanitizer (aka ASAN)

• UndefinedBehaviourSanitizer (aka UBSAN)

• ThreadSanitizer (aka TSAN)

• MemorySanitizer (aka MSAN)

How to Compile MariaDB with Sanitizers

Before using ASAN locally, please ensure that it is installed on the system:

You can use one of the two following build commands:

cmake  -DWITH_ASAN=ON /source

Additionally, UBSAN, TSAN, and MSAN can be enabled in a similar way:

UBSAN:

cmake -DWITH_UBSAN=ON /source

TSAN:

cmake -DWITH_TSAN=ON /source

MSAN:

cmake -DWITH_MSAN=ON /source

Important to note MSAN requires instrumented c++ and system libraries to have a functioning build per container guide below.

Buildbot's MSAN container

The time consuming aspect of building with MSAN is having instrumented system libraries. To help with this MariaDB Foundation has built the MSAN container for buildbot, but this is reusable locally.

The MariaDB Buildbot MSAN container, quay.io/mariadb-foundation/bb-worker/debian12-msan-clang-20 a container with:

• the instrumented libraries required for MSAN

• a very modern clang version

• the latest stable Debian as a base image

• a compiled rr for debugging

The build of this container isn't hard coded to MSAN so it can be used for:

• A general Debian build container

• Using the gcc/g++ of Debian (by removing the CC and CXX environment variables

• Compiling with a latest clang

• Compiling with the ASAN/UBSAN feature available in the latest clang

Running the MSAN container

First, run the container where your current directory is the source directory:

podman run -v $PWD:/source:z \
  --rm \
  -ti \
  --entrypoint bash \
  --mount=type=tmpfs,tmpfs-size=10G,dst=/build \
  --workdir /build \
   quay.io/mariadb-foundation/bb-worker:debian12-msan-clang-20

The /build options for docker are slighly different as they default to noexec and a root ownership by default.

docker run -v $PWD:/source:z \
  --rm \
  -ti \
  --entrypoint bash \
  --tmpfs /build:size=10G,exec,uid=1000 \
  --workdir /build \
  quay.io/mariadb-foundation/bb-worker:debian12-msan-clang-20

The purposes of these, and other options include:

Notes:

• docker can be used instead of the lighter weight podman if you so desired.

• /dev/shm is mounted no-exec so it rr recording here cannot be replayed while in that location

• optionally can make /build a filesystem mount to preserve the build.

There are environment variables that affect the cmake configure options and mtr are:

CXX=clang++
CC=clang
MSAN_LIBDIR=/msan-libs
CMAKE_GENERATOR=Ninja
MSAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-20
WSREP_PROVIDER=/usr/lib/galera/libgalera_smm.so
MTR_PARALLEL=auto
ASAN_OPTIONS=quarantine_size_mb=512:atexit=0:detect_invalid_pointer_pairs=3:dump_instruction_bytes=1:allocator_may_return_null=1
UBSAN_OPTIONS=print_stacktrace=1:report_error_type=1
MSAN_OPTIONS=abort_on_error=1:poison_in_dtor=0

Note: galera WSREP_PROVIDER isn't instrumented with any sanitizer

Check the latest version of these running env.

Running an MSAN Build

Once you have started the MSAN container this is how you perform a MSAN build.

The time consuming aspect of building with MSAN is having instrumented system libraries.

All the following instructions are executed within the container - there is a document in /etc/motd that contains the latest information. Start by running the configure stage of cmake:

cmake \
      -DUPDATE_SUBMODULES=OFF \
      -DWITH_MSAN=ON  \
      -DCMAKE_{EXE,MODULE}_LINKER_FLAGS="-L${MSAN_LIBDIR} -Wl,-rpath=${MSAN_LIBDIR}" \
      -DHAVE_CXX_NEW=1  \
      -DWITH_INNODB_{BZIP2,LZ4,LZMA,LZO,SNAPPY}=OFF \
      -DWITH_ZLIB=bundled  \
      -DWITH_NUMA=NO  \
      -DWITH_SYSTEMD=NO \
      -DHAVE_LIBAIO_H=0    \
      -DCMAKE_DISABLE_FIND_PACKAGE_{URING,LIBAIO}=1  \
      -DPLUGIN_{MROONGA,ROCKSDB,OQGRAPH}=NO  \
      -DWITH_EMBEDDED_SERVER=OFF \
      /source

MSAN is a clang only compile options and other compilers will not work.

Run the build stage:

cmake --build . 

...
[100%] Built target mariadbd
[100%] Linking CXX executable mariadb-backup
Creating mariadb-backup link
[100%] Built target mariadb-backup

As the MSAN has rpath defined in its compile option there is no need for LD_LIBRARY_PATH manipulation.

To run tests:

mysql-test/mtr   (usual mtr options)

As newer versions occur and improvements happen these instructions may change. Look at the execution on the buildbot builder to see if any changes have been made.

Bug Reporting

Use the MSAN in the label when reporting bugs.

Current outstanding MSAN bugs can be found on JIRA by searching for this label.

Running an combined ASAN and UBSAN Build

The clang implemented instrumentation of the MemoryStanitizer (MSAN) conflicts with the AddressSanitizer (ASAN) and UndefinedBehaviour (UBSAN) mechanisms, however ASAN and UBSAN can be combined into the same build.

After starting the MSAN container the following will configure a combined ASAN and UBSAN build:

cmake \
      -DUPDATE_SUBMODULES=OFF \
      -DWITH_ASAN=ON  \
      -DWITH_UBSAN=ON  \
      -DWITH_UNIT_TESTS=OFF \
     /source

Build and test run are standard.

Note: list of unfixed UBSAN issues by MariaDB Corporation Testing.

Bug Reporting

UBSAN bugs are labelled with UBSAN and also the short form of the undefined behaviour.

For example in the following output, the insufficient-object-size would be used as the additional short form of the label.

SUMMARY: UndefinedBehaviorSanitizer: insufficient-object-size /source/sql/item_strfunc.cc:5256:44 
 /source/sql/item_strfunc.cc:5256:44

Likewise for ASAN, should use ASAN as the label with the short form of the ASAN type from the output.

Using RR

In the MSAN container, there is a build version of the latest rr at the time of the container build.

A recording of the execution can be make with the mariadb-test-run.pl option --rr. Or alternately you can execute:

$ rr record sql/mariadbd ......

To replay a recording adjust per the test worker and instance used in the test:

$ rr replay mysql-test/var/log/mysqld.1.rr/mariadbd-0/

Using curl in the container its possible to save up this directory for another user or developer to use with the same container. This can also be shared with our public ftp server for assistance diagnosing validating a bug report.

ASAN Options

To run mariadbd with instrumentation you have to set the ASAN_OPTIONS environment variable before starting mariadbd including starting mariadbd when running mtr.

export ASAN_OPTIONS=abort_on_error=1

The above command will abort any instrumented executable if any errors are found, which is good for debugging. If you set abort_on_error=0 all server errors are logged to your error log file (mysqld.err).

To catch errors for other processes than the server, you can set more options, like this:

export ASAN_OPTIONS=abort_on_error=1:log_path=/tmp/asan

If you are seeing an incomplete stack trace for a memory allocation, you may rerun the failing test with

export ASAN_OPTIONS=abort_on_error=1:log_path=/tmp/asan:fast_unwind_on_malloc=0

To get core dumps of failures:

export ASAN_OPTIONS=abort_on_error=1:disable_coredump=0

To see all the options (or to check if an executable is instrumented), you may try the following:

ASAN_OPTIONS=help=1 extra/perror 0

Using Valgrind

The MariaDB test system can use Valgrind for finding memory leaks and wrong memory accesses. Valgrind is an instrumentation framework for building dynamic analysis tools. If Valgrind is installed on your system, you can simply use mysql-test-run --valgrind to run the test under Valgrind.

See Also

• Compiling MariaDB for debugging

_{This page is licensed: CC BY-SA / Gnu FDL}

All CMake configuration options for MariaDB can be displayed with:

cmake . -LH

See Also

• Get the Code, Build it, Test it (mariadb.org)

• Generic Build Instructions

_{This page is licensed: CC BY-SA / Gnu FDL}

From MariaDB 10.2, MariaDB uses InnoDB as the default storage engine. Before MariaDB 10.2, MariaDB came by default with XtraDB, an enhanced version of the InnoDB plugin that comes from Oracle.

If you want to use Oracle's InnoDB plugin, then you need to compile MariaDB andnot specify --without-plugin-innodb_plugin when configuring. For example, a simple ./configure without any options will do.

When the InnoDB plugin is compiled, the innodb_plugin test suite will test the InnoDB plugin in addition to xtradb:

./mysql-test-run --suite=innodb_plugin

To use the innodb_plugin instead of xtradb you can do (for MariaDB 5.5):

mysqld --ignore-builtin-innodb --plugin-load=innodb=ha_innodb.so \
--plugin_dir=/usr/local/mysql/lib/mysql/plugin

See Also

replacing-builtin-innodb.html

_{This page is licensed: CC BY-SA / Gnu FDL}

How to generate binary tar.gz files.

• Setup your build environment.

• Build binaries with your preferred options/plugins.

If the binaries are already built, you can generate a binary tarball with

make package

Prior to MariaDB 5.5, the following steps were required:

• Use make_binary_distribution to generate a binary tar file:

cd mariadb-source
./scripts/make_binary_distribution

This creates a source file with a name like mariadb-5.3.2-MariaDB-beta-linux-x86_64.tar.gz in your current directory.

The other option is to use the bakery scripts. In this case you don't have to compile MariaDB source first.

cd $PACKAGING_WORK
bakery/preheat.sh
cd bakery_{number}
bakery/tarbake51.sh last:1 $MARIA_WORK
bakery/autobake51-bintar.sh mariadb-{version_num}-maria-beta-ourdelta{number}.tar.gz

_{This page is licensed: CC BY-SA / Gnu FDL}

Buildroot

Buildroot is a way to cross compile MariaDB and other packages into a root filesystem. In the menuconfig you need to enable "Enable C++ Support" first under "Toolchain". After C++ is enabled MariaDB is an option under "Target Packages" ->"Libraries" -> "Databases" -> "mysql support" -> "mysql variant" -> "mariadb". Also enable the "mariadb server" below the "mysql support" option.

Details

To cross-compile with cmake you will need a toolchain file. See, for example, here. Besides cmake specific variables it should have, at least

SET(STACK_DIRECTION -1)
  SET(HAVE_IB_GCC_ATOMIC_BUILTINS 1)

with appropriate values for your target architecture. Normally these MariaDB configuration settings are detected by running a small test program, and it cannot be done when cross-compiling.

Note that during the build few helper tools are compiled and then immediately used to generate more source files for this very build. When cross-compiling these tools naturally should be built for the host architecture, not for the target architecture. Do it like this (assuming you're in the mariadb source tree):

$ mkdir host
$ cd host
$ cmake ..
$ make import_executables
$ cd ..

Now the helpers are built and you can cross-compile:

$ mkdir target
$ cd target
$ cmake .. -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/file.cmake -DIMPORT_EXECUTABLES=../host/import_executables.cmake
$ make

Here you invoke cmake, specifying the path to your toolchain file and the path to the import_executables.cmake that you have just built on the previous step. Of course, you can also specify any other cmake parameters that could be necessary for this build, for example, enable or disable specific storage engines.

See also msg02911.html

_{This page is licensed: CC BY-SA / Gnu FDL}

The instructions on this page will help you compile MariaDB from source. Links to more complete instructions for specific platforms can be found on the source page.

First, get a copy of the MariaDB source.

Next, prepare your system to be able to compile the source.

If you don't want to run MariaDB as yourself, then you should create a mysql user. The example below uses this user.

Using cmake

MariaDB 5.5 and above is compiled using cmake.

It is recommended to create a build directory beside your source directory

mkdir build-mariadb
cd build-mariadb

In the base repository run:

git clean -xffd && git submodule foreach --recursive git clean -xffd

You can configure your build simply by running cmake without any special options, like

cmake ../server

where server is where you installed MariaDB. If you are building in the source directory, just omit ../server.

If you want it to be configured exactly as a normal MariaDB server release is built, use

cmake ../server -DBUILD_CONFIG=mysql_release

This will configure the build to generate binary tarballs similar to release tarballs from downloads.mariadb.org. Unfortunately this doesn't work on old platforms, like OpenSuse Leap 15.0, because MariaDB binary tarballs are built to minimize external dependencies, and that needs static libraries that might not be provided by the platform by default, and would need to be installed manually.

To do a build suitable for debugging use:

cmake ../server -DCMAKE_BUILD_TYPE=Debug

By default, MariaDB is compiled with the -Werror flag, which causes compiling to abort if there is a compiler warning. You can disable that by configuring with-DMYSQL_MAINTAINER_MODE=OFF.

cmake ../server -DCMAKE_BUILD_TYPE=Debug -DMYSQL_MAINTAINER_MODE=OFF.

All cmake configuration options for MariaDB can be displayed with:

cmake ../server -LH

To build and install MariaDB after running cmake use

cmake --build .
sudo cmake --install .

If the commands above fail, you can enable more compilation information by doing:

cmake --build . --verbose

If you want to generate a binary tarball, run

cpack

Using BUILD Scripts

There are also BUILD scripts for the most common systems for those that doesn't want to dig into cmake options. These are optimized for in source builds.

The scripts are of type compile-#cpu#-how_to_build. Some common scripts:

Some common suffixes used for the scripts:

All BUILD scripts support the following options:

A typical compilation used by a developer would be:

shell> ./BUILD/compile-pentium64-debug

This configures the source for debugging and runs make. The server binary will be sql/mariadbd or sql/mysqld.

Starting MariaDB for the First Time

After installing MariaDB (using sudo make install), but prior to starting MariaDB for the first time, one should:

1. Ensure the directory where you want MariaDB to store it's data is owned by the mariadb user (if the user doesn't exist, you'll need to create it)

2. Create a MariaDB configuration config file (/.my.cnf or /etc/my.cnf) with the configuration options you desire. A suggested minimum configuration file, to specify where you want your data to be stored, would be:

   Copy

   [mariadbd]
   datadir=/usr/local/mariadb/data/

3. run the mariadb-install-db script to generate the needed system tables

# The following assumes that the 'mariadb' user exists and that we installed MariaDB
# in /usr/local/mariadb
chown -R mariadb /usr/local/mariadb/
cd /usr/local/mariadb/
./scripts/mariadb-install-db --user=mariadb
/usr/local/mariadb/bin/mariadb-safe --user=mariadb &

If needed, you can also use the --datadir=/usr/local/mariadb/data/ options with mariadbd-install-db and mariadbd-safe

Testing MariaDB

If you want to test your compiled MariaDB, you can do either of:

Run unit tests:

cmake --build . --target test

Or run mtr tests:

mysql-test/mysql-test-run --force

Each of the above are run from the build directory. There is no need to 'make install/cmake --install .' MariaDB prior to running them.

Increasing Version Number or Tagging a Version

If you have made code changes and want to increase the version number or tag our version with a specific tag you can do this by editing the VERSION file. Tags are shown when running the 'mariadbd --version' command.

Non-ascii Symbols

MariaDB builds with readline; using an alternative such as Editline may result in problems with non-ascii symbols.

Post-install Tasks

• Installing system tables (mariadb-install-db)

• Starting and Stopping MariaDB Automatically

_{This page is licensed: CC BY-SA / Gnu FDL}

The intention of this documentation is show all the steps of getting, building and testing the latest MariaDB server (10.5 at time of writing) from GitHub. Each stage links to the full documentation for that step if you need to find out more.

Install all tools needed to build MariaDB

OpenSuse

sudo zypper install git gcc gcc-c++ make bison ncurses ncurses-devel zlib-devel libevent-devel cmake openssl

Debian

apt install -y build-essential bison libgnutls28-dev
apt build-dep mariadb-server

Set Up git

Fetch and checkout the MariaDB source to a subdirectory of the current directory

git clone https://github.com/MariaDB/server.git mariadb
cd mariadb
git checkout 11.4

Build It

The following command builds a server the same way that is used for building releases. Use cmake . -DCMAKE_BUILD_TYPE=Debug to build for debugging.

cmake . -DBUILD_CONFIG=mysql_release && cmake --build . --parallel=8

Check the Server (If You Want To)

mysql-test/mtr --parallel=8 --force

Install the Default Databases

./scripts/mariadb-install-db --srcdir=.

(Older MariaDB version use mysql_install_db)

Install the Server (If needed)

You can also run and test mariadb directly from the build directory, in which case you can skip the rest of the steps below.

cmake --install .

Start the Server

Start the server in it's own terminal window for testing. Note that the directory depends on your system!

/usr/sbin/mariadbd

_{This page is licensed: CC BY-SA / Gnu FDL}

In the event that you are using the Linux-based operating system CentOS or any of its derivatives, you can optionally compile MariaDB from source code. This is useful in cases where you want use a more advanced release than the one that's available in the official repositories, or when you want to enable certain feature that are not otherwise accessible.

Installing Build Dependencies for MariaDB 5.5

Before you start building MariaDB, you first need to install the build dependencies required to run the compile. CentOS provides a tool for installing build dependencies. The yum-builddep utility reads a package and generates a list of the packages required to build from source, then calls YUM to install them for you. In the event that this utility is not available on your system, you can install it through the yum-utils package. Once you have it, install the MariaDB build dependencies.

yum install yum-utils
yum-builddep mariadb-server

Running the above command installs many of the build dependencies, but it doesn't install all of them. It will only install dependencies for MariaDB 5.5, which is not enough if you want to compile a newer MariaDB version!

Installing Build Dependencies for newer MariaDB versions

The following commands installs all packages needed to get and compile MariaDB 10.11:

yum install git
yum install gcc
yum install gcc-c++
yum install tar make cmake
yum install bison
yum install ncurses-devel
yum install openssl openssl-devel
yum install snappy snappy-devel
yum install valgrind
yum install libcurl-devel
yum install gzip
yum install zlib-devel
yum install lz4-devel
yum install lzo-devel
yum install bzip2-devel
yum install libxml2-devel
yum install libevent-devel
yum install libaio-devel
yum install boost
yum install pcre2-devel
yum install systemd-devel
yum install rpm-build
yum install libaio-devel
yum install zstd
yum install pam-devel
yum install checkpolicy
yum install policycoreutils-python
yum install galera.x86_64

You can replace openssl with gnutls above, depending on the TLS implementation you want to use.

If you plan to use the BUILD scripts to make it easier to build different configurations of MariaDB, then you should also install ccache to speed up your compilations:

yum install ccache

If you want to test the MariaDB installation, with the include mysql-test-run (mtr) system, you also need to install and configure cpan:

yum install cpan
# Complete Perl installing with the next command. Use the default answer to all questions
cpan App::cpanminus

For more information on dependencies, see Linux Build Environment.

Building MariaDB

Once you have the base dependencies installed, you can retrieve the source code and start building MariaDB. The source code is available on GitHub. Use the --branch option to specify the particular version of MariaDB you want to build.

$ git clone --branch 10.11 https://github.com/MariaDB/server.git

With the source repository cloned onto your system, you can start building MariaDB. Run CMake to ready MariaDB for the build,

$ cmake -DRPM=centos7 server/

Once CMake readies the relevant Makefile for your system, use Make to build MariaDB.

$ umask 0022
$ make package

This generates an RPM file, which you can then install on your system or copy over to install on other CentOS hosts. The umask is needed because of a bug in cmake / cmake scripts.

Alternative, use one of the build scripts in the BUILD directory that allows you to compile different versions of MariaDB (debug, optimized, profiling etc).

A good option for developers is:

./BUILD/compile-pentium64-debug

Creating MariaDB-compat package

MariaDB-compat package contains libraries from older MariaDB releases. They cannot be built from the current source tree, so cpack creates them by repackaging old MariaDB-shared packages. If you want to have -compat package created, you need to download MariaDB-shared-5.3 and MariaDB-shared-10.1 rpm packages for your architecture (any minor version will do) and put them one level above the source tree you're building. CMake will pick them up and create a MariaDB-compat package. CMake reports it as

$ ls ../*.rpm
../MariaDB-shared-10.1.17-centos7-x86_64.rpm
../MariaDB-shared-5.3.12-122.el5.x86_64.rpm
$ cmake -DRPM=centos7 .

...
Using ../MariaDB-shared-5.3.12-122.el5.x86_64.rpm to build MariaDB-compat
Using ../MariaDB-shared-10.1.17-centos7-x86_64.rpm to build MariaDB-compat

Additional Dependencies

In the event that you miss a package while installing build dependencies, CMake may continue to fail after you install the necessary packages. If this happens to you, delete the CMake cache then run the above the command again:

$ rm CMakeCache.txt

When CMake runs through the tests again, it should now find the packages it needs, instead of the cache telling it they're unavailable.

More about CMake and CPackRPM

See also building RPM packages from source

_{This page is licensed: CC BY-SA / Gnu FDL}

Sometimes, one needs to have MariaDB compiled with Vanilla XtraDB. This page describes the process to do this. The process is rather crude, as my goal was just a once-off compile for testing (that is, not packaging or shipping) purposes.

The process is applicable to MariaDB 5.3.4 and XtraDB from Percona Server 5.1.61.

wget http://s.petrunia.net/scratch/make-vanilla-xtradb-work-with-mariadb.diff

bzr branch /path/to/mariadb-5.3 5.3-vanilla-xtradb-r3

cd 5.3-vanilla-xtradb-r3/storage/
tar czf innodb_plugin.tgz innodb_plugin/
rm -rf innodb_plugin
tar czf xtradb.tgz xtradb/
rm -rf xtradb
cd ../../

tar zxvf ~/Percona-Server-5.1.61.tar.gz
cp -r Percona-Server-5.1.61/storage/innodb_plugin 5.3-vanilla-xtradb-r3/storage/
patch -p1 -d 5.3-vanilla-xtradb-r3/storage/innodb_plugin/ < make-vanilla-xtradb-work-with-mariadb.diff

cd 5.3-vanilla-xtradb-r3/

BUILD/autorun.sh
./configure --with-plugin-innodb_plugin
make

_{This page is licensed: CC BY-SA / Gnu FDL}

By default all plugins are enabled and built as dynamic .so (or .dll) modules. If a plugin does not support dynamic builds, it is not built at all.

Use PLUGIN_xxx cmake variables. They can be set on the command line with -DPLUGIN_xxx=value or in the cmake gui. Supported values are

Note that unlike autotools, cmake tries to configure and build incrementally. You can modify one configuration option and cmake will only rebuild the part of the tree affected by it. For example, when you do cmake -DWITH_EMBEDDED_SERVER=1 in the already-built tree, it will make libmysqld to be built, but no other configuration options will be changed or reset to their default values.

In particular this means that if you have run, for examplecmake -DPLUGIN_OQGRAPH=NO and later you want to restore the default behavior (with OQGraph being built) in the same build tree, you would need to runcmake -DPLUGIN_OQGRAPH=DYNAMIC

Alternatively, you might simply delete the CMakeCache.txt file — this is the file where cmake stores current build configuration — and rebuild everything from scratch.

_{This page is licensed: CC BY-SA / Gnu FDL}

Read the Profiling Memory Usage page for more information on how to debug high memory consumption.

Using tcmalloc or jemalloc

TCMalloc is a malloc replacement library optimized for multi-threaded usage. It also features a built-in heap debugger and profiler.

Another malloc replacement that may speed up MariaDB is jemalloc.

The procedures to use one of these libraries with MariaDB are the same. Many other malloc replacement libraries (as well as heap debuggers and profilers) can be used with MariaDB in a similar fashion.

Checking the malloc Implementation in Use

If you are unsure which malloc implementation is in use, or if you used one of the procedures explained in this page and you want to verify if it succeeded, you can run this query:

SHOW GLOBAL VARIABLES LIKE 'version_malloc_library';

A value of "system" indicates the system default, which is normally malloc. If another library is used, this query will return the name and version of the library.

Building MariaDB with an alternative to malloc

To build MariaDB 5.5 with TCMalloc, you need to use the following command

cmake -DCMAKE_EXE_LINKER_FLAGS='-ltcmalloc'  -DWITH_SAFEMALLOC=OFF

To use jemalloc, the option should be -ljemalloc.

Starting mariadbd-safe with an alternative to malloc

If you want to do this only one time, as a test, you can also start a standard MariaDB server with TCmalloc with:

/usr/sbin/mariadbd-safe --malloc-lib=tcmalloc

If you want to configure mariadbd-safe to use tcmalloc or jemalloc, edit your configuration file, in the [server] or [mariadbd] group:

malloc-lib=tcmalloc

Starting mariadbd with an alternative to malloc

First, locate the library file that needs to be used:

# jemalloc
find /usr/lib -name "libjemalloc.so.*"
# tcmalloc
find /usr/lib -name "libtcmalloc.so.*"

Now pass it to mariadbd using the LD_PRELOAD variable:

LD_PRELOAD=/path/to/library mariadbd

For example, on OpenSuse 15.4 one would do:

Configuring systemd

If you use systemd to run MariaDB, first locate the library as explained above. The locate the service configuration file:

systemctl status mariadb |grep Loaded

Now edit the mariadb.service file by adding a line to the [Service] group:

Environment=LD_PRELOAD=<path-to-library>

For example:

[Service]
Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2

Now you should reload the configuration, so that the news setting will take effect, and restart MariaDB:

systemctl daemon-reload
systemctl restart mariadb

Dockerfile

If you run MariaDB on Docker and use an image from a Dockerfile that is publicly available, most probably you have an entrypoint that is a Bash script, which starts mariadbd directly. You can edit this Bash script as explained above. Or you can set the LD_PRELOAD variable from the Dockerfile:

ENV LD_PRELOAD=<path-to-library>

To find the library file you can run one of these commands while the container is running:

# jemalloc
docker exec -ti <container-name> find /usr/lib -name "libjemalloc.so.*"
# tcmalloc
docker exec -ti <container-name> find /usr/lib -name "libtcmalloc.so.*"

Example:

docker run -P -d --name mariadb --env LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libjemalloc.so.2" --env MARIADB_ROOT_PASSWORD=Password123! mariadb:latest

Vagrantfile

Usually Vagrant is used to start a complete system in a virtual machine. If this is your case, you can use one of the methods above, for example you can modify your Vagrantfile to copy a modified version of the mariadb.service file into the guest system to configure systemd.

If you use Vagrant with the Docker provider, you can follow the instructions above to modify the Dockerfile.

Finding memory leaks with jemalloc

jemalloc can provide a report of memory leaks at program exit:

MALLOC_CONF=prof_leak:true,lg_prof_sample:0,prof_final:true \
LD_PRELOAD=${JEMALLOC_PATH}/lib/libjemalloc.so.2  path-to-mariadbd

This will produce something like:

<jemalloc>: Leak summary: 267184 bytes, 473 objects, 20 contexts
<jemalloc>: Run jeprof on "jeprof.19678.0.f.heap" for leak detail

You can learn more about the memory leaks with jeprof, that is included with jemalloc:

jeprof --show_bytes path-to-mariadbd jeprof.19678.0.f.heap

You can also generate a PDF call graph of the leak:

jeprof --show_bytes --pdf path-to-mariadbd  jeprof.19678.0.f.heap > /tmp/mariadbd.pdf

See Also

• Profiling memory usage

• Debugging a running server on Linux

• Jemalloc leak checking

_{This page is licensed: CC BY-SA / Gnu FDL}