Mysql не запускается - ibdata1 поврежден? - ошибка операционной системы номер 13 - проблема с правами доступа

Ответ 1

Файл не поврежден. Вы можете узнать об источнике этих ошибок с помощью "perror". то есть.

toaster:~ morgo$ perror 13
OS error code  13:  Permission denied

InnoDB имеет обнаружение коррупции (контрольные суммы страниц) и с радостью сообщит вам, была ли эта проблема.

Изменены либо разрешения каталога, либо файл my.cnf был запущен, и он пытается воссоздать файлы данных где-то еще.

Ответ 2

Если вы используете ubuntu или apparmor, вы должны разрешить это изменение в apparmor.

Измените /etc/apparmor.d/usr.sbin.mysqld и измените /var/lib/mysql на новый DATADIR.

Он должен работать.

Ответ 3

Ошибка:

101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Решение SeLinux Безопасность SeLinux:

[[email protected] ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  FALLÓ  ]
[[email protected] ~]#  restorecon -R /var/lib/mysql/
[[email protected] ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  OK  ]
[[email protected] ~]#

Ответ 4

Для меня восстановление контекста безопасности (selinux) сделало трюк

restorecon -R /var/lib/mysql/

Ответ 5

пожалуйста, проверьте это:

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

Ответ 6

У меня была такая же проблема на моем ящике CentOS. После перемещения каталога данных mysql я больше не мог запустить службу, даже когда я скопировал файлы с тем же владельцем и разрешениями.

У меня возникла проблема с контекстом безопасности SELinux. Если вы запустите свой счет CentOS, у него есть хорошие шансы быть включенным и не позволит делать то, что вы хотите с MySQL. Чтобы исправить это:

Сначала сравните старый каталог и новый каталог, используя

ls -Z /var/lib/mysql 

и

ls -Z /new/mysql/dir

Если вы видите какую-либо разницу, это может быть вашей проблемой. Чтобы изменить это:

chcon -R --type=mysql_db_t /new/mysql/dir

Переключатель -R предназначен для рекурсии. Если вам нужно только изменить один файл, вы можете его опустить. Если ваш контекст отличается от моего (возможно, другого дистрибутива), используйте тот, который указан в результате вывода первого (это должно быть 3-е поле материала SELinux)

ls -Z /var/lib/mysql 

Ответ 7

Короче говоря (особенно на RHEL/CentOS/Fedora) попробуйте

getenforce

если он отвечает с помощью Enforcing, у вас есть SELinux и работает. Временно отключите его с помощью setenforce 0 и посмотрите, начинается ли MariaDB сейчас! Скорее всего, особенно в RHEL/CentOS/Fedora.

Подробнее об этом ниже, а также в этой официальной статье.

Обычно

В среде UNIX существует больше вещей, которые могут препятствовать доступу к файлам, а не только прав доступа пользователей.

• Защитные модули, такие как SELinux (см. выше) или AppArmor (как сказал Дэн), могут запретить его
• Списки контроля доступа (ACL) могут быть специально настроены для требуемых файлов/каталогов
• Любая из родительских папок может принадлежать другому пользователю и не имеет x (= "dir access" ), установленного для других

Кроме того, могут быть и другие неожиданные факторы, например...

• mysql datadir устанавливается в место, где mysql не имеет разрешений (см. /etc/my.cnf)
• Mysql может (как ни странно) работать как другой пользователь, или файл может быть просто принадлежащим кому-то другому.

Просто, чтобы упомянуть о вещах с моей головы (не стесняйтесь редактировать/добавлять к этому ответу).

В случае SELinux является "проблемой"

Для постоянного решения вы можете попытаться восстановить соответствующий контекст безопасности,...

restorecon -R /var/lib/mysql/

... или просто отключите SELinux (но подумайте об этом немного до этого), отредактировав конфигурацию (обычно в /etc/selinux/config) и установив SELINUX=disabled, как предложено в следующей статье.

• Здесь официальная справочная страница с сайта mariadb.com: Что делать, если MariaDB не запускается li >
• И вот что-то от redhat.com: MariaDB Изменение местоположения базы данных

Очевидно, что они применимы к MySQL точно так же.

Ответ 8

Когда это появилось для меня, я нашел ответ в файле конфигурации /etc/mysql/my.cnf. Строка datadir не указывала на каталог /var/lib/mysql (где находятся базы данных). После ввода этого пути сервер не запускал никаких проблем.

Ответ 9

У меня была такая же проблема и исправить следующие шаги

Рабочий каталог /var/lib/mysql

Раньше /var/lib/mysql принадлежал неизвестному пользователю

Изменено на mysql

mysql]# chown -R mysql:mysql *

mysql]# service mariadb start

Redirecting to /bin/systemctl start mariadb.service

Работает как шарм

Ответ 10

У меня была такая же проблема на моем ящике CentOS. После перемещения каталога данных mysql я больше не мог запустить службу, даже когда я скопировал файлы с тем же владельцем и разрешениями.

У меня возникла проблема с контекстом безопасности SELinux. Если вы запустите свой счет CentOS, у него есть хорошие шансы быть включенным и не позволит делать то, что вы хотите с MySQL. Чтобы исправить это:

Сначала сравните старый каталог и новый каталог, используя

ls -Z /var/lib/mysql 

и

ls -Z /new/mysql/dir

Если вы видите какую-либо разницу, это может быть вашей проблемой. Чтобы изменить это:

chcon -R --type=mysql_db_t /new/mysql/dir

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

Ответ 11

В моей оценке проблема Селин. И
chcon -R --type=mysql_db_t /new/mysql/dir появляется ошибка:
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
Поэтому я использую команду: chcon -R root:object_r:mysqld_db_t /new/mysql/dir.

Ответ 12

Если у вас есть эта проблема на NAS Synology, вы можете исправить ее, следуя рекомендациям команды поддержки Synology:

Уважаемый пользователь,

Это подтверждено как известная проблема, и мы попытаемся исправить эту проблему в дальнейшем выпуске MariaDB. Извините за неудобства.

Вот обходной путь:

• Попробуйте установить telnet на свои DS с "root" учетной записью и паролем (такими же, как у администратора).
• запустите команду "echo 1 > /var/services/mysql/VERSION"
• открыть пакет MariaDB от DSM приведет к повторному обновлению
• введите пароль БД и нажмите "Обновить", исправив эту проблему.

Дополнительная информация: Форум Synology

Ответ 13

У меня была та же проблема. Много исследований и выяснил это решение. Вам нужно запустить эту команду на ibdata1 sudo shadowprotect -u root | корень

Я не знаю, что это делает... но это сработало для меня.

Удачи.