Mysql
 sql >> Base de données >  >> RDS >> Mysql

MySQL :erreur lors de la suppression de la base de données (errno 13 ; errno 17 ; errno 39)

Solution rapide

Si vous voulez simplement supprimer la base de données quoi qu'il arrive (mais s'il vous plaît lisez d'abord l'intégralité du message :l'erreur a été donnée pour une raison , et il peut être important d'en connaître la raison !), vous pouvez :

  • trouver le datadir avec la commande SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
  • arrêter le serveur MySQL (par exemple, service mysql stop ou rcmysqld stop ou similaire sous Linux, NET STOP <name of MYSQL service, often MYSQL57 or similar> ou via SERVICES.MSC sous Windows)
  • accédez au répertoire de données (c'est là que vous devriez enquêter ; voir ci-dessous)
  • supprimer le répertoire portant le même nom que la base de données
  • relancer le serveur MySQL et s'y connecter
  • exécuter une DROP DATABASE
  • c'est tout !

Raisons de l'erreur 13

MySQL n'a pas d'autorisation d'écriture sur le répertoire parent dans lequel mydb dossier réside.

Vérifiez avec

ls -la /path/to/data/dir/         # see below on how to discover data dir
ls -la /path/to/data/dir/mydb

Sous Linux, cela peut également se produire si vous mélangez et faites correspondre les packages MySQL et AppArmor/SELinux. Ce qui se passe, c'est qu'AppArmor s'attend à ce que mysqld ait ses données dans /path/to/data/dir , et autorise le R/W complet ici, mais MySQLd provient d'une distribution ou d'une construction différente, et il stocke en fait ses données ailleurs (ex :/var/lib/mysql5/data/** par opposition à /var/lib/mysql/** ). Donc, ce que vous voyez, c'est que le répertoire a les autorisations et la propriété correctes et pourtant il donne toujours Errno 13 car apparmor/selinux n'en autorise pas l'accès.

Pour vérifier, vérifiez le journal système pour les violations de sécurité, inspectez manuellement la configuration apparmor/selinux, et/ou personnifiez l'utilisateur mysql et essayez d'aller dans le répertoire var de base, puis cd progressivement jusqu'à ce que vous soyez dans le répertoire cible, et exécutez quelque chose comme touch aardvark && rm aardvark . Si les autorisations et la propriété correspondent, et que ce qui précède génère une erreur d'accès, il y a de fortes chances qu'il s'agisse d'un problème de cadre de sécurité.

Raisons de l'erreur 39

Ce code signifie "répertoire non vide". Le répertoire contient des éléments cachés fichiers dont MySQL ne sait rien. Pour les fichiers non cachés, voir Errno 17. La solution est la même.

Les raisons de l'Errno 17

Ce code signifie "le fichier existe". Le répertoire contient des fichiers MySQL que MySQL n'hésite pas à supprimer. De tels fichiers pourraient avoir été créés par un SELECT ... INTO OUTFILE "filename"; commande où filename n'avait pas de chemin. Dans ce cas, le processus MySQL les crée dans son répertoire de travail courant, qui (testé sur MySQL 5.6 sur OpenSuSE 12.3) est le répertoire de données de la base de données , par exemple. /var/lib/mysql/data/nameofdatabase .

Reproductibilité :

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)

Déplacez le(s) fichier(s) à l'extérieur (ou supprimez-le si vous n'en avez pas besoin) et réessayez. Déterminez également pourquoi ils ont été créés en premier lieu - cela pourrait indiquer un bogue dans certaines applications . Ou pire :voir ci-dessous...

MISE À JOUR :Erreur 17 en tant qu'indicateur d'exploitation

Cela s'est produit sur un système Linux avec Wordpress installé. Malheureusement, le client était sous des contraintes de temps et je ne pouvais ni imager le disque ni faire un véritable tour d'investigation - j'ai réinstallé toute la machine et Wordpress a été mis à jour dans le processus, donc je peux seulement dire que je suis presque certains qu'ils l'ont fait via ce plugin .

Symptômes :le mysql Le répertoire de données contenait trois fichiers avec l'extension PHP. Attendez, quoi ?! ? -- et à l'intérieur des fichiers, il y avait une grande quantité de code base64 qui a été transmis à base64_decode , gzuncompress et [eval()][2] . Aha . Bien sûr, ce n'étaient que les premières tentatives, celles qui ont échoué. Le site était bel et bien pwn3d.

Donc, si vous trouvez un fichier dans votre répertoire de données mysql qui provoque une erreur 17, vérifiez-le avec file utilitaire ou analysez-le avec un antivirus. Ou inspectez visuellement son contenu. Ne présumez pas qu'il est là pour une erreur anodine.

(Inutile de dire que pour inspecter visuellement le fichier, ne double-cliquez jamais dessus ).

La victime dans ce cas (il avait un ami "fait la maintenance") n'aurait jamais deviné qu'il avait été piraté jusqu'à ce qu'un script de maintenance/mise à jour/quelconque exécute une DROP DATABASE (ne me demandez pas pourquoi - je ne suis même pas sûr de vouloir savoir ) et a obtenu une erreur. D'après la charge du processeur et les messages syslog, je suis assez certain que l'hôte est devenu une ferme de spam.

Encore une autre erreur 17

Si vous rsync ou copier entre deux installations MySQL de la même version mais de plate-forme ou de systèmes de fichiers différents comme Linux ou Windows (ce qui est déconseillé et risqué, mais beaucoup le font quand même), et spécifiquement avec différents sensibilité à la casse paramètres, vous pouvez accidentellement vous retrouver avec deux versions du même fichier (données, index ou métadonnées) ; dites Customers.myi et Customer.MYI . MySQL utilise l'un d'eux et ne sait rien de l'autre (qui pourrait être obsolète et conduire à une synchronisation désastreuse). Lors de la suppression de la base de données, ce qui se produit également dans de nombreux mysqldump ... | ... mysql schémas de sauvegarde, le DROP échouera car ce fichier supplémentaire (ou ceux fichiers supplémentaires) existe. Si cela se produit, vous devriez être en mesure de reconnaître le ou les fichiers obsolètes qui doivent être supprimés manuellement à partir de l'heure du fichier ou du fait que leur schéma de cas est différent de la majorité des autres tables.

Trouver le répertoire de données

En général, vous pouvez trouver le répertoire de données en inspectant le my.cnf fichier (/etc/my.cnf , /etc/sysconfig/my.cnf , /etc/mysql/my.cnf sur Linux ; my.ini dans le répertoire des fichiers du programme MySQL sous Windows), sous le [mysqld] en-tête, comme datadir .

Vous pouvez également le demander à MySQL lui-même :

mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)