MySQL：删除数据库时出错（错误13;错误号17;错误号39）

时间：2012-08-30 12:37:03

标签： mysql errno

我没有删除数据库：

mysql> drop database mydb;
ERROR 1010 (HY000): Error dropping database (can't 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

我该怎么办？

7 个答案:

答案 0 :(得分：101)

快速修复

如果您只是想放弃数据库而不管什么（但请首先阅读整篇文章：错误是出于某种原因，这可能很重要要知道原因是什么！），你可以：

  • 使用命令SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
    • 查找datadir
  • 在Linux上停止MySQL服务器（例如service mysql stop或rcmysqld stop或类似内容，NET STOP <name of MYSQL service, often MYSQL57 or similar>或在Windows上通过SERVICES.MSC
  • 转到datadir（这是您应该调查的地方;见下文）
  • 删除与数据库同名的目录
  • 再次启动MySQL服务器并连接到它
  • 执行DROP DATABASE
  • 那就是它！

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

的原因

此代码表示＆＃34;目录不为空＆＃34;。该目录包含MySQL一无所知的隐藏文件。对于非隐藏文件，请参阅Errno 17.解决方案是相同的。

Errno 17

的原因

此代码表示＆＃34;文件存在＆＃34;。该目录包含一些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在此过程中得到了更新，所以我只能说我几乎没有 / em>确定他们是通过this plugin完成的。

症状：mysql数据目录包含三个扩展名为PHP的文件。 等等，什么？！？ - 在文件中有大量的base64代码传递给base64_decode，gzuncompress和[eval()][2]。 阿哈。当然这些只是第一次尝试，不成功的尝试。这个网站真的非常真实pwn3d。

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

（不用说，为了直观地检查文件，永远不要双击它）。

在这种情况下受害者（他有一些朋友＆＃34;做维护＆＃34;）绝不会猜到他被黑客攻击，直到维护/更新/任何脚本运行DROP DATABASE （不要问我为什么 - 我甚至不确定我想知道）并且出错了。从CPU负载和系统日志消息中，我非常肯定主机已成为垃圾邮件场。

又一个错误17

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

查找data-dir

通常，您可以通过检查Linux上的my.cnf文件（/etc/my.cnf，/etc/sysconfig/my.cnf，/etc/mysql/my.cnf; MySQL中的my.ini来查找数据目录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)

答案 1 :(得分：27)

在我的情况下，这是由于'lower_case_table_names'参数。

当我尝试删除包含带有lower_case_table_names参数的大写表名的数据库时，抛出的错误号39被启用。

通过将小写参数更改恢复为先前状态来解决此问题。

答案 2 :(得分：5)

只需转到/opt/lampp/var/mysql

您可以找到database名称。 打开该文件夹。删除其中的任何文件

现在来phpmyadmin并删除database

答案 3 :(得分：2)

至于 ERRORCODE 39 ，您绝对可以删除磁盘上的物理表文件。位置取决于您的操作系统分发和设置。在Debian上它通常位于/ var / lib / mysql / database_name /所以做一个：

rm -f /var/lib/mysql/<database_name>/

然后从您选择的工具中删除数据库或使用命令：

DROP DATABASE <database_name>

答案 4 :(得分：0)

在我的情况下，数据库文件夹中还有一个不属于数据库的附加文件。在删除所有触发错误的表后，Mysql发现文件夹不为空。我删除了文件，并且放置数据库工作正常。

答案 5 :(得分：0)

这就是我解决的方法：

mysql> DROP DATABASE mydatabase;
ERROR 1010 (HY000): Error dropping database (can't rmdir '.\mydatabase', errno: 13)
mysql>

我去了以下目录：C:\...\UniServerZ\core\mysql\data\mydatabase。

mysql> DROP DATABASE mydatabase;
ERROR 1008 (HY000): Can't drop database 'mydatabase'; database doesn't exist

答案 6 :(得分：-2)

在Linux中，只需右键单击“ / var / lib / mysql”，然后（以adminstrator身份打开），在mysql文件夹中找到与您的数据库名称相对应的文件夹并将其删除。 而已。 数据库已删除。

相关问题
最新问题