60

データベースを削除できませんでした：

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

私は何をすべきか？

4

7 に答える 7

131

クイックフィックス

何があってもデータベースを削除したい場合（ただし、最初に投稿全体を読んでください：エラーは理由で発生しました。理由が何であるかを知ることが重要な場合があります！）、次のことができます。

  • コマンドでdatadirを見つける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て）
  • datadirに移動します（これは調査する必要がある場所です。以下を参照してください）
  • データベースと同じ名前のディレクトリを削除します
  • MySQLサーバーを再起動して接続します
  • DROPDATABASEを実行します
  • それでおしまい！

Errno13の理由

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/**）。つまり、ディレクトリには正しい権限と所有権がありますが、apparmor / selinuxはそのディレクトリへのアクセスを許可しないため、Errno13が提供されます。

確認するには、システムログでセキュリティ違反を確認し、apparmor / selinux構成を手動で検査するか、mysqlユーザーになりすましてベースvarディレクトリに移動し、ターゲットディレクトリに移動するまで段階的にcdして、次のような操作を実行します。touch aardvark && rm aardvark。権限と所有権が一致していても、上記でアクセスエラーが発生した場合は、セキュリティフレームワークの問題である可能性があります。

有害と思われる「EASYFIX」

私は「エキスパートフォーラム」（ Stack Overflowではなく、よろしくお願いします）で提案された「簡単な修正」に遭遇しました。これは、WebやFTPの問題で時々見られるのと同じ「修正」です- chown 777。絶対にしないでください。まだ知らない人にとって、777（または775、または666）は、MySQLプログラマーが自分自身を適用するのを忘れた、またはあなたに知られたくないという魔法の数字ではありません。各桁には意味があり、777は、「バイナリまたはシェルスクリプトであるかのように実行することを含め、すべての人が私のものでやりたいことを行うことに同意します」という意味です。これを行うことにより（そして、適切に構成されたシステムでこれを行うことが許可されない可能性があります）、

  • セキュリティを意識したいくつかのプログラムが、現在は安全でないコンテキストにあることに気付いたため、機能を拒否するリスクがあります（たとえば、SSHキー、さようならSSH接続などに対して）。
  • MySQL自体に気付かれずに、MySQLが許可するかどうかに関係なく、システムへのあらゆるレベルのアクセス権を持つすべての人がデータの読み取りと書き込みを文字通り許可します。つまり、データベース全体をサイレントに破損することが可能になります。
  • 上記は、非常に悲惨な状況で、絶望的で知識のある人々によって、他の方法ではアクセスできないねじ込みMySQLインストールに再びアクセスするために行われることがあります（つまり、ローカルアクセスを許可しなくなります）。通常の状態に-それは永続的な変更ではなく、それでも。そして、それは「私のDBをドロップできるようにするための1つの奇妙なトリック」に対する修正ではありません。mysqladmin

（言うまでもなく、 WebやFTPの問題に対する実際の修正はほとんどありません。「最近、妻の鍵が玄関のドアを開けず、家に入ることができない」の修正は、鍵を確認するか、ロックを修理または交換してください」;確かにはるかに速いのは、「玄関のドアを大きく開いたままにしておくだけです！簡単です！起こり得る最悪の事態は何ですか？」）chown 777

Errno39の理由

このコードは「ディレクトリが空ではない」ことを意味します。ディレクトリには、MySQLが何も知らない隠しファイルがいくつか含まれています。非表示でないファイルについては、Errno17を参照してください。解決策は同じです。

Errno17の理由

このコードは「ファイルが存在する」ことを意味します。ディレクトリには、MySQLが削除を認識しないMySQLファイルが含まれています。このようなファイルは、パスがないSELECT ... INTO OUTFILE "filename";コマンドによって作成された可能性がfilenameあります。この場合、MySQLプロセスは、現在の作業ディレクトリ（OpenSuSE12.3のMySQL5.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が更新されたので、彼らがこれを介してそれを行ったとほぼ確信しているとしか言えませんプラグイン。

症状：mysqlデータディレクトリに、拡張子がPHPの3つのファイルが含まれていました。待って、なに？！？base64_decode--およびファイル内には、、gzuncompressおよびに渡された大量のbase64コードがありました[eval()][2]。あは。もちろん、これらは最初の試みであり、失敗したものでした。このサイトは本当にpwn3dでした。

したがって、エラー17の原因となっているファイルをmysqlデータディレクトリで見つけた場合は、ユーティリティで確認するfileか、アンチウイルスでスキャンしてください。または、その内容を視覚的に検査します。無害な間違いのためにそこにあると思い込まないでください。

（言うまでもなく、ファイルを視覚的に検査するには、ファイルをダブルクリックしないでください）。

この場合の被害者（彼には「メンテナンスを行う」友人がいた）は、メンテナンス/更新/スクリプトが実行されるまでハッキングされたとは決して推測しませんでしたDROP DATABASE（理由を聞かないでください-私が欲しいのかどうかさえわかりませんを知るために）そしてエラーが発生しました。CPUの負荷とsyslogメッセージから、ホストがスパムファームになったことはかなり確かです。

さらに別のエラー17

同じバージョンであるが、LinuxやWindowsなどの異なるプラットフォームまたはファイルシステムrsyncの2つのMySQLインストール間でコピーする場合（これは推奨されておらず、リスクがありますが、多くの場合、それでも実行されます）、特に大文字と小文字の区別の設定が異なる場合、誤って終了する可能性があります同じファイルの2つのバージョン（データ、インデックス、またはメタデータのいずれか）を使用します。と言うと。MySQLはそれらの1つを使用し、もう1つについては何も知りません（これは古く、悲惨な同期につながる可能性があります）。データベースを削除する場合、これは多くのバックアップスキームでも発生しますが、その余分なファイル（またはCustomers.myiCustomer.MYImysqldump ... | ... mysqlDROP余分なファイル）が存在します。これが発生した場合、ファイル時間から、またはそれらのケーススキームが他のテーブルの大部分とは異なるという事実から、手動で削除する必要がある廃止されたファイルを認識できるはずです。

データディレクトリの検索

一般に、データディレクトリは、見出しの下にあるmy.cnfファイル（Linuxの場合は、、Windowsの場合はMySQLプログラムファイルディレクトリ内）を調べることで見つけることができます。/etc/my.cnf/etc/sysconfig/my.cnf/etc/mysql/my.cnfmy.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)
于 2012-08-30T13:06:29.530 に答える
34

私の場合、「lower_case_table_names」パラメーターが原因でした。

大文字のテーブル名と lower_case_table_names パラメータで構成されるデータベースを削除しようとしたときにスローされたエラー番号 39 が有効になっています。

これは、小文字のパラメーターの変更を以前の状態に戻すことで修正されます。

于 2014-03-10T12:59:13.513 に答える
-1

私の場合、データベースに属していない追加のファイルがデータベースフォルダー内にありました。Mysql は、エラーを引き起こしたすべてのテーブルを削除した後、フォルダーが空ではないことを検出しました。ファイルを削除すると、ドロップ データベースは正常に機能しました。

于 2018-11-01T15:16:19.763 に答える