Prior to , the client was called mysqld. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.

See mariadbd-options for details.

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

In MacOS, create a file called /Library/LaunchDaemons/com.mariadb.server.plist with the following contents (edit to suit):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key> <string>com.mariadb.server</string>
  <key>KeepAlive</key><true/>
  <key>RunAtLoad</key><true/>
  <key>LaunchOnlyOnce</key><false/>
  <key>ExitTimeOut</key><integer>600</integer>
  <key>WorkingDirectory</key><string>/usr/local/var</string>
  <key>Program</key><string>/usr/local/bin/mysqld</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/mysqld</string>
    <string>--user=_mysql</string>
    <string>--basedir=/usr/local/opt/mariadb</string>
    <string>--plugin-dir=/usr/local/opt/mariadb/lib/plugin</string>
    <string>--datadir=/usr/local/var/mysql</string>
    <string>--log-error=/usr/local/var/mysql/Data-Server.local.err</string>
    <string>--pid-file=/usr/local/var/mysql/Data-Server.local.pid</string>
    <string>--sql-mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION</string>
  </array>
</dict>
</plist>

Then from a shell, run launchctl load /Library/LaunchDaemons/com.mariadb.server.plist and MariaDB will run immediately, and also upon reboot.

See Also

• Creating Launch Daemons and Agents

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

Default File Permissions

By default MariaDB uses the following permissions for files and directories:

This article is about managing many different installed MariaDB versions and running them one at a time. This is useful when doing benchmarking, testing, or for when developing different MariaDB versions.

This is most easily done using the tar files from mariadb.org/download/.

Stopping a pre-installed MySQL/MariaDB from interfering with your tests

If MySQL/MariaDB is already installed and running, you have two options:

1. Use test MariaDB servers with a different port & socket.

• In this case you are probably best off creating a specific section for MariaDB in your ~/.my.cnf file.

1. Stop mysqld with /etc/rc.d/mysql stop or mariadb-admin shutdown.

Note that you don't have to uninstall or otherwise remove MySQL!

How to create a binary distribution (tar file)

Here is a short description of how to generate a tar file from a source distribution. If you have a binary tar file, you can skip this section.

The steps to create a binary tar file are:

• Decide where to put the source. A good place is under /usr/local/src/mariadb-5.#.

• .

You will then be left with a tar file named something like:mariadb-11.0.1-MariaDB-linux-x86_64.tar.gz

Creating a directory structure for the different installations

Install the binary tar files under /usr/local/ with the following directory names (one for each MariaDB version you want to use), for example:

• mariadb-10.5

• mariadb-10.6

• mariadb-10.11

The above assumes you are just testing major versions of MariaDB. If you are testing specific versions, use directory names like mariadb-11.0.1

With the directories in place, create a sym-link named mariadb which points at the mariadb-XXX directory you are currently testing. When you want to switch to testing a different version, just update the sym-link.

Example:

Setting up the data directory

When setting up the data directory, you have the option of either using a shared database directory or creating a unique database directory for each server version. For testing, a common directory is probably easiest. Note that you can only have one mysqld server running against one data directory.

Setting up a common data directory

The steps are:

1. Create the mysql system user if you don't have it already! (On Linux you do it with the useradd command).

2. Create the directory (we call it mariadb-data in the example below) or add a symlink to a directory which is in some other place.

3. Create the mysql permission tables with

The reason to use --no-defaults is to ensure that we don't inherit incorrect options from some old my.cnf.

Setting up different data directories

To create a different data directories for each installation:

This will create a directory data inside the current directory.

If you want to use another disk you should do:

Running a MariaDB server

The normal steps are:

Setting up a .my.cnf file for running multiple MariaDB main versions

If you are going to start/stop MariaDB a lot of times, you should create a ~/.my.cnf file for the common options you are using.

The following example shows how to use a non-standard TCP-port and socket (to not interfere with a main MySQL/MariaDB server) and how to setup different options for each main server:

If you create an ~/.my.cnf file, you should startmysqld with --defaults-file=~/.my.cnf instead of --no-defaults in the examples above.

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

It is possible to run multiple MariaDB Server processes on the same server, but there are certain things that need to be kept in mind. This page will go over some of those things.

Configuring Multiple MariaDB Server Processes

If multiple MariaDB Server process are running on the same server, then at minimum, you will need to ensure that the different instances do not use the same , , and . The following example shows these options set in an :

The above values are the defaults. If you would like to run multiple MariaDB Server instances on the same server, then you will need to set unique values for each instance.

There may be additional options that also need to be changed for each instance. Take a look at the full list of options for

There are several different methods to start or stop the MariaDB Server process. There are two primary categories that most of these methods fall into: starting the process with the help of a service manager, and starting the process manually.

Service Managers

sysVinit and systemd are the most common Linux service managers. launchd is used in MacOS X. Upstart is a less common service manager.

Systemd

RHEL/CentOS 7 and above, Debian 8 Jessie and above, and Ubuntu 15.04 and above use by default.

For information on how to start and stop MariaDB with this service manager, see .

SysVinit

RHEL/CentOS 6 and below, and Debian 7 Wheezy and below use by default.

For information on how to start and stop MariaDB with this service manager, see .

launchd

is used in MacOS X.

Upstart

Ubuntu 14.10 and below use Upstart by default.

Starting the Server Process Manually

mariadbd

is the actual MariaDB Server binary. It can be started manually on its own.

mariadbd-safe

is a wrapper that can be used to start the server process. The script has some built-in safeguards, such as automatically restarting the server process if it dies. See for more information.

mariadbd-multi

is a wrapper that can be used to start the server process if you plan to run multiple server processes on the same host. See for more information.

mysql.server

is a wrapper that works as a standard script. However, it can be used independently of as a regular sh script. The script starts the server process by first changing its current working directory to the MariaDB install directory and then starting . The script requires the standard arguments, such as start, stop, and status. See for more information.

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

You can run mariadbd directly from the build directory (without doingmake install).

Starting mariadbd After Build on Windows

On Windows, the data directory is produced during the build.

The simplest way to start database from the command line is:

1. Go to the directory where mariadbd.exe is located (subdirectory sql\Debug or sql\Relwithdebinfo of the build directory)

2. From here, execute, if you are using or newer,

else

As usual, you can pass other server parameters on the command line, or store them in a my.ini configuraton file and pass --defaults-file=path\to\my.ini

The default search path on Windows for the my.ini file is:

• GetSystemWindowsDirectory()

• GetWindowsDirectory()

• C:\

• Directory where the executable is located

Starting mariadbd After Build on Unix

Copy the following to your '~/.my.cnf' file.

There are two lines you have to edit: 'datadir=' and 'language='. Be sure to change them to match your environment.

With the above file in place, go to your MariaDB source directory and execute:

Above '$PWD' is the environment variable that points to your current directory. If you added datadir to your my.cnf, you don't have to give this option above. Also above, --user=$LOGNAME is necessary when using msqyld 10.0.1-MariaDB (and possibly other versions)

Now you can start mariadbd (or mysqld if you are using a version older than ) in the debugger:

Or start mariadbd on its own:

