Не запускается mariadb ubuntu

Обновлено: 01.07.2024

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.

/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 datadir or 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:

Option Files

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

Another potential reason for a startup failure is that an option file contains an invalid option or an invalid option value. In those cases, the error log 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 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:

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 basedir 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 system tables really do not exist, then you may need to create them with mysql_install_db . See Installing System Tables (mysql_install_db) 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 datadir is owned by the user running mysqld , 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 systemd and selinux documentation below, or apparmor.

InnoDB

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 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:

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.

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 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:

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.

MyISAM

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.

systemd

If you are using systemd , 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 set Systemd: Configuring Access to Home Directories for information on how to work around this.

The default systemd unit file also sets
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 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.

SELinux

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.

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, there are situations when SELinux blocks resource accesses even in permissive mode.

MySQL - это одна из самых популярных реляционных систем управления базами данных, которая используется для обеспечения большинства веб-сайтов в интернете. От скорости записи и получения данных из таблиц зависит скорость работы сайта, в целом, так как, если на один запрос будет уходить больше секунды, то это будет тормозить работу php, а в следствии скоро накопиться столько запросов, что сервер не сможет их обработать.

В сегодняшней статье мы поговорим о том, как выполняется оптимизация производительности mysql. Какие программы для этого лучше использовать и как это работает.

Скорость работы MySQL

Оптимизация без аналитики бессмысленна. Перед тем как переходить к оптимизации давайте посмотрим как работает база данных сейчас, есть ли запросы, которые выполняются очень медленно. Все настройки вашего сервиса mysql находятся в файле /etc/my.cnf. Чтобы включить отображение медленных запросов добавьте такие строки в my.cnf, в секцию [mysqld]:

Здесь первая строка включает запись лога медленных запросов, вторая указывает, что минимальное время запроса для внесения его в этот лог - две секунды. Еще можно включить в лог запросы, которые не используют индексы:

Но это уже необязательно для проверки скорости и используется больше для отладки кода и правильности создания таблиц. Дальше перезапустите сервер баз данных и посмотрите лог:

systemctl restart mariadb

tail -f /var/log/mariadb/slow-queries.log

Мы можем видеть, что есть запросы, которые выполняются больше, чем 10 секунд. Это, например, запрос

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Можно его выполнить отдельно, в консоли mysql:

Здесь тоже измеряется время, и мы видим результат - три секунды. Это очень много. И еще ничего, если такие запросы приходят редко, если ваш сайт постоянно под нагрузкой, то тремя секундами вы не отделаетесь, количество необработанных запросов будет расти, а скорость ответа увеличиваться до нескольких минут. Можно пойти двумя путями - оптимизировать код, убрать сложные запросы, или же нужна оптимизация mysql на сервере.

Оптимизация MySQL

Конфигурация MySQL достаточно сложная, но, к счастью, вам не нужно в нее сильно углубляться. Есть специальный скрипт под названием MySQLTunner, который анализирует работу MySQL и дает советы какие параметры нужно изменить и какие значения для них установить. Скрипт поддерживает большинство версий MariaDB, MySQL и Percona XtraDB. Нам понадобится загрузить три файла с помощью wget:

Первый из них - это сам скрипт, написанный на Perl, второй и третий - база данных простых паролей и уязвимостей. Они позволяют обнаружить проблемы с безопасностью. Дальше можно переходить к тестированию. Я использую сервер с настройками mysql по умолчанию, установленными панелью управления VestaCP.

Буквально за несколько минут скрипт выдаст полную статистику по работе MySQL. Количеству запросов, занимаемому объему памяти и эффективности работы буферов. Вы можете ознакомиться со всем этим, чтобы лучше понять в чем причина проблем. Проблемные места обозначены красными восклицательными знаками. Например, здесь мы видим, что размер буфера движка таблиц InnoDB (InnoDB buffer pool) намного меньше, чем должен быть для оптимальной работы:

Все параметры нужно добавлять в /etc/my.cnf. Еще раз замечу, что вы не копируете статью, а смотрите что вам выдала утилита. Начнем с query-cache.

query_cache_size=0
query_cache_type=0
query_cache_limit=1M

Скрипт рекомендует отключить кэш запросов. Query Cache - это кэш вызовов SELECT. Когда базе данных отправляется запрос, она выполняет его и сохраняет сам запрос и результат в этом кэше. И все бы ничего, но при использовании его вместе с InnoDB при любом изменении совпадающих данных кэш будет перестраиваться, что влечет за собой потерю производительности. И чем больше объем кэша, тем больше потери. Кроме того при обновлении кэша могут возникать блокировки запросов. Таким образом, если данные часто пишутся в базу данных - его надежнее отключить.

