Я бьюсь головой об этом уже несколько дней. У нас есть двухнедельные ежедневные снимки резервных копий нашего производственного каталога данных mysql (то есть фактические двоичные файлы, а не дампы sql), и мне нужно восстановить таблицу из одной из резервных копий, чтобы мы могли сравнить ее с тем, что у нас есть сейчас .
Итак, я создал каталог фиктивной схемы, извлек соответствующие файлы таблиц (.MYI, .MYD и .frm) и перезапустил mysql. Он появляется, я могу «показать таблицы», но если я попытаюсь каким-либо образом с ним взаимодействовать («desc tablename», «select ...» и т. Д.), Я получаю:
Can't find file: './schema_name/table_name.frm' (errno: 13)
[ed: настоящие имена очищены]
Errno 13 - это разрешения, поэтому я все перепроверил. Каталог и файлы имеют того же владельца и группу (mysql: mysql), что и все другие схемы. У них тоже пермы одинаковые (700 в каталоге, 660 в файлах). Глядя на "ls -n", uid также точно совпадают.
Совсем недавно я попытался сделать полное извлечение другой резервной копии, а затем связать ее с каталогом данных mysql (на этом томе недостаточно места для извлечения всего файла), и я получаю ту же ошибку. Я также попытался указать каталог данных mysql в my.cnf на каталог, содержащий резервную копию и перезапуск. Он построил таблицы mysql, которые должны были быть там, но я все равно получил ту же ошибку.
Единственное, что я могу найти через поиск в Google, - это людей, у которых возникла эта проблема из-за фактических ошибок владения или прав доступа, что, похоже, не относится ко мне. Я также нашел несколько замечаний по поводу переменной env UMASK, которая может привести к этой ошибке, но я считать это связано с новыми установками, а это не так.
Вы используете что-то вроде selinux или другого подобного пакета? Я бы предложил отключить это (или изменить политику безопасности), чтобы увидеть, не мешает ли что-то MySQL доступу к файлам.
[править] Если это так, проверьте системный журнал, чтобы узнать, не блокирует ли selinux выполнение каких-либо действий mysql. Если это SELinux, мне сказали, что это может отключить его, чтобы вы могли проверить эту теорию.
/usr/sbin/setenforce Permissive
strace - ваш друг в этом случае. Найдите идентификатор процесса вашего mysql, затем запустите:
strace -efile -f -o /tmp/mysql.log -p $pid
В другом окне выполните действия, вызывающие ошибку. Затем вы можете нажать ctrl-c, чтобы убить strace. Если вы посмотрите в /tmp/mysql.log, вы увидите, что вызвало проблему.
Кроме того, я действительно рекомендую вам не полагаться на копирование двоичных файлов данных. Дампы SQL намного надежнее и гибче. Кроме того, похоже, вы используете MyISAM. Я бы действительно не рекомендовал использовать их, если вам не нужны данные в них. InnoDB имеет множество преимуществ перед MyISAM.
Недавно у меня была эта проблема, и я решил ее, изменив разрешение каталога базы данных для каждого каталога базы данных, расположенного в /var/lib/mysql как это:
PWD: /var/lib/mysql
chmod u+x schema_db1
chmod u+x schema_db2
chmod u+x schema_db3
chmod u+x schema_db4
Перезагрузите движок MySQL и снова работает! Я надеюсь, что это сработает для вас.
Когда я раньше сталкивался с этой проблемой, это было потому, что файлы не принадлежали пользователю mysql, независимо от его разрешений. chmod 777 в любом случае это не то, что вы хотите запускать в каталоге данных, редактируемом сервером.
Проверьте, какое имя пользователя настроено в /etc/my.cnf
[mysqld]
bind-address=<IP Address>
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=<username>
Может быть корень или который вы настроили. Я изменился на корень и это начало работать у меня.
Затем запустите mysql
service mysqld stop
service mysqld start
У меня была эта ошибка, SELinux отказывал в доступе к файлам (они предоставлены другим сервером, который разбился - поэтому они были 'unlimited_u: object_r: home_root_t'), поэтому я сделал это, чтобы восстановить правильный контекст:
semanage fcontext -a -t mysqld_db_t -s system_u "/var/lib/mysql/<my dbname>(/.*)?"
restorecon -vFr /var/lib/mysql/<my dbname>
Это устранило проблему :)