MySQL:删除数据库时出错(errno 13；errno 17；errno 39)

Question

我删除数据库失败:

mysql> 删除数据库 mydb；
错误 1010 (HY000):删除数据库时出错(不能 rmdir './mydb'，errno: 39)

目录 db/mydb 存在于 mysql 树中但没有表:

# ls -l db/mydb
-rw-rw---- mysql mysql HIS_STAT.MYD
-rw-rw---- mysql mysql HIS_STAT.MYI

我该怎么办？

Answer 1

快速解决

如果您无论如何只想删除数据库(但请先阅读整篇文章:错误是由于的原因给出的，知道原因可能很重要!)，您可以:

使用命令SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';

查找数据目录

停止 MySQL 服务器(例如 Linux 上的service mysql stop或rcmysqld stop或类似的，Windows 上的NET STOP <name of MYSQL service, often MYSQL57 or similar>或通过SERVICES.MSC)

转到数据目录(这是您应该调查的地方；见下文)

删除与数据库

同名的目录

再次启动MySQL服务器并连接到它

执行删除数据库

就是这样!

错误 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。如果权限和所有权匹配，但上述内容产生访问错误，则很可能是安全框架问题。

"EASY FIX" considered harmful

I have happened upon an "easy fix" suggested on a "experts forum" (not Stack Overflow, thank goodness), the same "fix" I sometimes find for Web and FTP problems -- chown 777. PLEASE NEVER DO THAT. For those who don't already know, 777 (or 775, or 666) isn't a magic number that somehow MySQL programmers forgot to apply themselves, or don't want you to know. Each digit has a meaning, and 777 means "I hereby consent to everyone doing whatever they want with my stuff, up to and including executing it as if it were a binary or shell script". By doing this (and chances are you won't be allowed to do this on a sanely configured system),

• you risk several security conscious programs to refuse to function anymore (e.g. if you do that to your SSH keys, goodbye SSH connections; etc.) since they realize they're now in a insecure context.
• you allow literally everyone with any level of access whatsoever to the system to read and write your data, whether MySQL allows it or not, unbeknownst to MySQL itself - i.e. it becomes possible to silently corrupt whole databases.
• the above might sometimes be done, in exceedingly dire straits, by desperate and knowledgeable people, to gain access again to an otherwise inaccessible screwed MySQL installation (i.e. even mysqladmin no longer grants local access), and will be immediately undone as soon as things get back to normal - it's not a permanent change, not even then. And it's not a fix to "one weird trick to be able to drop my DB".

(needless to say, it's almost never the real fix to any Web or FTP problems either. The fix to "Of late, the wife's keys fail to open the front door and she can't enter our home" is 'check the keys or have the lock repaired or replaced'; the admittedly much quicker chown 777 is "Just leave the front door wide open! Easy peasy! What's the worst that might happen?")

错误 39 的原因

此代码的意思是“目录不为空”。该目录包含一些 隐藏的文件，MySQL 对此一无所知。非隐藏文件见Errno 17，解决方法同上。

错误 17 的原因

此代码表示“文件存在”。该目录包含一些 MySQL 文件，MySQL 不想删除这些文件。此类文件可能是由 SELECT ... INTO OUTFILE "filename";命令创建的，其中 filename没有路径。在这种情况下，MySQL 进程在其当前工作目录中创建它们，该目录(在 OpenSuSE 12.3 上的 MySQL 5.6 上测试)是数据库的数据目录，例如 /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 作为漏洞利用标志

这发生在安装了 Wordpress 的 Linux 系统上。不幸的是，客户受到时间限制，我既无法对磁盘进行镜像，也无法进行真正的取证 - 我重新安装了整个机器并且 Wordpress 在此过程中得到了更新，所以我只能说我几乎可以肯定他们是通过 this plugin。

症状 : mysql数据目录包含三个扩展名为 PHP 的文件。等等，什么？!？ - 在文件中，有大量 base64 代码被传递给 base64_decode、 gzuncompress和 [eval()][2]。啊哈。当然，这些只是第一次尝试，没有成功。该网站一直很好，真正的 pwn3d。

因此，如果您在 mysql 数据目录中发现导致错误 17 的文件， 请使用file实用程序进行检查或使用防病毒软件对其进行扫描。或目视检查其内容。 不要假设它是一些无害的错误。

(不用说，要目视检查文件，切勿双击它)。

在这种情况下，受害者(他有一些 friend “做维护”)永远不会猜到他被黑了，直到维护/更新/任何脚本运行 DROP DATABASE(不要问我为什么 - 我不确定甚至我想知道)并出现错误。从 CPU 负载和系统日志消息来看，我相当肯定主机已成为垃圾邮件群。

又一个错误 17

如果您 rsync或在两个相同版本但不同平台或文件系统(如 Linux 或 Windows)的 MySQL 安装之间进行复制(这是不鼓励且有风险的，但许多人仍然这样做)，特别是使用不同的 case sensitivity设置，您可能会意外地得到 同一文件(数据、索引或元数据)的两个版本；说 Customers.myi和 Customer.MYI。 MySQL 使用其中一个并且对另一个一无所知(这可能已经过时并导致灾难性的同步)。当删除数据库时，这也发生在许多 mysqldump ... | ... mysql备份方案中， DROP将失败，因为存在额外的文件(或那些额外的文件)。如果发生这种情况，您应该能够从文件时间或从它们的案例方案与大多数其他表不同的事实中识别需要手动删除的过时文件。

查找数据目录

通常，您可以通过检查 my.cnf文件(Linux 上为 /etc/my.cnf、 /etc/sysconfig/my.cnf、 /etc/mysql/my.cnf；Windows 中 MySQL 程序文件目录中的 my.ini)，在 [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)