我正在运行一个大型数据库(2GB sql文件)的导入,但是出现问题。 SSH客户端似乎失去了连接,导入似乎冻结了。我使用另一个窗口登录到mysql,并且导入似乎已死,卡在特定的3M行表上。
因此,我尝试了
DROP DATABASE huge_db;
15-20分钟后,什么都没有。在另一个窗口中,我做了:
/etc/init.d/mysqld restart
DROP DB窗口显示消息:SERVER SHUTDOWN。
然后,我实际上重新启动了物理服务器。
重新登录mysql,检查数据库是否仍然存在,再次运行
DROP DATABASE huge_db;
,再次我已经等待了大约5分钟。 >
再次,这是全新安装。
huge_db
是唯一的数据库(系统数据库除外)。我发誓我之前并且很快就删除了这么大的数据库,但是也许我错了。我已经成功删除了数据库。花了大约30分钟。另请注意,当我认为mysqldump导入已死时,我认为我弄错了。终端连接丢失,但是我认为该过程仍在运行。我最有可能杀死了导入中间表(3M行表),并且可能杀死了整个数据库的3/4。令人误解的是,“ top”显示mysql仅使用了3%的内存,而它似乎应该使用更多的内存。
删除数据库最终花费了30分钟,因此,我可能不会已经不得不重新启动服务器,并且可能刚刚等待DROP完成,但是我不知道mysql对通过mysqldump导入的同一数据库的DROP查询会做出怎样的反应。
仍然,问题仍然存在,为什么删除一个2GB数据库需要30分钟以上的时间,而它要做的就是删除所有db文件并从information_schema中删除所有对该数据库的引用?有什么大不了的?
#1 楼
如果您在MySQL中执行此操作,则比终止该过程更安全:$ mysqladmin processlist -u root -p
Enter password:
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example | Sleep | 297 | | |
| 407 | root | localhost | | Query | 0 | | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
ID为174的查询是一个阻止删除“ example”数据库的操作,因此在终止任何进程之前,首先让MySQL尝试终止查询:
$ mysqladmin kill 174
再次运行上面的
processlist
命令以确认它已被终止。如果这不起作用,那么您也许可以考虑消除错误的进程,但是在此之前,您可以尝试重新启动MySQL服务器。
您还可以运行诸如'SHOW FULL'的命令例如,如果您仅安装了MySQL客户端,则在MySQL Shell中输入“ PROCESSLIST”和“ KILL 174”。要点是要避免在外壳中使用'kill'终止进程,除非绝对必要。
通常来说,您可以使用
mysql
或mysqladmin
。不过,您不必经常运行这样的命令;一旦开始定期终止查询,肯定会出现问题,并且最好解决该问题(终止查询过程只是在处理症状)。#2 楼
尽管我以为导入过程已经死了,但是它可能仍在运行。DROP DATABASE
命令可能在数据库运行之前等待数据库完成导入。所以,比
DROP DATABASE
需要很长时间,它可能只是导入。如果其他任何人都读了此文件并试图取消数据库导入并删除数据库,建议您首先找到PID(进程ID ),以便从其他终端导入并运行它:
$ kill [PID]
...其中[PID]是该过程的实际PID。
如果另一个终端仍然连接,您应该立即看到导入停止。
您还可以在phpMyAdmin SQL选项卡中运行
SHOW PROCESSLIST
。结果表显示正在运行的进程,然后单击要杀死的行旁边的'x'应该可以解决问题。然后运行
DROP DATABASE `database_name`;
<
一切都应该干净。
另一个答案表明,杀死mysql内部的进程比从外部执行更好。我尚未测试该答案,但听起来很合理。因此,我将其标记为“可接受的答案”,而不是此答案。
#3 楼
在删除数据库之前,请尝试截断youra数据库中最大的表。在使用MySQL防火墙流量档案时,我看到了非常相似的行为,这极大地帮助了我。评论
根据MySQL文档,“截断操作可以删除并重新创建表,这比逐行删除行要快得多”,因此截断删除没有意义-dev.mysql.com/doc/refman/8.0/zh/ truncate-table.html
– ejoubaud
19年4月16日在13:14
#4 楼
首先想到的是状态Checking Permissions...
发出
DROP DATABASE mydb;
时,将检查/ var / lib / mysql / mydb中的所有内容,以查看是否存在删除每个文件的权限是否具有OS权限。 br /> 有些人认为减少mysql用户数量可能会有所帮助
评论
@BugsBuggy发生这种情况的一种常见方式是,如果另一个进程(例如Web服务器,或者在这种情况下是导入进程)正在运行并连接到数据库。当您发出DROP DATABASE命令时,直到所有连接都关闭,服务器才能继续运行。
– Stefan Magnuson
19年1月4日在10:05