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 Where to find other MariaDB users and developers - or ask a question at the Starting and Stopping MariaDB page.
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.
It's also possible that the error log has been explicitly written to another location. This is often done by changing the
log_error system variables in an option file. See Option Files below for more information about that.
A quick way to get the values of these system variables is to execute the following commands:
mysqld --help --verbose | grep 'log-error' | tail -1 mysqld --help --verbose | grep 'datadir' | tail -1
Another kind of file to consider when troubleshooting is option files. 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 Configuring MariaDB with Option Files: Default Option File Locations 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 Configuring MariaDB with Option Files: Checking Program Options for more information on checking configuration options.
140514 12:19:37 [ERROR] /usr/local/mysql/bin/mysqld: unknown variable 'option=value'
This is more likely to happen when you upgrade to a new version of MariaDB. In most cases the option file 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 option file 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:
It is possible to see errors similar to the following:
System error 1067 has occurred. Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist
If errors like this occur, then critical system tables are either missing or are in the wrong location. The above error is quite common after an upgrade if the option files set the
datadir to a non-standard location, but the new server is using the default location. Therefore, make sure that the
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.
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:
May 13 10:24:28 mariadb3 mysqld: 2019-05-13 10:24:28 0 [Warning] Can't create test file /usr/local/data/mariadb/mariadb3.lower-test May 13 10:24:28 mariadb3 mysqld: 2019-05-13 10:24:28 0 [ERROR] Aborting
This is usually a permission error on the directory in which this file is being written. Ensure that the entire
datadir is owned by the user running
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 (
InnoDB is probably the MariaDB component that most frequently causes a crash. In the error log, lines containing InnoDB messages generally start with "InnoDB:".
In a typical installation on a dedicated server, at least 70% of your memory should be assigned to InnoDB buffer pool; 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:
140124 17:29:01 InnoDB: Fatal error: cannot allocate memory for the buffer pool
In that case, you will need to add more memory to your server/VM or decrease the value of the innodb_buffer_pool_size variables.
Remember that the buffer pool will slightly exceed that limit. Also, remember that MariaDB also needs allocate memory for other storage engines and several per-connection buffers. The operating system also needs memory.
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 innodb_corrupt_table_action 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:
InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 7. InnoDB: You may have to recover from a backup.
Generally, it is still possible to recover most of the corrupted data. To do so, restart the server in InnoDB recovery mode 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.
Most tables in the mysql database are MyISAM tables. These tables are necessary for MariaDB to properly work, or even start.
A MariaDB crash could cause system tables corruption. With the default settings, MariaDB will simply not start if the system tables are corrupted. With myisam_recover_options, we can force MyISAM to repair damaged tables.
If you are using
systemd, then there are a few relevant notes about startup failures:
/run/user, then the default systemd unit file will prevent access to these directories with a
Permission Deniederror. This happens because the unit file set
ProtectHome=true. See Systemd: Configuring Access to Home Directories for information on how to work around this.
ProtectSystem=offin the same way as above will restore access to these directories.
TimeoutStartSecoption is 90 seconds. See Systemd: Configuring the Systemd Service Timeout for information on how to work around this.
See systemd documentation for further information on systemd configuration.
Security-Enhanced Linux (SELinux) is a Linux kernel module that provides a framework for configuring mandatory access control (MAC) system for many resources on the system. It is enabled by default on some Linux distributions, including RHEL, CentOS, Fedora, and other similar Linux distribution. 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:
See SELinux for more information.
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.