Learn to compile MariaDB Server from source code. This section provides detailed instructions for building MariaDB, offering flexibility and control over your installation.
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.
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
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:
Synchronize your tree with
emerge --sync
Build MariaDB using
emerge mariadb
This page is licensed: CC BY-SA / Gnu FDL
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 tothis 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, installWindows 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.
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.
Building Debug version is done with:
cmake --build . --config Debug
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.
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.
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.
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
cmake --build . --config relwithdebinfo
cmake --build . --config relwithdebinfo --target MSI
Starting with MariaDB 5.2.7, it is possible to build an installer which
includes 3rd party products, as described inMWL#200. Currently onlyHeidiSQL 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.
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.
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.
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
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 onrepository-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
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.
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
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.
libncurses or libncurses6
zlib-dev or zlib-devel
libevent-dev or libevent-devel
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).
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:
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
sudo yum install rpm-build yum-utils
yumdownloader --source MariaDB
sudo yum-builddep MariaDB-*.src.rpm
rpmbuild --rebuild MariaDB-*.src.rpm
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
The instructions on this page will help you compile MariaDB from source. Links to more complete instructions for specific platforms can be found on thesource page.
First, get a copy of the MariaDB source.
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
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
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 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.
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
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.
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.
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.
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.
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
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):
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
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
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
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 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
This page is licensed: CC BY-SA / Gnu FDL
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:
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.
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
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:
podman run / docker run
run a container
other implementations use docker syntax (or at least close)
--rm
remove container on termination
-ti
a tty and a stdin are connected
for interactive container use
-v "$PWD":/source:z
mount current directory as /source inside the container - :z - read selinux label
--mount=type=tmpfs,tmpfs-size=10G,dst=/build
a 10G build directory and mtr under podman
keeps as transient, big enough for some mtr tests
--tmpfs /build:size=10G,exec,uid=1000
a 10G build directory and mtr for docker
keeps as transient, big enough for some mtr tests, exec and uid needed by build/tests
--workdir /build
default directory
--entrypoint bash
Ensure the cmd of buildbot start isn't executed
--cap-add=SYS_PTRACE
capability for tracing used by gdb
for debugging
Extra options
--name containername
useful if running multiple to keep track
Used as a name for a new session in the container (podman exec -ti containername bash)
--shm-size=10g
Size of /dev/shm as alternate for mtr tests
Default is unsable 64k, This is large enough for most --big-tests with some parallelism
--privileged
Allow rr recording
Note security impacting, don't run untrusted code as root
-v $DATADIR:/var/lib/mysql:Z
Mount an existing datadir
For testing against some prepared data
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
.
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.
UPDATE_SUBMODULES=OFF
The source directory is read-only so cannot be updated from within the container
WITH_MSAN=ON
Enables MSAN build in compile options
CMAKE_{EXE,MODULE}_LINKER_FLAGS
links executables and shared libraries against the instrumented libraries with a rpath so a LD_LIBRARY_PATH environment variable isn't required
WITH_INNODB_{BZIP2,LZ4,LZMA,LZO,SNAPPY}=OFF
system libraries for these haven't been MSAN instrumented currently
HAVE_CXX_NEW
Works around a ODR violation
WITH_ZLIB=bundled
This hasn't been MSAN instrumented currently
WITH_NUMA / WITH_SYSTEMD
both uninstrumented
HAVE_LIBAIO_H=0 / CMAKE_DISABLE_FIND_PACKAGE_LIBAIO
AIO currently not MSAN instrumented
CMAKE_DISABLE_FIND_PACKAGE_URING=NO
Uninstrumented MDEV-36482, and required seccomp adjustment or --privileged to work
PLUGIN_OQGRAPH (and PLUGIN_COLUMNSTORE)
Dependency on boost libraries are instrumented
WITH_EMBEDDED_SERVER=OFF
reduce build time
WITH_DBUG_TRACE=OFF
reduce runtime overhead if CMAKE_BUILD_TYPE=Debug chosen
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.
Use the MSAN in the label when reporting bugs.
Current outstanding MSAN bugs can be found on JIRA by searching for this label.
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
UPDATE_SUBMODULES=OFF
The source directory is read-only so cannot be updated from within the container
WITH_ASAN=ON
Enables ASAN build in compile options
WITH_UBSAN=ON
Enables UBSAN build in compile options
WITH_UNIT_TESTS=OFF or PLUGIN_PERFSCHEMA=OFF
clang is incompatible with performance schema unit tests, at least one must be disabled (ref: MDEV-22940)
Build and test run are standard.
Note: list of unfixed UBSAN issues by MariaDB Corporation Testing.
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.
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.
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
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.
This page is licensed: CC BY-SA / Gnu FDL
All CMake configuration options for MariaDB can be displayed with:
cmake . -LH
Get the Code, Build it, Test it (mariadb.org)
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
This page is licensed: CC BY-SA / Gnu FDL
How to generate binary tar.gz files.
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 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.
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 thesource 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 amysql
user. The example below uses this user.
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
NOTE If you have built MariaDB in the past and have recently updated the repository, you should perform a complete cleanup of old artifacts (such as cmake configured files). 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
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-are
compile-pentium64
Compile an optimized binary optimized for 64 bit pentium (works also for amd64)
compile-pentium-debug
Compile a debug binary optimized for 64 bit pentium
compile-pentium-valgrind-max
Compile a debug binary that can be used with valgrind to find wrong memory accesses and memory leaks. Should be used if one want's to run the mysql-test-run test suite with the --valgrind option
Some common suffixes used for the scripts:
32
Compile for 32 bit cpu's
64
Compile for 64 bit cpu's
-max
Enable (almost) all features and plugins that MariaDB supports
-gprof
binary is compiled with profiling (gcc --pg)
-gcov
binary is compiled with code coverage (gcc -fprofile-arcs -ftest-coverage)
-valgrind
The binary is compiled for debugging and optimized to be used with valgrind.
-debug
The binary is compiled with all symbols (gcc -g) and the DBUG log system is enabled.
All BUILD
scripts support the following options:
-h, --help
Show this help message.
-n, --just-print
Don't actually run any commands; just print them.
-c, --just-configure
Stop after running configure. Combined with --just-print shows configure options.
--extra-configs=xxx
Add this to configure options
--extra-flags=xxx
Add this C and CXX flags
--extra-cflags=xxx
Add this to C flags
--extra-cxxflags=xxx
Add this to CXX flags
--verbose
Print out full compile lines
--with-debug=full
Build with full debug(no optimizations, keep call stack).
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
.
After installing MariaDB (using sudo make install
), but prior to starting MariaDB for the first time, one should:
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)
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:
[mariadbd]
datadir=/usr/local/mariadb/data/
run the mariadb-install-db script to generate the needed system tables
Here is an example:
# 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
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.
NOTE: If you are doing more extensive testing or debugging of MariaDB (like with real application data and workloads) you may want to start and run MariaDB directly from the source directory instead of installing it with 'sudo make install
'. If so, seeRunning MariaDB from the Source Directory.
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.
MariaDB builds with readline
; using an alternative such as Editline
may result in problems with non-ascii symbols.
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.
sudo zypper install git gcc gcc-c++ make bison ncurses ncurses-devel zlib-devel libevent-devel cmake openssl
apt install -y build-essential bison libgnutls28-dev
apt build-dep mariadb-server
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
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
mysql-test/mtr --parallel=8 --force
./scripts/mariadb-install-db --srcdir=.
(Older MariaDB version use mysql_install_db)
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 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.
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!
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.
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
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
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.
See also building RPM packages from source
This page is licensed: CC BY-SA / Gnu FDL
Compile MariaDB Server with extra modules and options. This section details how to customize your build from source, enabling specific features or optimizations for your deployment.
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
NO
the plugin will be not compiled at all
STATIC
the plugin will be compiled statically, if supported. Otherwise it will be not compiled.
DYNAMIC
the plugin will be compiled dynamically, if supported. Otherwise it will be not compiled. This is the default behavior.
AUTO
the plugin will be compiled statically, if supported. Otherwise it will be compiled dynamically.
YES
same as AUTO, but if plugin prerequisites (for example, specific libraries) are missing, it will not be skipped, it will abort cmake with an error.
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.
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.
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.
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
.
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
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:
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
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
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.
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
This page is licensed: CC BY-SA / Gnu FDL