What to Do if MariaDB Doesn't Start
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 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.
- 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
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.
Invalid Option or Option Value
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:
- If the option is completely invalid, then remove it from the option file.
- 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:
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.
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 Buffer Pool
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:
- If MariaDB is configured to access files under
/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.
- The default systemd unit file also sets ProtectSystem=full, which places restrictions on writing to a few other directories. Overwriting this with
ProtectSystem=offin the same way as above will restore access to these directories.
- If MariaDB takes longer than 90 seconds to start, then the default systemd unit file will cause it to fail with an error. This happens because the default value for the
TimeoutStartSecoption is 90 seconds. See Systemd: Configuring the Systemd Service Timeout for information on how to work around this.
- The systemd journal may also contain useful information about startup failures. See Systemd: Systemd Journal for more information.
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:
- 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.
See SELinux for more information.