Mysql ne démarre pas - ibdata1 est corrompu? - numéro d'erreur de système d'exploitation 13 - problème d'autorisations
Arrêt du serveur suite à une panne de courant.
Mysql ne va pas commencer maintenant.
Le disque n'est pas plein . Syslog est en dessous
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
Le fichier n'est pas corrompu. Vous pouvez trouver la source de ces erreurs avec "perror". c'est à dire.
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDB a une détection de corruption (sommes de contrôle de page) et vous dira avec plaisir si tel était le problème.
Soit les autorisations de répertoire ont changé, soit votre fichier my.cnf a été isolé et il tente de recréer des fichiers de données ailleurs.
Si vous utilisez ubuntu ou apparmor, vous devez autoriser ce changement d'apparmor.
Éditez /etc/apparmor.d/usr.sbin.mysqld et changez /var/lib/mysql avec la nouvelle DATADIR.
Ça devrait marcher.
Erreur:
101130 14:42:51 mysqld_safe mysqld à partir du fichier pid /var/run/mysqld/mysqld.pid terminé 101130 18:07:58 mysqld_safe Démarrage du démon mysqld avec les bases de données de /var/lib/mysql 101130 18:07:58 InnoDB: numéro d’erreur système 13 dans une opération de fichier . InnoDB: L’erreur signifie que mysqld n’a pas les droits d’accès à InnoDB: le répertoire . InnoDB: nom du fichier. /ibdata1 InnoDB: Appel de l'opération de fichier: 'ouvrir' . InnoDB: Impossible de poursuivre l'opération .
Solution SeLinux Sécurité SeLinux:
[root @ localhost ~] # service mysqld restart Détecter mysqld: [OK] Iniciando mysqld: [FALLÓ] [root @ localhost ~] # restorecon -R/var/lib/mysql / [root@localhost ~] # service mysqld restart Détecter mysqld: [OK] Iniciando mysqld: [OK] [root @ localhost ~] #
Pour moi, restaurer le contexte de sécurité (selinux) a fait l'affaire
restorecon -R /var/lib/mysql/
s'il te plaît, vérifie cela:
chown -R mysql:mysql /var/lib/mysql
J'ai eu exactement le même problème sur ma boîte CentOS. Après avoir déplacé le répertoire de données mysql, je ne pouvais plus démarrer le service, même si j'avais copié les fichiers avec le même propriétaire et les mêmes autorisations.
J'ai eu un problème avec le contexte de sécurité SELinux. Si vous utilisez votre stock CentOS, il a de bonnes chances d'être activé et ne laissera pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème:
Commencez par comparer l'ancien et le nouveau dir à l'aide de
ls -Z /var/lib/mysql
et
ls -Z /new/mysql/dir
Si vous voyez une différence, c'est probablement votre problème. Pour modifier ceci:
chcon -R --type=mysql_db_t /new/mysql/dir
Le commutateur -R est pour la récursion. Si vous ne devez modifier qu'un fichier, vous pouvez l'omettre. Si votre contexte est différent du mien (peut-être une distribution différente), utilisez celui indiqué par la sortie du premier (ce devrait être le 3ème champ du contenu SELinux)
ls -Z /var/lib/mysql
En bref, (surtout sur RHEL/CentOS/Fedora), essayez
getenforce
s'il répond avec Enforcing, SELinux est opérationnel. Désactivez-le temporairement avec setenforce 0 et voyez si MariaDB démarre maintenant! Plutôt commun, en particulier sur RHEL/CentOS/Fedora.
Il y a plus à ce sujet plus bas, ainsi que dans cet article officiel .
En général
Un environnement UNIX pouvant empêcher l'accès aux fichiers est plus complexe que les droits d'accès utilisateur.
- Des modules de sécurité tels que SELinux (voir ci-dessus) ou AppArmor (comme mentionné par Dan) pourraient l'interdire.
- Les listes de contrôle d'accès (ACL) peuvent être spécifiquement définies pour les fichiers/répertoires requis
- Tous les dossiers parents peuvent appartenir à un autre utilisateur et ne pas définir x (= "dir access") pour les autres.
En outre, il pourrait y avoir d'autres facteurs inattendus, comme ...
- Mysql
datadirétant défini sur un emplacement où mysql n'a pas les permissions (voir/etc/my.cnf) - Mysql pourrait (étrangement) fonctionner en tant qu'utilisateur différent, ou le fichier pourrait simplement appartenir à quelqu'un d'autre
Juste pour mentionner une vue de ma tête (n'hésitez pas à modifier/ajouter à cette réponse en passant).
Dans le cas, SELinux est "le problème"
Pour une solution permanente, vous pouvez essayer de restaurer le contexte de sécurité approprié, ...
restorecon -R /var/lib/mysql/
... ou simplement désactiver SELinux (mais réfléchissez-y un peu avant de le faire), en modifiant la configuration (généralement dans /etc/selinux/config) et en définissant SELINUX=disabled comme suggéré dans l'article suivant.
- Voici la page d'aide officielle de mariadb.com: Que faire si MariaDB ne démarre pas
- Et voici quelque chose sur redhat.com: MariaDB Modification de l’emplacement de la base de données
Évidemment, ceux-ci sont applicables à MySQL de la même manière.
J'ai eu le même problème et résoudre par étapes ci-dessous
Répertoire de travail/var/lib/mysql
L'ancien/var/lib/mysql appartenait à un utilisateur inconnu
Changé en mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Fonctionne comme un charme
Lorsque cela est apparu pour moi, j'ai trouvé la réponse dans le fichier de configuration /etc/mysql/my.cnf. La ligne datadir ne pointait pas vers le répertoire /var/lib/mysql (où se trouvent les bases de données). Une fois que j'ai mis ce chemin, le serveur a redémarré sans problème.
Si vous utilisez SEL Linux
Semanage Intall
yum whatprovides /usr/sbin/semanage vous obtenez policycoreutils-python-2.5-22.el7.x86_64
Voir le contexte de sécurité de mysqld
Après l'installation yum install policycoreutils-python, vous pouvez simplement regarder quel est le contexte de sécurité différent de mysqld.
semanage fcontext -l | grep mysqld
/etc/mysql(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.* regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)? all file system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)? regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.* regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.* regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.* regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf regular file unconfined_u:object_r:mysqld_home_t:s0
Ici vous voyez tout le contexte pour mysqld une courte liste avec des explications
- mysqld_etc_t - fichiers de configuration
- mysqld_db_t - fichiers de base de données
- mysqld_log_t - fichiers journaux
- mysqld_exec_t - fichiers d'exécution
Donc, si vous avez le mauvais contexte de sécurité sur vos fichiers, vous obtenez une autorisation refusée (erreur 13)
Solution
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
Mais vérifiez également les autorisations "normales". J'ai eu ce problème avec centos. Vous devez systemctl restart mysql pour les modifications.
J'ai eu exactement le même problème sur ma boîte CentOS. Après avoir déplacé le répertoire de données mysql, je ne pouvais plus démarrer le service, même si j'avais copié les fichiers avec le même propriétaire et les mêmes autorisations.
J'ai eu un problème avec le contexte de sécurité SELinux. Si vous utilisez votre stock CentOS, il a de bonnes chances d'être activé et ne laissera pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème:
Commencez par comparer l'ancien et le nouveau dir à l'aide de
ls -Z /var/lib/mysql
et
ls -Z /new/mysql/dir
Si vous voyez une différence, c'est probablement votre problème. Pour modifier ceci:
chcon -R --type=mysql_db_t /new/mysql/dir
Le commutateur -R est pour la récursion. Si vous ne devez modifier qu'un fichier, vous pouvez l'omettre.
Si vous rencontrez ce problème sur un Synology NAS, vous pouvez y remédier en suivant les conseils de l'équipe de support technique de Synology:
Cher utilisateur,
Ce problème a été confirmé et nous essaierons de résoudre ce problème dans une version ultérieure de MariaDB. Désolé pour l'inconvénience.
Voici la solution de contournement:
- S'il vous plaît essayez de telnet à votre DS avec un compte "root" et un mot de passe (identique à celui de l'administrateur)
- lancez la commande "echo 1>/var/services/mysql/VERSION"
- ouvrir le package MariaDB de DSM déclenchera à nouveau la mise à jour
- tapez le mot de passe de la base de données et cliquez sur Mettre à jour pour résoudre ce problème
Plus d'infos: Forum Synology
Dans mon esprit, c'est le problème de Selinux. Et lechcon -R --type=mysql_db_t /new/mysql/dir vient erreur:chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
Donc, j'utilise la commande: chcon -R root:object_r:mysqld_db_t /new/mysql/dir.