Оба параметра устанавливают размер памяти, которая используется для внутренних временных таблиц MySQL. Утилита рекомендует использовать объем больше 16 мегабайт, просто установите это ваше значение для обоих переменных, если у вас достаточно памяти, то можно выделить 32 или даже 64. Но важно чтобы оба значения совпадали, иначе будет использоваться минимальное.

Этот параметр отвечает за количество потоков, которые будут закэшированны. После того, как работа с подключением будет завершена, база данных не разорвет его, а закэширует, если количество кэшированных потоков не превышает ограничение. Утилита рекомендует больше четырех, например, 16.

Указывает, что не нужно пытаться определить доменное имя для подключений извне. Ускоряет работу, так как не тратится время на DNS запросы.

Этот параметр определяет размер буфера InnoDB в оперативной памяти, от этого размера очень сильно зависит скорость выполнения запросов. Значение зависит от размера ваших таблиц и количества данных в них. Если памяти недостаточно, запросы будут обрабатываться дольше. У меня используется стандартный объем 128, а нужно больше 652.

Размер файла лога innodb должен составлять 25% от размера буфера. В случае 800 мегабайт это будет 200М. Но тут есть одна проблема. Чтобы изменить размер лога нужно выполнить несколько действий. Поскольку мы изменили все нужные параметры перейдем к перезагрузке сервера. Для нашего лога нужно остановить сервис:

systemctl stop mariadb

Затем переместите файлы лога в /tmp:

mv /var/lib/mysql/ib_logfile[01] /tmp

И запустите сервис:

systemctl start mariadb

systemctl status mariadb

Тестирование результата

Готово оптимизация базы данных mysql завершена, теперь тестируем тот же запрос через клиент mysql:

> USE база_данных;
> SELECT option_name, option_value FROM wpfc_options WHERE autoload = 'yes';

Первый раз он выполняется долго, может даже дольше чем обычно, но все последующие разы буквально мгновенно. Результат с более 3 секунд до 0,15. А если брать статистику из slow-log, то от более 12. Если в выводе утилиты для вас были предложены и другие оптимизации, то их тоже стоит применить.

Выводы

Как видите, оптимизация mysql это достаточно просто благодаря такому скрипту, но, в то же время, такая операция может очень сильно помочь, особенно высоконагруженным проектам. Еще лучше ускорить работу может только оптимизация запросов mysql. Не забывайте время от времени проверять параметры, чтобы быть уверенным что все в порядке. Если у вас остались вопросы, спрашивайте в комментариях!

На завершение лекция про производительность MySQL от Percona:

MySQL или MariaDB - это один из самых популярных движков баз данных, который используется для обеспечения работы большинства веб-сайтов в интернете, а также множества других проектов.

Иногда случается, что из-за после изменения настроек или по какой-либо другой причине mysql не запускается. Это довольно серьезная проблема, особенно, когда такая ситуация случается на сервере публичного проекта. В этой статье мы рассмотрим основные причины почему может возникать такая проблема, а также пути решения. В качестве примера будет использоваться Mariadb и Ubuntu.

Почему не запускается MySQL сервер?

Если вы используете systemd для запуска сервисов, то получите такую ошибку:

failed to start mysql server или job for mysql failed because the control proccess exited

Синтаксические ошибки в конфигурационном файле;
Неверные настройки;
Недостаточное количество оперативной памяти на сервере;
Проблемы с правами доступа;
Сетевой порт уже занят;
Таблицы баз данных повреждены;

Дальше мы рассмотрим основные пути решения этих проблем. Но сначала нам нужно выяснить почему не запускается программа. Гадать на кофейной гуще и перебирать все возможные методы решения можно очень долго, самым эффективным решением будет посмотреть какие ошибки выдает сама программа.

Что делать если не запускается MySQL?

Первым делом, если вы меняли настройки в конфигурационном файле надо проверить его на ошибки. Встроенной утилиты для таких целей нет, но можно запустить mysql daemon с опцией --help:

/usr/sbin/mysqld --help --verbose

systemctl restart mariadb

Если же это не сработало и вы все еще получаете ошибку, посмотрите лог загрузки systemd для этого сервиса:

systemctl status -l mariadb

Иногда здесь тоже можно найти полезную информацию, но в данном случае ничего нет. Следующий шаг - просмотр лога mysql. Если лог еще не включен, включаем его добавив такую строчку в /etc/mysql/my.cnf в секцию [mysqld]:

sudo vi /etc/mysql/my.cnf

[mysqld]
log-error=/var/log/mysql/error.log
Затем снова пытаемся запустить сервис и смотрим на появившиеся в логе ошибки:

tail -f /var/log/mysql/error.log

