DROP DATABASEに時間がかかるのはなぜですか?(MySQL)


46

新しいCentOSインストール。

大きなDB(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(システムDBS以外の)唯一のDBです。私は以前にこれほど速くdbをドロップしたことを誓いますが、多分間違っています。

データベースを正常に削除しました。30分ほどかかりました。また、mysqldumpのインポートが死んだと思ったとき、私は間違っていたと思うことに注意してください。端末の接続は失われましたが、プロセスはまだ実行中だったと思います。インポート中テーブル(3M行テーブル)を削除した可能性が最も高く、おそらくデータベース全体の3/4を削除しました。「top」がmysqlを使用してメモリを3%しか使用していないことを示していたのに、それ以上使用する必要があるように思えたのは誤解を招きました。

DBの削除には30分かかりました。そのため、サーバーを再起動する必要がなく、DROPが完了するのを待つこともできましたが、DROPクエリの取得に対するmysqlの反応はわかりません。 mysqldump経由でインポートするのと同じdb。

それでも、疑問が残ります。すべてのdbファイルを削除し、information_schemaからDBへのすべての参照を削除するだけで2 GBのデータベースを削除するのに30分以上かかるのはなぜですか?大したことは何ですか?

回答:


73

プロセスを強制終了するよりも、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サーバーを再起動してみてください。

たとえば、MySQLクライアントのみがインストールされている場合、MySQLシェルで「SHOW FULL PROCESSLIST」や「KILL 174」などのコマンドを実行することもできます。主なポイントは、絶対に必要でない限り、シェルで「kill」を使用してプロセスを強制終了しないことです。

一般的に、mysqlまたはのいずれかを使用できますmysqladmin。ただし、このようなコマンドを頻繁に実行する必要はありません。クエリを定期的に削除し始めたら、何か間違いがあるので、その問題を修正した方がよいでしょう(クエリプロセスを削除することは、単に症状を治療することです)。


1
@BugsBuggyこれが発生する一般的な方法は、別のプロセス(Webサーバー、この場合はインポートプロセスなど)が実行されており、データベースに接続されている場合です。DROP DATABASEコマンドを発行すると、すべての接続が閉じられるまでサーバーは続行しません。
ステファンマグナソン

11

インポートプロセスは終了したと思いましたが、おそらくまだ実行中でした。

DROP DATABASEコマンドは、おそらくそれが実行する前に、インポート仕上げにデータベースを待っていました。

したがって、DROP DATABASE長い時間をかけるのではなく、おそらく単なるインポートでした。

他の誰かがこれを読み、データベースのインポートをキャンセルしてデータベースをドロップしようとしている場合、まずインポートのPID(プロセスID)を見つけて別の端末から実行することをお勧めします。

$ kill [PID]

... [PID]はプロセスの実際のPIDです。

他の端末がまだ接続されている場合、インポートがすぐに停止するはずです。

またSHOW PROCESSLIST、phpMyAdmin SQLタブで実行することもできます。結果のテーブルには実行中のプロセスが表示されます。削除したい行の横にある「x」をクリックすると、トリックが実行されます。

次に実行する

DROP DATABASE `database_name`;

そして、すべてがきれいでなければなりません。


別の答えは、mysql内でプロセスを強制終了する方が、外部から実行するよりも優れていることを示唆しています。私はその答えをテストしていませんが、非常にもっともらしいようです。それで、私はこれを「受け入れられた答え」としてマークしました。


3

データベース内の最大のテーブルを削除する前に切り捨ててみてください。ファイアウォールトラフィックのMySQLアーカイブを操作すると、非常によく似た動作が見られ、これは非常に役立ちました。


MySQLのドキュメントによると、「切り捨て操作はテーブルを削除して再作成します。これは、行を1つずつ削除するよりもはるかに高速です」ため、削除を切り捨てても意味がありません-dev.mysql.com/doc/refman/8.0/en/ truncate-table.html
ejoubaud


3

私は同じ問題に直面した。しかし、今回はshow processlistをチェックしました。それはより長い時間の許可のチェックを言った。それから、mysqld_safeがrootとして実行されているのに対し、フォルダーレベルの権限はmysqlユーザーのみに許可されていることがわかりました。したがって、クエリを強制終了しました。もちろん、強制終了状態であると言うのに長い時間がかかりましたが、反応するのを待ってからクエリを強制終了し、グループに追加してフォルダレベルのアクセス許可をルートに変更し、chmodを770にしました。同じドロップデータベースブラー; 20GBデータベースの場合、2秒で機能しました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.