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

Существует множество причин, по которым MariaDB может не запуститься. Эта страница поможет устранить некоторые из наиболее распространенных причин и предоставит решения.

Если вы перепробовали все здесь и все еще нуждаетесь в помощи, вы можете обратиться за помощью на IRC или на форумах — см. Где найти других пользователей и разработчиков MariaDB — или задать вопрос на странице Запуск и остановка MariaDB.

Журнал ошибок и каталог данных

Причина сбоя почти наверняка будет записана в журнале ошибок и, если вы запускаете MariaDB вручную, в консоли. По умолчанию журнал ошибок имеет имя имя_хоста.err и записывается в каталог данных.

Общие расположения:

• /var/log/
• /var/log/mysql
• C:\Program Files\MariaDB x.y\data (x.y обозначает номер версии)
• C:\Program Files (x86)\MariaDB x.y\data (32-разрядная версия на 64-разрядных Windows)

Также возможно, что журнал ошибок был явно записан в другое место. Это часто делается путем изменения системных переменных datadir или log_error в файле настроек. Для получения дополнительной информации об этом см. раздел Файлы настроек ниже.

Быстрый способ получить значения этих системных переменных — выполнить следующие команды:

mysqld --help --verbose | grep 'log-error' | tail -1
mysqld --help --verbose | grep 'datadir' | tail -1

Файлы настроек

Еще один тип файлов, который следует учитывать при устранении неполадок, — это файлы настроек. Файл настроек по умолчанию называется my.cnf. Файлы настроек содержат параметры конфигурации, например, расположение каталога данных, упомянутого выше. Если вы не уверены, где находится файл настроек, см. Настройка MariaDB с файлами настроек: расположения файлов настроек по умолчанию для информации о расположениях по умолчанию.

Вы можете проверить, какие параметры конфигурации MariaDB-сервер будет использовать из файлов настроек, выполнив следующую команду:

mysqld --print-defaults

Вы также можете проверить, выполнив следующую команду:

my_print_defaults --mysqld

См. Настройка MariaDB с файлами настроек: проверка параметров программы для получения дополнительной информации о проверке параметров конфигурации.

Неверный параметр или значение параметра

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

140514 12:19:37 [ERROR] /usr/local/mysql/bin/mysqld: unknown variable 'option=value'

Это с большей вероятностью произойдет при обновлении до новой версии MariaDB. В большинстве случаев файл настроек старой версии MariaDB прекрасно работает с новой версией. Однако иногда в новых версиях MariaDB параметры удаляются или изменяются допустимые значения параметров. Поэтому возможно, что файл настроек перестанет работать после обновления.

Также помните, что имена параметров чувствительны к регистру.

Рассмотрите подробности ошибки. Возможные исправления, как правило, следующие:

• Если параметр полностью неверный, удалите его из файла настроек.
• Если имя параметра изменилось, исправьте имя.
• Если допустимые значения параметра изменились, измените значение параметра на допустимое.
• Если проблема вызвана простой опечаткой, исправьте опечатку.

Невозможно открыть таблицы привилегий

Возможно, будут видны ошибки, похожие на следующие:

System error 1067 has occurred.
Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist

Если возникают такие ошибки, то критически важные системные таблицы отсутствуют или находятся в неправильном месте. Вышеупомянутая ошибка довольно распространена после обновления, если файлы настроек устанавливают basedir или datadir в нестандартное местоположение, но новый сервер использует стандартное местоположение. Поэтому убедитесь, что переменные basedir и datadir правильно установлены.

Если вы не уверены, где находится файл настроек, см. Настройка MariaDB с файлами настроек: расположения файлов настроек по умолчанию для информации о расположениях по умолчанию.

Если системные таблицы действительно отсутствуют, возможно, вам потребуется создать их с помощью mariadb-install-db. Для получения дополнительной информации см. Установка системных таблиц (mariadb-install-db).

Невозможно создать тестовый файл

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

May 13 10:24:28 mariadb3 mysqld[19221]: 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[19221]: 2019-05-13 10:24:28 0 [ERROR] Aborting

Обычно это ошибка разрешений на каталог, в котором создается этот файл. Убедитесь, что весь datadir принадлежит пользователю, запускающему mysqld, обычно mysql. Убедитесь, что каталоги имеют разрешения "x" (выполнение) для владельца. Убедитесь, что у всех родительских каталогов datadir выше есть разрешения "x" (выполнение) для всех (user, group, и other).

После проверки обратитесь к документации по systemd и selinux ниже, или AppArmor.

Невозможно заблокировать файл управления Aria

При запуске MariaDB файл aria_log_control блокируется. Если блокировка не может быть получена, записывается ошибка, похожая на эту:

2023-05-01 16:27:03 0 [ERROR] mariadbd: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds

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

Менее вероятный случай — отсутствие блокировки, что может произойти в каталоге данных NFS с явно отключенной блокировкой.

Невозможно заблокировать ./ibdata1 ошибка 11

Как и в случае с файлом управления Aria, это попытка получить эксклюзивную блокировку ibdata1 системных таблиц InnoDB. Ошибка 11 соответствует системной ошибке «OS error code 11: Resource temporarily unavailable», что означает, что блокировка не может быть создана.

2023-05-01 16:27:34 0 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 11
2023-05-01 16:27:34 0 [Note] InnoDB: Check that you do not already have another mariadbd process using the same InnoDB data or log files.
2023-05-01 16:27:34 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2023-05-01 16:27:35 0 [Note] InnoDB: Starting shutdown...