1. Изменение размера буфера innodb

Если вы измените значение директивы innodb_buffer_pool_size в большую или меньшую сторону пока сервис работает, то перезапустить вы его уже не сможете. Перед тем как менять значение директивы остановите mysql:

sudo systemctl stop mariadb

Затем удалите старые логи innodb или просто их переименуйте:

sudo mv /var/lib/mysql/ib_logfile0
sudo mv /var/lib/mysql/ib_logfile1

И только после этого можете снова запускать сервис, он запустится с новыми настройками размера буфера. Только будьте аккуратны с выбором размера. При слишком большом размере может не хватить памяти для запуска, так как весь буфер хранится в ОЗУ.

sudo systemctl start mariadb

2. Ошибка Permission denied

MySQL хранит файлы базы данных на диске. У движка базы данных должен быть полный доступ к папке, в которой хранятся эти файлы. По умолчанию в Ubuntu это /var/lib/mysql/. Все файлы в этой папке должны принадлежать пользователю mysql:

ls -l /var/lib/mysql/

Если это не так, исправляем командой:

sudo chown -R mysql:mysql /var/lib/mysql/

3. Ошибка Address already in use

MySQL может использовать файловый сокет Linux или же сетевой сокет, тогда база данных будет доступна другим программам на порту 3306. Если сейчас уже запущен другой процесс mysql или какой-либо другой процесс занимает этот порт вы получите ошибку Address already in use. Чтобы ее решить смотрим какой процесс использует порт:

sudo ss -lptn 'sport = :3306'

Например, здесь мы видим, что запущен другой экземпляр mysql с PID 11240. Вы можете его завершить с помощью kill:

sudo kill -TERM 11240

Теперь база данных запуститься.

4. Ошибка corrupt database page Mysql

Если mysql завершился некорректно из-за недостатка памяти или других проблем, например, проблем с файловой системой, то таблицы innodb могут быть повреждены - corrupt database page. Это происходит не так часто. При такой проблеме вы увидите такую запись в логе:

Нам необходимо запустить mysql в режиме восстановления, в котором все повреждения таблиц будут игнорироваться. Для этого добавляем в конфигурационный файл /etc/mariadb/my.cnf строку:

sudo vi /etc/mariadb/my.cnf

Затем запускаем mysql:

systemctl start mariadb

mysqlcheck -u root --auto-repair --all-databases

Готово. Теперь возвращаемся в конфигурационный файл и комментируем или удаляем строку innodb_force_recovery.

После этого можно перезапустить mysql и сервис будет работать в обычном режиме:

sudo systemctl restart mariadb

Выводы

Начинаю знакомство с Astra Linux. Установили Astra Linux 1.6 Смоленск, установила mariadb-server и mariadb-client; enable, start, status, в результате:

Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; .
Active: inactive (dead) .

Подскажите, пожалуйста, в каком направлении копать.

journalctl --unit mariadb тоже ничего не дает?

/etc/my.ini - посмотри, куда ведут пути к логам
посмотри эти логи
если нет файлов - создай и chown mysql:mysq на него
рестартани сервис
посмотри логи

$ sudo journalctl --unit mariadb
-- Logs begin at Fri 2019-10-25 11:27:43 MSK, end at Fri 2019-10-25 12:22:50 MSK. --
окт 25 11:27:49 server systemd[1]: Starting MariaDB database server.
окт 25 11:27:52 server systemd[1]: Started MariaDB database server.

Файла /etc/my.ini нет, но в /etc/mysql/ лежат несколько конфигурационных файлов, в файле /etc/mysql/mariadb.conf.d/50-server есть строчка: 'log_error = /var/log/mysql/error.log' Но создание указанного файла (с необходимыми правами доступа) не помогло - лог не появился, вывод не изменился:

окт 25 12:48:49 server systemd[1]: Starting MariaDB database server.
окт 25 12:48:49 server systemd[1]: Started MariaDB database server.

в файле /etc/mysql/mariadb.conf.d/50-server есть строчка: 'log_error = /var/log/mysql/error.log'

вроде оно.
проверь еще, существуют ли файлы по путям basedir и datadir из этого файла.
А вообще, сначала надо определиться откуда mysql настройки берет, там настраивать и смотреть вот это все.

а что там с уровнем контроля целостности у залогиненого пользователя? мандатный контроль включен ли?

basedir и datadir существуют, владелец datadir - mysql.

Настройки - в каталоге /etc/mysql/ - других файлов настроек для mariadb или mysql я не нашла.

Была попытка указать 'PDPLabel= ', она тоже не принесла результата, после чего мандатный контроль выключила совсем, чтобы не мешал - не помогло :(

Читайте также: