Cause de l'erreur: nom de table ou de base de données non valide (ancien?) «Perdu + trouvé»

8

Mon journal MySQL montre des erreurs dupliquées:

141223  5:47:21 [ERROR] Invalid (old?) table or database name 'lost+found'

J'ai une base de données nommée #mysql50#lost+foundmais je n'arrive pas à la supprimer.

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| maindatabas         |
| maindatabas_help    |
| maindatabas_tracker |
| gitlabhq_production |
| locations           |
| #mysql50#lost+found |
| mysql               |
| osticket            |
| performance_schema  |
+---------------------+
10 rows in set (0.00 sec)

mysql> DROP DATABASE `#mysql50#lost+found`;
ERROR 1008 (HY000): Can't drop database '#mysql50#lost+found'; database doesn't exist
mysql>

J'utilise la version Serveur: 5.5.40 Distribuée par The IUS Community Project sur Centos 6.

Par MySQL fonctionne TRÈS lentement sur CentOS 6x (pas 5x) , mon datadir est sur ext3 avec l'option barrière = 0.

Quelle est la cause de cette erreur et comment la supprimer?

user1032531
la source

Réponses:

14

Il me semble que vous datadirêtes dans un système de fichiers qui lui est propre.

Les systèmes de fichiers Ext, comme la plupart des FS sous Unix, ont à leur racine un répertoire appelé lost+found. Il existe pour permettre aux fichiers qui se détachent (c'est-à-dire qu'ils ont du contenu, mais aucune entrée de répertoire associée) d'être rattachés quelque part lorsqu'un système de fichiers incohérent est fscké (voir, par exemple, https://unix.stackexchange.com/ questions / 18154 / quel-est-le-but-du-dossier-perdu-dans-linux-et-unix pour plus de détails). Cet objectif est important dans la reprise après sinistre, vous ne devez donc pas supprimer le répertoire.

Votre problème survient lorsque le point de montage, sur lequel le système de fichiers qui contient ce répertoire est monté, est entièrement remis à une application qui s'attend à ce que tout ce point de montage lui appartienne. MySQL étant l'un d'entre eux, il tente d'interpréter le lost+foundrépertoire comme étant quelque chose de lié à la base de données et (ce n'est pas déraisonnable) échoue.

Le mieux est de ne jamais dédier un FS entier à une application, mais de monter le FS sur un point de montage non spécifique à une application, par exemple /data1, créer un sous-répertoire sous celui-ci, par exemple /data1/mysql, et reconfigurer l'application pour utiliser ce répertoire comme son datadir.

Chapelier Fou
la source
12

MadHatter a bien expliqué l'erreur. Mais depuis lors, les temps ont changé et maintenant MySQL ( depuis 5.6.3 ) a une option pour ignorer ce répertoire. Ajoutez simplement cette déclaration dans votre /etc/mysql/my.cnffichier:

ignore-db-dir=lost+found

Après le redémarrage de MySQL, vous pouvez le vérifier avec la commande:

show global variables like 'ignore_db_dirs';

Si vous souhaitez ignorer plusieurs répertoires, vous devez spécifier l'option pour chacun d'eux séparément.

Source: http://www.chriscalender.com/ignoring-the-lostfound-directory-in-your-datadir/

Marki555
la source
3

Emplacement de my.cnf sous CentOS 7.2 si vous utilisez MariaDB est dans

/etc/my.cnf

Vous pouvez redémarrer le service avec

systemctl restart mariadb.service

ignore-db-dir doit être placé sous la section [mysqld] et non sous [mysqld_safe].

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

ignore-db-dir=lost+found

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
Strahinja Radman
la source
1

Comme notre MySQL ne comprend pas encore ignore_db_dirs, j'ai fait

# chmod 0 lost+found

qui a résolu le (ce) problème.

Gerrit A. Smit
la source
0

MariaDb est ignore_db_dirs MySQL est ignore_db_dir - sans le "s"

Voir https://mariadb.com/kb/en/library/server-system-variables/#ignore_db_dirs

J'avais un répertoire caché comme ci-dessous

mysql50 # .local

donc dans etc / my.cnf --- pour MariaDB c'était

[mysqld] ignore_db_dirs = .local

et redémarrez le serveur de base de données - puis vérifiez que la base de données n'est plus dans la commande SHOW DATABASES ou avec MariaDB il y a un "mysqlshow" depuis la ligne de commande

Ensuite, vous pouvez supprimer le répertoire et tout ce qu'il contient dans / var / lib / mysql, puis rééditer le fichier /etc/my.cnf et commenter la commande ou le supprimer et redémarrer le serveur - le problème est résolu

NE SUPPRIMEZ PAS JUSTE LE RÉPERTOIRE INDÉSIRABLE SANS faire cela ci-dessus EN PREMIER = car le magasin de données que le serveur conserve sera corrompu et vous ne pourrez pas le redémarrer sans avoir à supprimer toutes les bases de données et restaurer les bases de données à partir d'une sauvegarde ou pire - et c'est un GRAND OUCH.

Wilburunion
la source