MySQL:Грешка при премахване на база данни (errno 13; errno 17; errno 39)

Бързо решение

Ако просто искате да премахнете базата данни, независимо от всичко (но моля първо прочетете цялата публикация:грешкатабе дадена по причина , и може да е важно да знаете каква е причината!), можете:

намерете datadir с командата SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
спиране на MySQL сървъра (напр. service mysql stop или rcmysqld stop или подобен в Linux, NET STOP <name of MYSQL service, often MYSQL57 or similar> или чрез SERVICES.MSC на Windows)
Отидете до datadir (това е мястото, където трябва да проучите; вижте по-долу)
премахнете директорията със същото име като базата данни
стартирайте MySQL сървъра отново и се свържете с него
изпълни DROP БАЗА ДАННИ
това е!

Причини за Errno 13

MySQL няма разрешение за запис в родителската директория, в която е mydb папка се намира.

Проверете го с

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb

В Linux това може също да се случи, ако смесите и съпоставите MySQL и AppArmor/SELinux пакети. Това, което се случва, е, че AppArmor очаква mysqld да има своите данни в /path/to/data/dir , и позволява пълно R/W там, но MySQLd е от различна дистрибуция или компилация и всъщност съхранява своите данни на друго място (напр.:/var/lib/mysql5/data/** за разлика от /var/lib/mysql/** ). И така, това, което виждате, е, че директорията има правилни разрешения и собственост и въпреки това все още дава Errno 13, защото apparmor/selinux няма да позволи достъп до него.

За да проверите, проверете системния дневник за нарушения на сигурността, ръчно проверете конфигурацията на apparmor/selinux и/или имитирайте потребителя на mysql и опитайте да отидете в основната директория var, след това cd постепенно, докато не сте в целевата директория, и изпълнете нещо като touch aardvark && rm aardvark . Ако разрешенията и собствеността съвпадат и все пак горното води до грешка при достъп, има вероятност това да е проблем в рамката за сигурност.

Причини за Errno 39

Този код означава "директорията не е празна". Директорията съдържа някои скрити файлове, за които MySQL не знае нищо. За нескрити файлове вижте Errno 17. Решението е същото.

Причини за Errno 17

Този код означава "файлът съществува". Директорията съдържа някакъв MySQL файл, който MySQL не смята за изтриване. Такива файлове биха могли да бъдат създадени от SELECT ... INTO OUTFILE "filename"; команда, където filename нямаше път. В този случай процесът MySQL ги създава в текущата си работна директория, която (тествана на MySQL 5.6 на OpenSuSE 12.3) е директорията с данни на базата данни , напр. /var/lib/mysql/data/nameofdatabase .

Възпроизводимост:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]    

mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)

mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)

mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)

-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.

mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)

Преместете файла(ите) извън (или изтрийте, ако не е необходимо) и опитайте отново. Определете също защо са създадени на първо място – това може да сочи към грешка в някое приложение . Или по-лошо:вижте по-долу...

АКТУАЛИЗАЦИЯ:Грешка 17 като флаг за експлоатиране

Това се случи на Linux система с инсталиран Wordpress. За съжаление клиентът беше под ограничения във времето и не можах нито да изобразя диска, нито да направя истинска криминалистика - преинсталирах цялата машина и Wordpress се актуализира в процеса, така че мога само да кажа, че съм почти сигурни, че са го направили чрез този плъгин .

Симптоми :mysql директорията с данни съдържа три файла с разширение PHP. Чакай, какво?!? -- и вътре във файловете имаше голяма част от base64 код, който беше предаден на base64_decode , gzuncompress и [eval()][2] . Аха . Разбира се, това бяха само първите опити, неуспешните. Сайтът беше добре и наистина pwn3d.

Така че, ако намерите файл във вашия mysql data dir, който причинява грешка 17, проверете го с file полезноста или го сканирайте с антивирусна програма. Или визуално проверете съдържанието му. Не предполагайте, че е там заради някаква безобидна грешка.

(Излишно е да казвам, че за да проверите визуално файла, никога не щракайте двукратно върху него ).

Жертвата в този случай (той имаше някакъв приятел, който „върши поддръжката“) никога не би предположил, че е бил хакнат, докато скрипт за поддръжка/актуализация/който и да е скрипт не стартира DROP DATABASE (не ме питайте защо - не съм сигурен, че дори искам да знам ) и получи грешка. От натоварването на процесора и съобщенията в системния журнал съм доста сигурен, че хостът се е превърнал в спам ферма.

Още една грешка 17

Ако rsync или копирайте между две MySQL инсталации на една и съща версия но различна платформа или файлови системи като Linux или Windows (което е обезкуражено и рисковано, но мнозина го правят въпреки това), и по-специално с различни чувствителност на главни и малки букви настройки, може случайно да се окажете с две версии на същия файл (или данни, индекс или метаданни); кажете Customers.myi и Customer.MYI . MySQL използва единия от тях и не знае нищо за другия (което може да е остаряло и да доведе до катастрофално синхронизиране). При изтриване на базата данни, което също се случва в много mysqldump ... | ... mysql резервни схеми, DROP ще се провали, защото този допълнителен файл (или тези допълнителни файлове) съществува. Ако това се случи, трябва да можете да разпознаете остарелите файлове, които се нуждаят от ръчно изтриване от времето на файла или от факта, че схемата им на случаите е различна от повечето други таблици.

Намиране на директорията с данни

Като цяло можете да намерите директорията с данни, като проверите my.cnf файл (/etc/my.cnf , /etc/sysconfig/my.cnf , /etc/mysql/my.cnf на Linux; my.ini в директорията на MySQL програмни файлове в Windows), под [mysqld] заглавие, като datadir .

Като алтернатива можете да го зададете на самия MySQL:

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)