Как и выше, это указывает на то, что другая инстанция MariaDB уже запущена в каталоге данных.

InnoDB

InnoDB — это, вероятно, компонент MariaDB, который чаще всего вызывает сбой. В журнале ошибок строки, содержащие сообщения InnoDB, обычно начинаются с «InnoDB:».

Невозможно выделить память для буфера пула InnoDB

В типичной установке на выделенном сервере, по крайней мере, 70% памяти должно быть выделено для буфера пула InnoDB; иногда оно может даже достигать 85%. Но будьте очень осторожны: не выделяйте буферу пулу больше памяти, чем он может выделить. Если он не может выделить память, InnoDB будет использовать область подкачки диска, что очень плохо сказывается на производительности. Если подкачка отключена или область подкачки недостаточно велика, InnoDB завершится с ошибкой. В этом случае MariaDB, вероятно, будет пытаться перезапуститься несколько раз, и каждый раз будет записываться сообщение, подобное этому:

140124 17:29:01 InnoDB: Fatal error: cannot allocate memory for the buffer pool

В этом случае вам потребуется добавить больше памяти на ваш сервер/виртуальную машину или уменьшить значение переменных innodb_buffer_pool_size.

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

Повреждение таблицы InnoDB

По умолчанию InnoDB намеренно завершает работу сервера при обнаружении повреждения таблицы. Причина этого поведения заключается в предотвращении распространения повреждений. Однако в некоторых ситуациях доступность сервера важнее целостности данных. По этой причине мы можем избежать этих сбоев, изменив значение innodb_corrupt_table_action на 'warn'.

Если InnoDB завершает работу сервера после обнаружения повреждения данных, он записывает подробное сообщение в журнал ошибок. Первые строки похожи на следующие:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.

Как правило, все же возможно восстановить большую часть поврежденных данных. Для этого перезапустите сервер в режиме восстановления InnoDB и попытайтесь извлечь данные, которые вы хотите сохранить в резервной копии. Вы можете сохранить их в CSV-файл или в таблицу, отличную от InnoDB. Затем перезапустите сервер в обычном режиме и восстановите данные.

MyISAM

Большинство таблиц в базе данных mysql являются таблицами MyISAM. Эти таблицы необходимы для правильной работы MariaDB или даже для запуска.

Сбой MariaDB может привести к повреждению системных таблиц. При стандартных настройках MariaDB просто не запустится, если системные таблицы повреждены. С помощью myisam_recover_options мы можем заставить MyISAM восстановить поврежденные таблицы.

systemd

Если вы используете systemd, есть несколько важных замечаний по поводу сбоев при запуске:

• Если MariaDB настроена для доступа к файлам в /home, /root, или /run/user, то файл единицы systemd по умолчанию запретит доступ к этим каталогам с ошибкой Permission Denied. Это происходит потому, что в файле единицы установлен ProtectHome=true. См. Systemd: Настройка доступа к домашним каталогам для получения информации о том, как обойти эту проблему.

• Файл единицы systemd по умолчанию также устанавливает ProtectSystem=full, что накладывает ограничения на запись в некоторые другие каталоги. Переопределение этого значения с помощью ProtectSystem=off аналогичным образом вернет доступ к этим каталогам.

• Если запуск MariaDB занимает более 90 секунд, то стандартный файл unit systemd приведет к ошибке. Это происходит потому, что значение по умолчанию для параметра TimeoutStartSec составляет 90 секунд. Смотрите Systemd: Настройка таймаута службы Systemd для получения информации о том, как обойти эту проблему.

• Журнал systemd также может содержать полезную информацию об ошибках запуска. Смотрите Systemd: Журнал Systemd для получения дополнительной информации.

См. документацию systemd для получения дополнительной информации о конфигурации systemd.

SELinux

Security-Enhanced Linux (SELinux) — это модуль ядра Linux, предоставляющий фреймворк для конфигурации системы обязательного контроля доступа (MAC) для многих ресурсов системы. Он включен по умолчанию в некоторых дистрибутивах Linux, включая RHEL, CentOS, Fedora и другие аналогичные дистрибутивы Linux. SELinux предотвращает доступ программам к файлам, каталогам или портам, если они не настроены для доступа к этим ресурсам.

Вам может потребоваться устранить проблемы, связанные с SELinux, в таких случаях, как:

• MariaDB использует нестандартный порт.
• MariaDB читает или записывает в некоторые файлы (каталог данных, файлы журналов, файлы параметров и т.д.) по нестандартным путям.
• MariaDB использует плагин, который требует доступа к ресурсам, не используемым в стандартных установках.

Установка состояния SELinux в permissive — это распространённый способ исследования проблем, позволяющий MariaDB работать нормально. permissive предполагается, что каждый раз, когда он должен заблокировать доступ к ресурсу, он создаёт запись в журнале, но на самом деле его не блокирует. Однако существуют ситуации, когда SELinux блокирует доступ к ресурсам даже в режиме permissive.

См. SELinux для получения дополнительной информации.

AppArmor

Добавьте следующее в /etc/apparmor.d/tunables/alias в случае перемещения каталога данных:

alias /var/lib/mysql/ -> /data/mariadb/,

Перезапуск AppArmor:

sudo systemctl restart apparmor