Warum dauert DROP DATABASE so lange? (MySQL)
Neue CentOS-Installation.
Ich habe einen Import einer großen Datenbank (2 GB SQL-Datei) ausgeführt und hatte ein Problem. Der SSH-Client schien die Verbindung zu verlieren und der Import schien einzufrieren. Ich habe ein anderes Fenster verwendet, um mich bei MySQL anzumelden, und der Import schien tot zu sein, da er in einer bestimmten 3M-Zeilentabelle steckte.
Also habe ich es versucht
DROP DATABASE huge_db;
15-20 Minuten später nichts. In einem anderen Fenster habe ich:
/etc/init.d/mysqld restart
Das DROP DB-Fenster meldete: SERVER SHUTDOWN. Dann habe ich den physischen Server tatsächlich neu gestartet.
Zurück in MySQL angemeldet, überprüft und die Datenbank war noch da, lief
DROP DATABASE huge_db;
wieder und wieder warte ich schon ca. 5 minuten.
Es ist wieder eine Neuinstallation. Das huge_db ist die einzige Datenbank (außer System-Datenbank). Ich schwöre, ich habe db's schon einmal so schnell fallen lassen, aber vielleicht irre ich mich.
Ich habe die Datenbank erfolgreich gelöscht. Es dauerte ungefähr 30 Minuten. Beachten Sie auch, dass ich mich geirrt habe, als ich dachte, der mysqldump-Import sei tot. Die Terminalverbindung wurde unterbrochen, aber ich denke, der Prozess lief noch. Ich habe höchstwahrscheinlich die Import-Mid-Tabelle (die 3M-Zeilentabelle) und wahrscheinlich 3/4 des Weges durch die gesamte Datenbank getötet. Es war irreführend, dass "top" MySQL mit nur 3% des Speichers zeigte, wenn es so aussah, als ob es mehr verwenden sollte.
Das Löschen der Datenbank dauerte 30 Minuten, sodass ich den Server möglicherweise nicht neu starten musste und möglicherweise nur auf den Abschluss des DROP warten musste, aber ich weiß nicht, wie MySQL auf das Abrufen einer DROP-Abfrage reagieren würde die gleiche Datenbank, die es über mysqldump importiert.
Dennoch bleibt die Frage, warum es mehr als 30 Minuten dauert, eine 2-GB-Datenbank zu DROPEN, wenn nur alle Datenbankdateien gelöscht und alle Verweise auf die Datenbank aus information_schema entfernt werden müssen. Was ist die große Sache?
Anstatt den Prozess abzubrechen, wäre es sicherer, wenn Sie dies in MySQL tun würden:
$ 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 |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
Die Abfrage mit der ID 174 blockiert das Löschen der 'Beispiel'-Datenbank. Bevor Sie also Prozesse beenden, lassen Sie MySQL zunächst versuchen, die Abfrage zu beenden:
$ mysqladmin kill 174
Führen Sie den obigen Befehl processlist erneut aus, um zu bestätigen, dass er getötet wurde.
Wenn dies nicht funktioniert, könnten Sie vielleicht versuchen, den fehlerhaften Prozess zu beenden, aber vorher könnten Sie versuchen, den MySQL-Server neu zu starten.
Sie können auch Befehle wie 'SHOW FULL PROCESSLIST' und 'KILL 174' in der MySQL-Shell ausführen, wenn Sie beispielsweise nur den MySQL-Client installiert haben. Der Hauptpunkt besteht darin, zu vermeiden, dass der Prozess mit 'kill' in der Shell abgebrochen wird, sofern dies nicht unbedingt erforderlich ist.
Im Allgemeinen können Sie entweder mysql oder mysqladmin verwenden. Sie sollten solche Befehle jedoch nicht so oft ausführen müssen. Sobald Sie anfangen, Abfragen regelmäßig zu beenden, stimmt definitiv etwas nicht, und Sie sollten dieses Problem besser beheben (das Beenden des Abfrageprozesses behandelt nur das Symptom).
Obwohl ich dachte, dass der Importprozess beendet war, lief er wahrscheinlich noch.
Der Befehl DROP DATABASE Wartete wahrscheinlich darauf, dass der Import der Datenbank abgeschlossen war, bevor sie ausgeführt wurde.
Anstatt DROP DATABASE Lange zu dauern, war es wahrscheinlich nur der Import.
Wenn jemand anderes dies liest und versucht, einen Datenbankimport abzubrechen und die Datenbank zu löschen, empfehle ich, zuerst die PID (Prozess-ID) für den Import zu suchen und diese von einem anderen Terminal aus auszuführen:
$ kill [PID]
... wobei [PID] die tatsächliche PID für den Prozess wäre.
Der Import wird sofort angehalten, wenn das andere Terminal noch angeschlossen ist.
Sie können auch SHOW PROCESSLIST Auf der Registerkarte phpMyAdmin SQL ausführen. Die resultierende Tabelle zeigt laufende Prozesse. Wenn Sie auf das 'x' neben der Zeile klicken, die Sie beenden möchten, sollten Sie den Trick ausführen.
Dann renne
DROP DATABASE `database_name`;
Und alles sollte sauber sein.
Eine andere Antwort deutete darauf hin, dass es besser ist, den Prozess innerhalb von MySQL zu beenden, als ihn von außen auszuführen. Ich habe diese Antwort nicht getestet, aber sie klingt sehr plausibel. Also habe ich es als "akzeptierte Antwort" anstelle dieser markiert.
Versuchen Sie, die größten Tabellen in Ihrer Datenbank abzuschneiden, bevor Sie sie löschen. Ich habe bei der Arbeit mit MySQL-Archiven des Firewall-Verkehrs ein sehr ähnliches Verhalten festgestellt, und dies hat immens geholfen.
Ich hatte das gleiche Problem. Aber diesmal habe ich show processlist überprüft. Es hieß, länger nach Berechtigungen zu suchen. Dann stellte ich fest, dass mysqld_safe als root ausgeführt wurde, während Berechtigungen auf Ordnerebene nur für mysql-Benutzer gelten. Daher habe ich die Abfrage beendet, natürlich hat es lange gedauert, bis sie als beendet bezeichnet wurde, aber ich habe darauf gewartet, dass sie reagiert. Dann hat sie die Abfrage beendet und die Berechtigungen auf Ordnerebene in root geändert, indem ich sie zu group und chmod auf 770 hinzugefügt habe. Dann habe ich ausgeführt die gleiche Drop-Datenbank bla; Es hat bei mir in 2 Sekunden für 20 GB Datenbank funktioniert.
Das erste, was mir in den Sinn kommt, ist der Status Checking Permissions...
Wenn Sie DROP DATABASE mydb; Alles in/var/lib/mysql/mydb wird überprüft, um festzustellen, ob Betriebssystemberechtigungen für das Recht zum Löschen jeder Datei vorhanden sind.
Einige haben das Gefühl, dass die Reduzierung der Anzahl der MySQL-Benutzer hilfreich sein könnte