After starting up mariadbd using one of the above methods (with the debugger or without), launch the client (as root if you don't have any users setup yet).

Using a Storage Engine Plugin

The simplest case is to compile the storage engine into MariaDB:

Another option is to point mariadbd to the storage engine directory:

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

is one of the most common service managers. On systems that use , the script is normally installed to /etc/init.d/mysql.

Interacting with the MariaDB Server Process

The service can be interacted with by using the command.

Before using mariadbd-multi be sure that you understand the meanings of the options that are passed to the mariadbd servers and why you would want to have separate mariadbd processes. Beware of the dangers of using multiple mariadbd servers with the same data directory. Use separate data directories, unless you know what you are doing. Starting multiple servers with the same data directory does not give you extra performance in a threaded system.

The mariadbd-multi startup script is in MariaDB distributions on Linux and Unix. It is a wrapper that is designed to manage several mariadbd processes running on the same host.

Prior to , the client was called mysqld_multi. It can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.

In order for multiple mariadbd processes to work on the same host, these processes must:

• Use different Unix socket files for local connections.

• Use different TCP/IP ports for network connections.

• Use different data directories.

• Use different process ID files (specified by the --pid-file option) if using to start mariadbd.

mariadbd-multi can start or stop servers, or report their current status.

Using mariadbd-multi

The command to use mariadbd-multi and the general syntax is:

start, stop, and report indicate which operation to perform.

You can specify which servers to perform the operation on by providing one or more GNR values. GNR refers to an option group number, and it is explained more in the section below. If there is no GNR list, then mariadbd-multi performs the operation for all GNR values found in its option files.

Multiple GNR values can be specified as a comma-separated list. GNR values can also be specified as a range by separating the numbers by a dash. There must not be any whitespace characters in the GNR list.

For example:

This command starts a single server using option group [mariadbd17]:

This command stops several servers, using option groups [mariadbd8] and [mariadbd10] through [mariadbd13]:

Options

mariadbd-multi supports the following options:

Option Files

In addition to reading options from the command-line, mariadbd-multi can also read options from . If an unknown option is provided to mariadbd-multi in an option file, then it is ignored.

The following options relate to how MariaDB command-line tools handles option files. They must be given as the first argument on the command-line:

Option Groups

mariadbd-multi reads options from the following from :

mariadbd-multi also searches for with names like [mariadbdN], where N can be any positive integer. This number is referred to in the following discussion as the option group number, or GNR:

GNR values distinguish option groups from one another and are used as arguments to mariadbd-multi to specify which servers you want to start, stop, or obtain a status report for. The GNR value should be the number at the end of the option group name in the option file. For example, the GNR for an option group named [mariadbd17] is 17.

Options listed in these option groups are the same that you would use in the regular server option groups used for configuring mariadbd. However, when using multiple servers, it is necessary that each one use its own value for options such as the Unix socket file and TCP/IP port number.

The [mariadbd-multi] option group can be used for options that are needed for mariadbd-multi itself. [mariadbdN] option groups can be used for options passed to specific mariadbd instances.

The regular server can also be used for common options that are read by all instances:

For an example of how you might set up an option file, use this command:

Authentication and Privileges

Make sure that the MariaDB account used for stopping the mariadbd processes (with the utility) has the same user name and password for each server. Also, make sure that the account has the SHUTDOWN privilege. If the servers that you want to manage have different user names or passwords for the administrative accounts, you might want to create an account on each server that has the same user name and password. For example, you might set up a common multi_admin account by executing the following commands for each server:

Change the connection parameters appropriately when connecting to each one. Note that the host name part of the account name must allow you to connect as multi_admin from the host where you want to run mariadbd-multi.

User Account

Make sure that the data directory for each server is fully accessible to the Unix account that the specific mariadbd process is started as. If you run the mariadbd-multi script as the Unix root account, and if you want the mariadbd process to be started with another Unix account, then you can use the --user option with mariadbd. If you specify the --user option in an option file, and if you did not run the mariadbd-multi script as the Unix root account, then it will just log a warning and the mariadbd processes are started under the original Unix account.

Do not run the mariadbd process as the Unix root account, unless you know what you are doing.

Example

The following example shows how you might set up an option file for use with mariadbd-multi. The order in which the mariadbd programs are started or stopped depends on the order in which they appear in the option file. Group numbers need not form an unbroken sequence. The first and fifth [mariadbdN] groups were intentionally omitted from the example to illustrate that you can have “gaps” in the option file. This gives you more flexibility.

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

The mysql.server startup script is in MariaDB distributions on Linux and Unix. It is a wrapper that works as a standard sysVinit script. However, it can be used independently of sysVinit as a regular sh script. The script starts the mariadbd server process by first changing its current working directory to the MariaDB install directory and then starting mariadbd-safe. The script requires the standard sysVinit arguments, such as start, stop, restart, and status. For example:

It can be used on systems such as Linux, Solaris, and Mac OS X.

The mysql.server script starts mariadbd by first changing to the MariaDB install directory and then calling mariadbd-safe.

Using mysql.server

The command to use mysql.server and the general syntax is:

Options

If an unknown option is provided to mariadbd-safe on the command-line, then it is passed to mariadbd-safe.

mysql.server supports the following options:

Option Files

In addition to reading options from the command-line, mysql.server can also read options from .

The following options relate to how MariaDB command-line tools handles option files. They must be given as the first argument on the command-line:

Option Groups

mysql.server reads options from the following from :

mysql.server also reads options from the following server from :

Customizing mysql.server

If you have installed MariaDB to a non-standard location, then you may need to edit the mysql.server script to get it to work right.

If you do not want to edit the mysql.server script itself, then mysql.server also sources a few other sh scripts. These files can be used to set any variables that might be needed to make the script work in your specific environment. The files are:

• /etc/default/mysql

• /etc/sysconfig/mysql

• /etc/conf.d/mysql

Installed Locations

mysql.server can be found in the support-files directory under your MariaDB installation directory or in a MariaDB source distribution.

Installed SysVinit Locations

On systems that use , mysql.server may also be installed in other locations and with other names.

If you installed MariaDB on Linux using , then the mysql.server script will be installed into the /etc/init.d directory with the name mysql. You need not install it manually.

Manually Installing with SysVinit

If you install MariaDB from or from a that does not install automatically, and if you are on a system that uses , then you can manually install mysql.server with . This is usually done by copying it to /etc/init.d/ and then creating specially named symlinks in the appropriate /etc/rcX.d/ directories (where 'X' is a number between 0 and 6).

In the examples below we will follow the historical convention of renaming themysql.server script to 'mysql' when we copy it to /etc/init.d/.

The first step for most Linux distributions is to copy the mysql.server script to /etc/init.d/ and make it executable:

Now all that is needed is to create the specially-named symlinks. On both RPM and Debian-based Linux distributions there are tools which do this for you. Consult your distribution's documentation if neither of these work for you and follow their instructions for generating the symlinks or creating them manually.

On RPM-based distributions (like Fedora and CentOS), you use chkconfig:

On Debian-based distributions you use update-rc.d:

On FreeBSD, the location for startup scripts is/usr/local/etc/rc.d/ and when you copy themysql.server script there you should rename it so that it matches the *.sh pattern, like so:

As stated above, consult your distribution's documentation for more information on starting services like MariaDB at system startup.

See for information on configuration options for mariadbd.

_{This page is licensed: GPLv2}

There could be many reasons that MariaDB fails to start. This page will help troubleshoot some of the more common reasons and provide solutions.

If you have tried everything here and still need help, you can ask for help on IRC or on the forums - see - or ask a question at the Starting and Stopping MariaDB page.

The Error Log and the Data Directory

The reason for the failure will almost certainly be written in the error log and, if you are starting MariaDB manually, to the console. By default, the error log is named host-name.err and is written to the data directory.

Common Locations:

• /var/log/

• /var/log/mysql

• C:\Program Files\MariaDB x.y\data (x.y refers to the version number)

• C:\Program Files (x86)\MariaDB x.y\data (32bit version on 64bit Windows)

It's also possible that the error log has been explicitly written to another location. This is often done by changing the or system variables in an . See the below for more information about that.

A quick way to get the values of these system variables is to execute the following commands:

Option Files

Another kind of file to consider when troubleshooting is . The default option file is called my.cnf. Option files contain configuration options, such as the location of the data directory mentioned above. If you're unsure where the option file is located, see for information on the default locations.

You can check which configuration options MariaDB server will use from its option files by executing the following command:

You can also check by executing the following command:

See for more information on checking configuration options.

Invalid Option or Option Value

Another potential reason for a startup failure is that an contains an invalid option or an invalid option value. In those cases, the should contain an error similar to this:

This is more likely to happen when you upgrade to a new version of MariaDB. In most cases, the from the old version of MariaDB will work just fine with the new version. However, occasionally, options are removed in new versions of MariaDB, or the valid values for options are changed in new versions of MariaDB. Therefore, it's possible for an to stop working after an upgrade.

Also, remember that option names are case sensitive.

Examine the specifics of the error. Possible fixes are usually one of the following:

• If the option is completely invalid, then remove it from the .

• If the option's name has changed, then fix the name.

• If the option's valid values have changed, then change the option's value to a valid one.

• If the problem is caused by a simple typo, then fix the typo.

Can't Open Privilege Tables

It is possible to see errors similar to the following:

If errors like this occur, then critical are either missing or are in the wrong location. The above error is quite common after an upgrade if the set the or datadir to a non-standard location, but the new server is using the default location. Therefore, make sure that the basedir and datadir variables are correctly set.

If you're unsure where the option file is located, see Configuring MariaDB with Option Files: Default Option File Locations for information on the default locations.

If the really do not exist, then you may need to create them with . See for more information.

Can't Create Test File

One of the first tests on startup is to check whether MariaDB can write to the data directory. When this fails, it will log an error like this:

This is usually a permission error on the directory in which this file is being written. Ensure that the entire is owned by the user running mariadbd, usually mysql. Ensure that directories have the "x" (execute) directory permissions for the owner. Ensure that all the parent directories of the datadir upwards have "x" (execute) permissions for all (user, group, and other).

Once this is checked, look at the and documentation below, or .

Can't Lock Aria Control File

On starting MariaDB, the aria_log_control file is locked. If a lock cannot be obtained, it will log an error like this:

This almost always happens because there is already an existing MariaDB service running on this data directory. Recommend aborting this startup and looking closely for the other MariaDB instance.

A less likely case is that file locking is not available, which might occur on an NFS-mounted data directory without proper locking support.

Unable to lock ./ibdata1 error 11

Like the above for the Aria Control File, this is attempting to exclusively lock the ibdata1 InnoDB system tablespace. Error 11 corresponds to the system error "OS error code 11: Resource temporarily unavailable," meaning the lock cannot be created.

Like the above, this is an indication that a second MariaDB instance is already running on the data directory.

InnoDB

is probably the MariaDB component that most frequently causes a crash. In the error log, lines containing InnoDB messages generally start with "InnoDB:".

Cannot Allocate Memory for the InnoDB Buffer Pool

In a typical installation on a dedicated server, at least 70% of your memory should be assigned to the ; sometimes it can even reach 85%. But be very careful: don't assign to the buffer pool more memory than it can allocate. If it cannot allocate memory, InnoDB will use the disk's swap area, which is very bad for performance. If swapping is disabled or the swap area is not big enough, InnoDB will crash. In this case, MariaDB will probably try to restart several times, and each time it will log a message like this:

In that case, you will need to add more memory to your server/VM or decrease the value of the variable.

Remember that the buffer pool will slightly exceed that limit. Also, remember that MariaDB also needs to allocate memory for other storage engines and several per-connection buffers. The operating system also needs memory.

InnoDB Table Corruption

By default, InnoDB deliberately crashes the server when it detects table corruption. The reason for this behavior is preventing corruption propagation. However, in some situations, server availability is more important than data integrity. For this reason, we can avoid these crashes by changing the value of to 'warn'.

If InnoDB crashes the server after detecting data corruption, it writes a detailed message in the error log. The first lines are similar to the following:

Generally, it is still possible to recover most of the corrupted data. To do so, restart the server in and try to extract the data that you want to backup. You can save them in a CSV file or in a non-InnoDB table. Then, restart the server in normal mode and restore the data.

MyISAM

Most tables in the database are MyISAM tables. These tables are necessary for MariaDB to properly work or even start.

A MariaDB crash could cause system table corruption. With the default settings, MariaDB will simply not start if the system tables are corrupted. With , we can force MyISAM to repair damaged tables.

systemd

If you are using , then there are a few relevant notes about startup failures:

• If MariaDB is configured to access files under /home, /root, or /run/user, then the default systemd unit file will prevent access to these directories with a Permission Denied error. This happens because the unit file sets . See for information on how to work around this.

• The default systemd unit file also sets , which places restrictions on writing to a few other directories. Overwriting this with ProtectSystem=off in the same way as above will restore access to these directories.

See documentation for further information on systemd configuration.

SELinux

is a Linux kernel module that provides a framework for configuring a system for many resources on the system. It is enabled by default on some Linux distributions, including RHEL, CentOS, Fedora, and other similar Linux distributions. SELinux prevents programs from accessing files, directories, or ports unless it is configured to access those resources.

You might need to troubleshoot SELinux-related issues in cases such as:

• MariaDB is using a non-default port.

• MariaDB is reading from or writing to some files (datadir, log files, option files, etc.) located at non-default paths.

• MariaDB is using a plugin that requires access to resources that default installations do not use.

Setting SELinux state to permissive is a common way to investigate what is going wrong while allowing MariaDB to function normally. permissive is supposed to produce a log entry every time it should block a resource access, without actually blocking it. However, when SELinux blocks resource accesses even in permissive mode.

See for more information.

AppArmor

Add the following to /etc/apparmor.d/tunables/alias if you have moved the datadir:

The restart AppArmor:

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

The mariadbd-safe startup script is in MariaDB distributions on Linux and Unix. It is a wrapper that starts mariadbd with some extra safety features. For example, if mariadbd-safe notices that mariadbd has crashed, then mariadbd-safe will automatically restart mariadbd.

mariadbd-safe is the recommended way to start mariadbd on Linux and Unix distributions that do not support . Additionally, the init script used by starts mariadbd with mariadbd-safe

systemd is a sysVinit replacement that is the default service manager on the following Linux distributions:

• RHEL 7 and above

• CentOS 7 and above

• Fedora 15 and above

• Debian 8 and above

• Ubuntu 15.04 and above

• SLES 12 and above

• OpenSUSE 12.2 and above

MariaDB's systemd unit file is included in the server packages for and . It is also included in certain .

The service name is mariadb.service.

Installing & Starting MariaDB

When installing MariaDB server rpm / dep package, it will automatically run the script, that creates the initial databases and users.

When MariaDB is started with the systemd unit file, it directly starts the process as the mysql user. Unlike with , the process is not started with . As a consequence, options will not be read from the [mariadbd-safe] from .

Contents of the MariaDB Service's Unit File

The contents of the mariadb.service file can be examined with systemctl show mariadb.service.

Interacting with the MariaDB Server Process

The service can be interacted with by using the command.

Starting the MariaDB Server Process on Boot

MariaDB's systemd service can be configured to start at boot by executing the following:

Starting the MariaDB Server Process

MariaDB's systemd service can be started by executing the following:

MariaDB's systemd unit file has a default startup timeout of about 90 seconds on most systems. If certain startup tasks, such as crash recovery, take longer than this default startup timeout, then systemd will assume that mariadbd has failed to startup, which causes systemd to kill the mariadbd process. To work around this, you can reconfigure the MariaDB systemd unit to have an .

Note that that allows services to extend the startup timeout during long-running processes. Starting with , , and , on systems with systemd versions that support it, MariaDB uses this feature to extend the startup timeout during certain startup processes that can run long. Therefore, if you are using systemd 236 or later, then you should not need to manually override TimeoutStartSec, even if your startup tasks, such as crash recovery, run for longer than the configured value. See for more information.

Stopping the MariaDB Server Process

MariaDB's systemd service can be stopped by executing the following:

Restarting the MariaDB Server Process

MariaDB's systemd service can be restarted by executing the following:

Checking the Status of the MariaDB Server Process

The status of MariaDB's systemd service can be obtained by executing the following:

Interacting with Multiple MariaDB Server Processes

A systemd with the name mariadb@.service is installed in INSTALL_SYSTEMD_UNITDIR on some systems. See to see what directory that refers to on each distribution.

This template unit file allows you to interact with multiple MariaDB instances on the same system using the same template unit file. When you interact with a MariaDB instance using this template unit file, you have to provide an instance name as a suffix. For example, the following command tries to start a MariaDB instance with the name node1:

MariaDB's build system cannot include the mariadb@.service template unit file in packages on platforms that have versions older than 3.3.0, because these versions have a that causes it to encounter errors when packaging a file in RPMs if the file name contains the @ character. MariaDB's RHEL 7 and CentOS 7 RPM build hosts only got a new enough version starting with , , and . To use this functionality on a MariaDB version that does not have the file, you can copy the file from a package that does have the file.

Default configuration of Multiple Instances in 10.4 and Later

systemd will also look for an for a specific MariaDB instance based on the instance name.

It will use the .%I as the that is appended to any , in any configuration file included by default.

In all distributions, the %I is the MariaDB instance name. In the above node1 case, it would use the at the path/etc/mynode1.cnf.

When using multiple instances, each instance will of course also need their own , and , (unless [skip_networking](../../../server-usage/replication-cluster-multi-master/optimization-and-tuning/system-variables/server-system-variables.md#skip_networking) is specified). As [mariadb-install-db#option-groups](../../../clients-and-utilities/mariadb-install-db.md#option-groups) reads the same sections as the server, andExecStartPre=run [mariadb-install-db](../../../clients-and-utilities/mariadb-install-db.md) within the service, the instances are autocreated if there is sufficient priviledges.

To use a 10.3 configuration in 10.4 or later and the following customisation in the editor after running sudo systemctl edit mariadb@.service:

Custom configuration of Multiple Instances in 10.4 and Later

Because users may want to do many various things with their multiple instances, we've provided a way to let the user define how they wish their multiple instances to run. The systemd environment variable MYSQLD_MULTI_INSTANCE can be set to anything that and will recognise.

A hosting environment where each user has their own instance may look like (with sudo systemctl edit mariadb@.service):

Here the instance name is the unix user of the service.

Configuring Multiple Instances in 10.3 and Earlier

systemd will also look for an for a specific MariaDB instance based on the instance name. By default, it will look for the option file in a directory defined at build time by the INSTALL_SYSCONF2DIR option provided to .

For example, on RHEL, CentOS, Fedora, and other similar Linux distributions, INSTALL_SYSCONF2DIR is defined as /etc/my.cnf.d/, so it will look for an option file that matches the format:

• /etc/my.cnf.d/my%I.cnf

And on Debian, Ubuntu, and other similar Linux distributions, INSTALL_SYSCONF2DIR is defined as /etc/mysql/conf.d//, so it will look for an option file that matches the format:

• /etc/mysql/conf.d/my%I.cnf

In all distributions, the %I is the MariaDB instance name. In the above node1 case, it would use the at the path/etc/my.cnf.d/mynode1.cnf for RHEL-like distributions and /etc/mysql/conf.d/mynode1.cnf for Debian-like distributions.

When using multiple instances, each instance will of course also need their own . See for information on how to initialize the for additional MariaDB instances.

Systemd and Galera Cluster

Bootstrapping a New Cluster

When using with systemd, the first node in a cluster has to be started with galera_new_cluster. See for more information.

Recovering a Node's Cluster Position

When using Galera Cluster with systemd, a node's position in the cluster can be recovered with galera_recovery. See for more information.

SSTs and Systemd

MariaDB's systemd unit file has a default startup timeout of about 90 seconds on most systems. If an SST takes longer than this default startup timeout on a joiner node, then systemd will assume that mariadbd has failed to startup, which causes systemd to kill the mariadbd process on the joiner node. To work around this, you can reconfigure the MariaDB systemd unit to have an . See for more information.

Note that that allows services to extend the startup timeout during long-running processes. Starting with , , and , on systems with systemd versions that support it, MariaDB uses this feature to extend the startup timeout during long SSTs. Therefore, if you are using systemd 236 or later, then you should not need to manually override TimeoutStartSec, even if your SSTs run for longer than the configured value. See for more information.

Configuring the Systemd Service

You can configure MariaDB's systemd service by creating a "drop-in" configuration file for the systemd service. On most systems, the systemd service's directory for "drop-in" configuration files is /etc/systemd/system/mariadb.service.d/. You can confirm the directory and see what "drop-in" configuration files are currently loaded by executing:

If you want to configure the systemd service, then you can create a file with the .conf extension in that directory. The configuration option(s) that you would like to change would need to be placed in an appropriate section within the file, usually [Service]. If a systemd option is a list, then you may need to set the option to empty before you set the replacement values. For example:

After any configuration change, you will need to execute the following for the change to go into effect:

Useful Systemd Options

Useful systemd options are listed below. If an option is equivalent to a common option, then that is also listed. Use systemctl edit mariadb.service to create the systemd option under a [Service] section header.

Note: the manual contains the official meanings for these options. The manual also lists considerably more options than the ones listed above.

There are other options and the mariadb-service-convert script will attempt to convert these as accurately as possible.

Configuring the Systemd Service Timeout

MariaDB's unit file has a default startup timeout of about 90 seconds on most systems. If a service startup takes longer than this default startup timeout, then systemd will assume that mariadbd has failed to startup, which causes systemd to kill the mariadbd process. To work around this, it can be changed by configuring the option for the systemd service.

A similar problem can happen when stopping the MariaDB service. Therefore, it may also be a good idea to set .

For example, you can reconfigure the MariaDB systemd service to have an infinite timeout by executing one of the following commands:

If you are using systemd 228 or older, then you can execute the following to set an infinite timeout:

, so if you are using systemd 229 or later, then you can execute the following to set an infinite timeout:

Note that that allows services to extend the startup timeout during long-running processes. On systems with systemd versions that support it, MariaDB uses this feature to extend the startup timeout during certain startup processes that can run long.

Configuring the Open Files Limit

When using systemd, rather than setting the open files limit by setting the option for mariadbd-safe or the system variable, the limit can be changed by configuring the option for the MariaDB systemd service. The default is set to LimitNOFILE=16364 in mariadb.service.

For example, you can reconfigure the MariaDB systemd service to have a larger limit for open files by executing the following commands:

An important note is that setting LimitNOFILE=infinity doesn't actually set the open file limit to infinite.

In systemd 234 and later, setting LimitNOFILE=infinity actually sets the open file limit to the value of the kernel's fs.nr_open parameter. Therefore, in these systemd versions, you may have to change this parameter's value.

The value of the fs.nr_open parameter can be changed permanently by setting the value in and restarting the server.

The value of the fs.nr_open parameter can be changed temporarily by executing the utility. For example:

In systemd 233 and before, setting LimitNOFILE=infinity actually sets the open file limit to 65536. See for more information. Therefore, in these systemd versions, it is not generally recommended to set LimitNOFILE=infinity. Instead, it is generally better to set LimitNOFILE to a very large integer. For example:

Configuring the Core File Size

When using systemd, if you would like to , rather than setting the core file size by setting the option for mariadbd-safe, the limit can be changed by configuring the option for the MariaDB systemd service. For example, you can reconfigure the MariaDB systemd service to have an infinite size for core files by executing the following commands:

Configuring MariaDB to Write the Error Log to Syslog

When using systemd, if you would like to redirect the to the , then that can easily be done by doing the following:

• Ensure that system variable is not set.

• Set .

• Set .

• Set .

For example:

If you have multiple instances of MariaDB, then you may also want to set with a different tag for each instance.

Configuring LimitMEMLOCK

If using , or the io_uring asyncronious IO in InnoDB in or above, with a Linux Kernel version < 5.12, you will need to raise the LimitMEMLOCK limit.

Note: Prior to , the option could not be used with the MariaDB systemd service.

Configuring Access to Home Directories

MariaDB's unit file restricts access to /home, /root, and /run/user by default. This restriction can be overridden by setting the option to false for the MariaDB systemd service. This is done by creating a "drop-in" directory /etc/systemd/system/mariadb.service.d/ and in it a file with a .conf suffix that contains the ProtectHome=false directive.

You can reconfigure the MariaDB systemd service to allow access to /home by executing the following commands:

Configuring the umask

When using systemd, the default file permissions of mariadbd can be set by setting the UMASK and UMASK_DIR environment variables for the systemd service. For example, you can configure the MariaDB systemd service's umask by executing the following commands:

These environment variables do not set the umask. They set the default file system permissions. See for more information.

Keep in mind that configuring the umask this way will only affect the permissions of files created by the mariadbd process that is managed by systemd. The permissions of files created by components that are not managed by systemd, such as , will not be affected.

See for more information.

Configuring the data directory

When doing a standard binary tarball install the datadir will be under /usr/local/data. The default systemd service file makes the whole /usr directory tree write protected however.

So when just copying the distributed service file a tarball install will not start up, complaining e.g. about

So when using a data directory under /usr/local that specific directory needs to be made writable for the service using the ReadWritePaths setting:

Systemd Socket Activation

MariaDB starting with

MariaDB can use systemd's socket activation.

This is an on-demand service for MariaDB that will activate when required.

Systemd socket activation uses a mariadb.socket definition file to define a set of UNIX and TCP sockets. Systemd will listen on these sockets, and when they are connected to, systemd will start the mariadb.service and hand over the socket file descriptors for MariaDB to process the connection.

MariaDB remains running at this point and will have all sockets available and process connections exactly like it did before 10.6.

When MariaDB is shut down, the systemd mariadb.socket remains active, and a new connection will restart the mariadb.service.

Using Systemd Socket Activation

To use MariaDB systemd socket activation, instead of enabling/starting mariadb.service, mariadb.socket is used instead.

So the following commands work exactly like the mariadb.service equivalents.

These files alone only contain the UNIX and TCP sockets and basic network connection information to which will be listening for connections. @mariadb is a UNIX abstract socket, which means it doesn't appear on the filesystem. Connectors based on MariaDB Connector/C will be able to connect with these by using the socket name directly, provided the higher level implementation doesn't try to test for the file's existence first. Some connectors like PHP use mysqlnd that is a pure PHP implementation and as such will only be able to connect to on filesystem UNIX sockets.

With systemd activated sockets there is only a file descriptor limit on the number of listening sockets that can be created.

When to Use Systemd Socket Activation

A common use case for systemd socket activated MariaDB is when there needs to be a quick boot up time. MariaDB needs to be ready to run, but it doesn't need to be running.

The ideal use case for systemd socket activation for MariaDB is for infrastructure providers running many multiple instances of MariaDB, where each instance is dedicated for a user.

Downsides to Using Systemd Socket Activiation

From the time the connection occurs, the client is going to be waiting until MariaDB has fully initialized before MariaDB can process the awaiting connection. If MariaDB was previously hard shutdown and needs to perform an extensive InnoDB rollback, then the activation time may be larger than the desired wait time of the client connection.

Configuring Systemd Socket Activation

When MariaDB is run under systemd socket activation, the usual , , and system variables are ignored, as these settings are contained within the systemd socket definition file.

There is no configuration required in MariaDB to use MariaDB under socket activation.

The systemd options available are from the , however and would be the most common configuration options.

As MariaDB isn't creating these sockets, the sockets don't need to be created with a mysql user. The sockets MariaDB may end up listening to under systemd socket activation, it may have not had the privileges to create itself.

Changes to the default mariadb.socket can be made in the same way as services, systemctl edit mariadb.socket, or using /etc/systemd/system/mariadb.socket.d/someconfig.conf files.

Extra Port

A systemd socket can be configured as an , by using the[FileDescriptorName=extra](https://www.freedesktop.org/software/systemd/man/systemd.socket.html#FileDescriptorName=) in the.socketfile.

The mariadb-extra.socket is already packaged and ready for use.

Multi-instance socket activation

mariadb@.socket is MariaDB's packaged multi-instance defination. It creates multiple UNIX sockets based on the socket file started.

Starting mariadb@bob.socket will use the mariadb@.socket defination with %I within the defination replaced with "bob".

When something connects to a socket defined there, the mariadb@bob.service will be started.

Systemd Socket Activation for Hosting Service Providers

A systemd socket activation service with multi-instance can provide an on-demand per user access to a hosting service provider's dedicated database.

"User", in this case, refers to the customer of the hosting service provider.

End User Benefits

This provides the following benefits for the user:

• Each user has their own dedicated instance with the following benefits:

  • The instance is free from the database contention of neighbors on MariaDB shared resources (table cache, connections, etc)

  • The user is free to change their own configuration of MariaDB, within the limits and permissions of the service provider.

  • Database service level backups, like mariadb-backup, are now directly available.

Hosting Service Provider Benefits

In addition to providing user benefits as a sales item, the following are additional benefits for the hosting service provider compared to a monolith service:

• Without passwords for the database, while still having security, support may be easier.

• When a user's database isn't active, there is no resource usage, only listening file descriptors by systemd.

• The socket activation transparently, with a minor startup time, starts the service as required.

• When the user's database hasn't had any activity after a time, it will deactivate ().

Downsides to the Hosting Service Provider

The extra memory used by more instances. This is mitigated by the on-demand activation. The deactivation when idle, and improved InnoDB memory management.

With plenty of medium size database servers running, the Linux OOM kill has the opportunity to kill off only a small number of database servers running rather than everyones.

Example on configuration Items for a per user, systemd socket activitated multi-instance service

From a server pespective the operation would be as follows;

To make the socket ready to connect and systemd will be listening to the socket:

To enable this on reboot (the same way as a systemd service):

A MariaDB Template File

A global template file. Once installed as a user's $HOME/.my.cnf file, it will becomes the default for many applications, and the MariaDB server itself.

Custom Configuration for the Multi-instance Service

This extends/modifies the MariaDB multi-instance service.

The feature of this extension are:

• that it will autocreate configuration file for user applications

• It will install the database on first service start

• auth-root-* in means that the user is their own privileged user with unix socket authentication active. This means non-that user cannot access another users service, even with access to the unix socket(s). For more information see .

Custom Configuration for the Multi-instance Socket

This extends/modifies the MariaDB socket defination to be per user.

Create sockets based on the user of the istance (%I). Permissions are only necessary in the sense that the user can connect to them. It won't matter to the server. Access control is enforced within the server, however if the user web services are run as the user, Mode=777 can be reduced. @mariadb-%I is a abstract unix socket not on the filesystem. It may help if a user is in a chroot. Not all applications can connect to abstract sockets.

The extra socket provides the user the ability to access the server when all max-connections are used:

Systemd Journal

systemd has its own logging system called the systemd journal. The systemd journal contains information about the service startup process. It is a good place to look when a failure has occurred.

The MariaDB systemd service's journal can be queried by using the command. For example:

Converting mariadbd-safe Options to Systemd Options

mariadb-service-convert is a script included in many MariaDB packages that is used by the package manager to convert options to systemd options. It reads any explicit settings in the [mariadbd-safe] from , and its output is directed to /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf. This helps to keep the configuration the same when upgrading from a version of MariaDB that does not use systemd to one that does.

Implicitly high defaults of may be missed by the conversion script and require explicit configuration. See .

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

This page lists all of the options for mariadbd (called mysqld before ), ordered by topic. For a full alphabetical list of all mariadbd options, as well as server and status variables, see Full list of MariaDB options, system and status variables.

In many cases, the entry here is a summary, and links to the full description.

By convention, server variables have usually been specified with an underscore in the configuration files, and a dash on the command line. You can however specify underscores as dashes - they are interchangeable.

See Configuring MariaDB with Option Files for which files and groups mariadbd reads for it's default options.

Prior to , the client used to be called mysqld, and can still be accessed under this name, via a symlink in Linux, or an alternate binary in Windows.

Option Prefixes

--autoset-*

• Description: Sets the option value automatically. Only supported for certain options.

--disable-*

• Description: For all boolean options, disables the setting (equivalent to setting it to 0). Same as --skip.

--enable-*

• Description: For all boolean options, enables the setting (equivalent to setting it to 1).

--loose-*

• Description: Don't produce an error if the option doesn't exist.

--maximum-*

• Description: Sets the maximum value for the option.

--skip-*

• Description: For all boolean options, disables the setting (equivalent to setting it to 0). Same as --disable.

Option File Options

--defaults-extra-file

• Command line: --defaults-extra-file=name

• Description: Read this extra option file after all other option files are read.

  • See .

--defaults-file

• Command line: --defaults-file=name

• Description: Only read options from the given option file.

  • See .

--defaults-group-suffix

• Command line: --defaults-group-suffix=name

• Description: In addition to the default option groups, also read option groups with the given suffix.

  • See .

--no-defaults

• Command line: --no-defaults

• Description: Don't read options from any option file.

  • See .

--print-defaults

• Command line: --print-defaults

• Description: Read options from option files, print all option values, and then exit the program.

  • See .

Compatibility Options

The following options have been added to MariaDB to make it more compliant with other MariaDB and MySQL versions. Options that are also system variables are listed after:

-a, --ansi

• Description: Use ANSI SQL syntax instead of MariaDB syntax. This mode will also set .

--new

• Description: Use new functionality that will exist in next version of MariaDB. This function exists to make it easier to prepare for an upgrade.

--old-style-user-limits

• Description: Enable old-style user limits (before MySQL 5.0.3, user resources were counted per each user+host vs. per account).

--safe-mode

• Description: Disable some potential unsafe optimizations. For 5.2, is disabled, is set to DEFAULT (automatically recover crashed MyISAM files) and the is disabled. For tables, disable bulk insert optimization to enable one to use to recover tables even if tables are deleted (good for testing recovery).

--skip-new

• Description: Disables .

Compatibility Options and System Variables

Locale Options

Options that are also system variables are listed after:

--character-set-client-handshake

• Command line: --character-set-client-handshake

• Description: Don't ignore client side character set value sent during handshake. --skip-character-set-client-handshake will ignore the client value and use the default server value.

--default-character-set

• Command line: --default-character-set=name

• Description: Still available as an option for setting the default character set for clients and their connections, it was deprecated and removed in as a server option. Use instead.

--language

• Description: This option can be used to set the server's language for error messages. This option can be specified either as a language name or as the path to the directory storing the language's . See for a list of supported locales and their associated languages.

  • This option is deprecated. Use the and system variables instead.

  • See for more information.

Locale Options and System Variables

Windows Options

Options that are also system variables are listed after:

--console

• Description: Windows-only option that keeps the console window open and for writing log messages to stderr and stdout. If specified together with , the last option will take precedence.

--install

• Description: Windows-only option that installs the mariadbd process as a Windows service.

  • The Windows service created with this option . If you want a service that is started on demand, then use the option.

  • This option takes a service name as an argument. If this option is provided without a service name, then the service name defaults to "MARIADB".

--install-manual

• Description: Windows-only option that installs the mariadbd process as a Windows service.

  • The Windows service created with this option is started on demand. If you want a service that , use the option.

  • This option takes a service name as an argument. If this option is provided without a service name, then the service name defaults to "MARIADB".

--remove

• Description: Windows-only option that removes the Windows service created by the or options.

  • This option takes a service name as an argument. If this option is provided without a service name, then the service name defaults to "MARIADB".

  • This option is deprecated and may be removed in a future version. See for more information.

--slow-start-timeout

• Description: Windows-only option that defines the maximum number of milliseconds that the service control manager should wait before trying to kill the Windows service during startup. Defaults to 15000.

--standalone

• Description: Windows-only option that has no effect. Kept for compatibility reasons.

Windows Options and System Variables

The following options and system variables are related to using MariaDB on Windows:

Replication and Binary Logging Options

The following options are related to and the . Options that are also system variables are listed after:

--abort-slave-event-count

• Command line: --abort-slave-event-count=#

• Description: Option used by mysql-test for debugging and testing of replication.

--binlog-do-db

• Command line: --binlog-do-db=name

• Description: This option allows you to configure a to write statements and transactions affecting databases that match a specified name into its . Since the filtered statements or transactions will not be present in the , its replicas will not be able to replicate them.

  • This option will not work with cross-database updates with . See the section for more information.

--binlog-ignore-db

• Command line: --binlog-ignore-db=name

• Description: This option allows you to configure a to not write statements and transactions affecting databases that match a specified name into its . Since the filtered statements or transactions will not be present in the , its replicas will not be able to replicate them.

  • This option will not work with cross-database updates with . See the section for more information.

--binlog-row-event-max-size

• Command line: --binlog-row-event-max-size=#

• Description: The maximum size of a row-based event in bytes. Rows will be grouped into events smaller than this size if possible. The value has to be a multiple of 256. Available as a from .

• Default value 8192

--disconnect-slave-event-count

• Command line: --disconnect-slave-event-count=#

• Description: Option used by mysql-test for debugging and testing of replication.

--flashback

• Command line: --flashback

• Description: Setup the server to use flashback. This enables the and sets binlog_format=ROW.

--init-rpl-role

• Command line: --init-rpl-role=name

• Description: Set the replication role. From , , , , and , changes the condition for to truncate the to instead use this option, when set to SLAVE. This allows for both and to be set for a primary that is restarted, and no transactions will be lost, so long as --init-rpl-role is not set to SLAVE. In earlier versions, for servers configured with both and , if a primary is just re-started (i.e. retaining its role as primary), it can truncate its binlog to drop transactions which its replica(s) have already received and executed. If this happens, when the replica reconnects, its can be ahead of the recovered primary’s , resulting in an error state where the replica’s state is ahead of the primary’s.

--log-basename

• Command line: --log-basename=name

• Description: Basename for all log files and the .pid file. This sets all log file names at once (in 'datadir') and is normally the only option you need for specifying log files. This is especially recommended to be set if you are using as it ensures that your log file names are not dependent on your host name. Sets names for the , , , and . Note that if you explicity set log file names with any of these other options; , , , , (), , and , these should be placed after --log-basename in the config files. Later settings override earlier settings, so log-basename will override any earlier log file name settings.

--log-bin-trust-routine-creators

• Command line: --log-bin-trust-routine-creators

• Description: Deprecated, use .

--master-host

• Command line: --master-host=name

• Description: Primary hostname or IP address for replication. If not set, the replica thread will not be started. Note that the setting of master-host will be ignored if there exists a valid master.info file.

--master-info-file

• Command line: --master-info-file=name

• Description: Name and location of the file on the replica where the MASTER_LOG_FILE and MASTER_LOG_POS options (i.e. the position on the primary) and most other options are written. The keeps this position updated as it downloads events.

  • See

--master-password

• Command line: --master-password=name

• Description: The password the replica thread will authenticate with when connecting to the primary. If not set, an empty password is assumed. The value in master.info will take precedence if it can be read.

--master-port

• Command line: --master-port=#

• Description: The port the master is listening on. If not set, the compiled setting of MYSQL_PORT is assumed. If you have not tinkered with configure options, this should be 3306. The value in master.info will take precedence if it can be read.

--master-retry-count

• Command line: --master-retry-count=#

• Description: Number of times a replica will attempt to connect to a primary before giving up. The retry interval is determined by the MASTER_CONNECT_RETRY option for the CHANGE MASTER statement. A value of 0 means the replica will not stop attempting to reconnect. Reconnects are triggered when a replica has timed out. See .

• Default Value: 86400 through 10.5, 100000 as of 10.6

--master-ssl

• Command line: --master-ssl

• Description: Enable the replica to .

--master-ssl-ca

• Command line: --master-ssl-ca[=name]

• Description: Master TLS CA file. Only applies if you have enabled .

--master-ssl-capath

• Command line: --master-ssl-capath[=name]

• Description: Master TLS CA path. Only applies if you have enabled .

--master-ssl-cert

• Command line: --master-ssl-cert[=name]

• Description: Master TLS certificate file name. Only applies if you have enabled .

--master-ssl-cipher

• Command line: --master-ssl-cipher[=name]

• Description: Master TLS cipher. Only applies if you have enabled .

--master-ssl-key

• Command line: --master-ssl-key[=name]

• Description: Master TLS keyfile name. Only applies if you have enabled .

--master-user

• Command line: --master-user=name

• Description: The username the replica thread will use for authentication when connecting to the primary. The user must have FILE privilege. If the primary user is not set, user test is assumed. The value in master.info will take precedence if it can be read.

--max-binlog-dump-events

• Command line: --max-binlog-dump-events=#

• Description: Option used by mysql-test for debugging and testing of replication.

--replicate-same-server-id

• Command line: --replicate-same-server-id

• Description: In replication, if set to 1, do not skip events having our server id. Default value is 0 (to break infinite loops in circular replication). Can't be set to 1 if is used. Added as a in .

--sporadic-binlog-dump-fail

• Command line: --sporadic-binlog-dump-fail

• Description: Option used by mysql-test for debugging and testing of replication.

--sysdate-is-now

• Command line: --sysdate-is-now

• Description: Non-default option to alias to to make it safe for . Since 5.0, SYSDATE() has returned a `dynamic' value different for different invocations, even within the same statement.

Replication and Binary Logging Options and System Variables

The options and system variables related to and are described on .

Semisynchronous Replication Options and System Variables

The options and system variables related to are described .

Optimizer Options

Options that are also system variables are listed after:

--record-buffer

• Command line: --record-buffer=#

• Description: Old alias for .

• Removed:

--table-cache

• Command line: --table-open-cache=#

• Description: Removed; use instead.

• Removed:

Optimizer Options and System Variables

Storage Engine Options

--skip-bdb

• Command line: ----skip-bdb

• Description: Deprecated option; Exists only for compatibility with very old my.cnf files.

• Removed:

--external-locking

• Command line: --external-locking

• Description: Use system (external) locking (disabled by default). With this option enabled you can run to test (not repair) tables while the server is running. Disable with . From , , , , and all later version, this effects InnoDB and can be used to prevent multiple instances running on the same data.

MyISAM Storage Engine Options

The options related to the storage engine are described below. Options that are also system variables are listed after:

--log-isam

• Command line: --log-isam[=file_name]

• Description: Enable the , which logs all MyISAM changes to file. If no filename is provided, the default, myisam.log is used.

MyISAM Storage Engine Options and System Variables

Some options and system variables related to the storage engine can be found . Direct links to many of them can be found below.

InnoDB Storage Engine Options

The options related to the storage engine are described below. Options that are also system variables are listed after:

--innodb

• Command line: --innodb=value, --skip-innodb

• Description: This variable controls whether or not to load the InnoDB storage engine. Possible values are ON, OFF, FORCE or FORCE_PLUS_PERMANENT (from ). If set to OFF (the same as --skip-innodb), since InnoDB is the default storage engine, the server will not start unless another storage engine has been chosen with

--innodb-cmp

• Command line: --innodb-cmp

• Description:

• Default: ON

--innodb-cmp-reset

• Command line: --innodb-cmp-reset

• Description:

• Default: ON

--innodb-cmpmem

• Command line: --innodb-cmpmem

• Description:

• Default: ON

--innodb-cmpmem-reset

• Command line: --innodb-cmpmem-reset

• Description:

• Default: ON

--innodb-file-io-threads

• Command line: --innodb-file-io-threads

• Description:

• Default: 4

• Removed:

--innodb-index-stats

• Command line: --innodb-index-stats

• Description:

• Default: ON

• Removed:

--innodb-lock-waits

• Command line: --innodb-lock-waits

• Description:

• Default: ON

--innodb-locks

• Command line: --innodb-locks

• Description:

• Default: ON

--innodb-rseg

• Command line: --innodb-rseg

• Description:

• Default: ON

• Removed:

--innodb-status-file

• Command line: --innodb-status-file

• Description:

• Default: FALSE

--innodb-sys-indexes

• Command line: --innodb-sys-indexes

• Description:

• Default: ON

--innodb-sys-stats

• Command line: --innodb-sys-stats

• Description:

• Default: ON

• Removed:

--innodb-sys-tables

• Command line: --innodb-sys-tables

• Description:

• Default: ON

--innodb-table-stats

• Command line: --innodb-table-stats

• Description:

• Default: ON

• Removed:

--innodb-trx

• Command line: --innodb-trx

• Description:

• Default: ON

InnoDB Storage Engine Options and System Variables

Some options and system variables related to the storage engine can be found . Direct links to many of them can be found below.

Aria Storage Engine Options

Options related to the storage engine are listed below:

Aria Storage Engine Options and System Variables

Some options and system variables related to the storage engine can be found . Direct links to many of them can be found below.

MyRocks Storage Engine Options

The options and system variables related to the storage engine can be found .

S3 Storage Engine Options

The options and system variables related to the storage engine can be found .

CONNECT Storage Engine Options

The options related to the storage engine are described below.

CONNECT Storage Engine Options and System Variables

Some options and system variables related to the storage engine can be found . Direct links to many of them can be found below.

Spider Storage Engine Options

The options and system variables related to the storage engine can be found .

Mroonga Storage Engine Options

The options and system variables related to the storage engine can be found .

TokuDB Storage Engine Options

The options and system variables related to the storage engine can be found .

Vector Options

The options and system variables related to storage engine (beginning with mhnsw) can be found .

Performance Schema Options

The options related to the are described below. Options that are also system variables are listed after:

--performance-schema-consumer-events-stages-current

• Command line: --performance-schema-consumer-events-stages-current

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-stages-history

• Command line: --performance-schema-consumer-events-stages-history

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-stages-history-long

• Command line: --performance-schema-consumer-events-stages-history-long

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-statements-current

• Command line: --performance-schema-consumer-events-statements-current

• Description: Enable the consumer. Use --skip-performance-schema-consumer-events-statements-current to disable.

• Default: ON

--performance-schema-consumer-events-statements-history

• Command line: --performance-schema-consumer-events-statements-history

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-statements-history-long

• Command line: --performance-schema-consumer-events-statements-history-long

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-waits-current

• Command line: --performance-schema-consumer-events-waits-current

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-waits-history

• Command line: --performance-schema-consumer-events-waits-history

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-events-waits-history-long

• Command line: --performance-schema-consumer-events-waits-history-long

• Description: Enable the consumer.

• Default: OFF

--performance-schema-consumer-global-instrumentation

• Command line: --performance-schema-consumer-global-instrumentation

• Description: Enable the global-instrumentation consumer. Use --skip-performance-schema-consumer-global-instrumentation to disable.

• Default: ON

--performance-schema-consumer-statements-digest

• Command line: --performance-schema-consumer-statements-digest

• Description: Enable the statements-digest consumer. Use --skip-performance-schema-consumer-statements-digest to disable.

• Default: ON

--performance-schema-consumer-thread-instrumentation

• Command line: --performance-schema-consumer-thread-instrumentation

• Description: Enable the statements-thread-instrumentation. Use --skip-performance-schema-thread-instrumentation to disable.

• Default: ON

Performance Schema Options and System Variables

Some options and system variables related to the can be found . Direct links to many of them can be found below.

Galera Cluster Options

The options related to are described below. Options that are also system variables are listed after:

--wsrep-new-cluster

• Command line: --wsrep-new-cluster

• Description: Bootstrap a cluster. It works by overriding the current value of wsrep_cluster_address. It is recommended not to add this option to the config file as this will trigger bootstrap on every server start.

Galera Cluster Options and System Variables

Some options and system variables related to can be found . Direct links to many of them can be found below.

Options When Debugging mariadbd

--debug-assert-if-crashed-table

• Description: Do an assert in handler::print_error() if we get a crashed table.

--debug-binlog-fsync-sleep

• Description: --debug-binlog-fsync-sleep=#If not set to zero, sets the number of micro-seconds to sleep after running fsync() on the to flush transactions to disk. This can thus be used to artificially increase the perceived cost of such an fsync().

--debug-crc-break

• Description: --debug-crc-break=#Call my_debug_put_break_here() if crc matches this number (for debug).

--debug-flush

• Description: Default debug log with flush after write.

--debug-no-sync

• Description: debug-no-sync[=#]Disables system sync calls. Only for running tests or debugging!

--debug-sync-timeout

• Description: debug-sync-timeout[=#]Enable the debug sync facility and optionally specify a default wait timeout in seconds. A zero value keeps the facility disabled.

--gdb

• Description: Set up signals usable for debugging.

--silent-startup

• Description: Don't print Notes to the during startup.

--sync-sys

• Description: Enable/disable system sync calls. Syncs should only be turned off (--disable-sync-sys) when running tests or debugging! Replaced by from .

• Removed:

--thread-alarm

• Description: Enable/disable system thread alarm calls. Should only be turned off (--disable-thread-alarm) when running tests or debugging!

Debugging Options and System Variables

Other Options

Options that are also system variables are listed after:

--allow-suspicious-udfs

• Command line: --allow-suspicious-udfs

• Description: Allows use of consisting of only one symbol x() without corresponding x_init() or x_deinit(). That also means that one can load any function from any library, for example exit() from libc.so. Not recommended unless you require old UDFs with one symbol that cannot be recompiled. From , available as a as well.

--bootstrap

• Command line: --bootstrap

• Description: Used by mariadb installation scripts, such as to execute SQL scripts before any privilege or system tables exist. Do no use while an existing MariaDB instance is running.

--chroot

• Command line: --chroot=name

• Description: Chroot mariadbd daemon during startup.

--des-key-file

• Command line: --des-key-file=name

• Description: Load keys for and des_encrypt from given file.

--exit-info

• Command line: --exit-info[=#]

• Description: Used for debugging. Use at your own risk.

--getopt-prefix-matching

• Command line: --getopt-prefix-matching={0|1}

• Description: Makes it possible to disable historical "unambiguous prefix" matching in the command-line option parsing.

• Default: TRUE

• Introduced:

--help

• Command line: --help

• Description: Displays help with many commandline options described, and exits. From , includes deprecation information.