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

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

30 голосов
/ 11 октября 2010

Выключение сервера из-за сбоя питания.
Mysql сейчас не запускается.
Диск не переполнен.Системный журнал ниже 

Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31  InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.

Ответы [ 14 ]

94 голосов
/ 28 января 2013

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

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

Это должно работать.

18 голосов
/ 01 декабря 2010

Ошибка: 

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: 

[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  FALLÓ  ]
[root@localhost ~]#  restorecon -R /var/lib/mysql/
[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  OK  ]
[root@localhost ~]#
16 голосов
/ 27 октября 2010

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

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

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

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

13 голосов
/ 03 января 2013

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

restorecon -R /var/lib/mysql/

9 голосов
/ 11 июня 2014

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

chown -R mysql:mysql /var/lib/mysql
5 голосов
/ 04 сентября 2013

У меня была точно такая же проблема на моей коробке 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
4 голосов
/ 31 октября 2014

Короче говоря, (особенно на 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, как предложено в следующей статье.

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

3 голосов
/ 31 мая 2017

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

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

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

Изменено на mysql

mysql]# chown -R mysql:mysql *

mysql]# service mariadb start

Redirecting to /bin/systemctl start mariadb.service

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

2 голосов
/ 18 декабря 2012

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

1 голос
/ 11 сентября 2018

Если вы используете SEL Linux

Интал semanage

yum whatprovides /usr/sbin/semanage вы получите policycoreutils-python-2.5-22.el7.x86_64

См. Контекст безопасности mysqld

После установки yum install policycoreutils-python вы можете просто посмотреть, какой другой контекст безопасности имеет mysqld. 

semanage fcontext -l | grep mysqld
/etc/mysql(/.*)?                       all files    system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)?                  all files    system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.*                       regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files    system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)?                  all files    system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)?                 all file     system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)?                 all files    system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)?                regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.*         regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.*       regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.*      regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf                           regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf                        regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd                         regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld                    regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe                   regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade                 regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld              regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock             socket       system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper    regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf                  regular file unconfined_u:object_r:mysqld_home_t:s0

Здесь вы видите весь контекст для mysqld краткий список с объяснением

  1. mysqld_etc_t - файлы конфигурации
  2. mysqld_db_t - файлы базы данных данных
  3. mysqld_log_t - файлы журналов
  4. mysqld_exec_t - исполняемые файлы

Поэтому, если у вас неправильный контекст безопасности в ваших файлах, вы получаете разрешение, в котором отказано (ошибка 13)

Решение 

chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

Но проверьте и "нормальные" разрешения. У меня была эта проблема с centos. Вы должны systemctl restart mysql для изменений.

Страница:
...