mysql - recuperar - remove ibdata1
Mysql no se inicia-ibdata1 corrupto?-error del sistema operativo número 13-emisión de permisos (14)
El servidor se apaga por falta de energía.
Mysql no se iniciará ahora.
El disco no está lleno. Syslog está abajo
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.
Si usas SEL Linux
Semanage intall
yum whatprovides /usr/sbin/semanage
obtiene policycoreutils-python-2.5-22.el7.x86_64
Ver el contexto de seguridad de mysqld.
Después de la instalación yum install policycoreutils-python
, puede ver qué contexto de seguridad tiene 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
Aquí puedes ver todo el contexto para mysqld una breve lista con una explicación
- mysqld_etc_t - archivos de configuración
- mysqld_db_t - archivos db de datos
- mysqld_log_t - archivos de registro
- mysqld_exec_t - archivos de ejecución
Entonces, si tiene el contexto de seguridad incorrecto en sus archivos, obtiene un permiso denegado (error 13)
Solución
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
Pero también verifique los permisos "normales". Tuve este problema con los centos
. Tienes que systemctl restart mysql
para los cambios.
En resumen, (especialmente en RHEL / CentOS / Fedora) intente
getenforce
si responde con Enforcing
, tiene SELinux en funcionamiento. ¡ setenforce 0
temporalmente con setenforce 0
y vea si MariaDB comienza ahora! Bastante común, especialmente en RHEL / CentOS / Fedora.
Hay más sobre esto más abajo, así como en este artículo oficial .
En general
Hay más cosas en un entorno UNIX que pueden impedir el acceso a los archivos, que los derechos de acceso de los usuarios.
- Los módulos de seguridad como SELinux (ver arriba) o AppArmor (como lo mencionó Dan) podrían deshabilitarlo
- Las listas de control de acceso (ACL) se pueden establecer específicamente para los archivos / directorios requeridos
- Cualquiera de las carpetas principales podría ser propiedad de otro usuario y no tener establecido x (= "dir access") para otros.
Además podría haber otros factores inesperados, como ...
- El
datadir
mysql se establece en un lugar, donde mysql no tiene permisos (consulte/etc/my.cnf
) - Mysql podría (extrañamente) ejecutarse como un usuario diferente, o el archivo podría ser propiedad de alguien más
Solo por mencionar una vista de la parte superior de mi cabeza (siéntase libre de editar / agregar a esta respuesta por cierto).
En el caso, SELinux es "el problema".
Para una solución permanente, puede intentar restaurar el contexto de seguridad apropiado, ...
restorecon -R /var/lib/mysql/
... o simplemente desactive SELinux (pero piense en esto un poco antes de hacerlo), editando la configuración (normalmente en /etc/selinux/config
) y configurando SELINUX=disabled
como se sugiere en el siguiente artículo.
- Aquí está la página de ayuda oficial de mariadb.com: ¿Qué hacer si MariaDB no se inicia?
- Y aquí algo de redhat.com: MariaDB cambiando la ubicación de la base de datos
Obviamente, esos son aplicables a MySQL de la misma manera.
Cuando esto apareció, encontré la respuesta en el archivo de configuración /etc/mysql/my.cnf
. La línea de datos no /var/lib/mysql
directorio /var/lib/mysql
(donde están las bases de datos). Una vez que puse esta ruta, el servidor se reinició sin problemas.
El archivo no está dañado. Puede encontrar la fuente de estos errores con ''perror''. es decir
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDB tiene detección de corrupción (sumas de comprobación de página) y con mucho gusto le diría si ese fuera el problema.
O los permisos del directorio han cambiado, o su archivo my.cnf ha sido arreglado, y está intentando recrear archivos de datos en otro lugar.
En mi situación está el problema de Selinux. Y el
chcon -R --type=mysql_db_t /new/mysql/dir
viene error:
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument
.
Entonces uso el comando : chcon -R root:object_r:mysqld_db_t /new/mysql/dir
.
Error:
101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 101130 18:07:58 InnoDB: Operating system error number 13 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name ./ibdata1 InnoDB: File operation call: ''open''. InnoDB: Cannot continue operation.
Solución de seguridad SeLinux SeLinux:
[root@localhost ~]# service mysqld restart Deteniendo mysqld: [ OK ] Iniciando mysqld: [ FALLÓ ] [root@localhost ~]# restorecon -R /var/lib/mysql/ [root@localhost ~]# service mysqld restart Deteniendo mysqld: [ OK ] Iniciando mysqld: [ OK ] [root@localhost ~]#
Para mí, restaurar el contexto de seguridad (selinux) hizo el truco
restorecon -R /var/lib/mysql/
Por favor, chequee esto:
chown -R mysql:mysql /var/lib/mysql
Si está utilizando ubuntu o apparmor, debe permitir este cambio en apparmor.
Edite /etc/apparmor.d/usr.sbin.mysqld
y cambie /var/lib/mysql
con el nuevo DATADIR
.
Deberia de funcionar.
Si tiene este problema en un Synology NAS, puede solucionarlo siguiendo los consejos del equipo de soporte de Synology:
Querido usuario,
Esto se ha confirmado como un problema conocido y trataremos de solucionarlo en más versiones de MariaDB. Lo siento por tu inconveniente.
Aquí está la solución:
- Intente enviar un telnet a su DS con la cuenta "root" y la contraseña (igual que la del administrador)
- ejecute el comando "echo 1> / var / services / mysql / VERSION"
- abrir el paquete MariaDB desde DSM activará la actualización nuevamente
- escriba la contraseña de la base de datos y haga clic en Actualizar para solucionar este problema
Más información: foro de Synology
Tuve el mismo problema y solución por los pasos a continuación
Directorio de trabajo / var / lib / mysql
Anteriormente / var / lib / mysql era propiedad de un usuario desconocido
Lo cambió a mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Funciona de maravilla
Tuve exactamente el mismo problema en mi caja de CentOS. Después de mover el directorio de datos de mysql, ya no pude iniciar el servicio, incluso aunque había copiado los archivos con el mismo propietario y permisos.
Tuve un problema con el contexto de seguridad de SELinux. Si ejecuta su stock de CentOS, tiene buenas posibilidades de estar habilitado y no le permitirá hacer lo que quiera con MySQL. Para arreglar esto :
Primero compare el antiguo dir y el nuevo dir usando
ls -Z /var/lib/mysql
y
ls -Z /new/mysql/dir
Si ves alguna diferencia es probable que sea tu problema. Para modificar esto:
chcon -R --type=mysql_db_t /new/mysql/dir
El interruptor -R es para recursión. Si solo necesitas cambiar un archivo puedes omitirlo. Si su contexto es diferente al mío (tal vez una distro diferente), use el indicado por la salida del primero (debería ser el tercer campo de las cosas de SELinux)
ls -Z /var/lib/mysql
Tuve exactamente el mismo problema en mi caja de CentOS. Después de mover el directorio de datos de mysql, ya no pude iniciar el servicio, incluso aunque había copiado los archivos con el mismo propietario y permisos.
Tuve un problema con el contexto de seguridad de SELinux. Si ejecuta su stock de CentOS, tiene buenas posibilidades de estar habilitado y no le permitirá hacer lo que quiera con MySQL. Para arreglar esto :
Primero compare el antiguo dir y el nuevo dir usando
ls -Z /var/lib/mysql
y
ls -Z /new/mysql/dir
Si ves alguna diferencia es probable que sea tu problema. Para modificar esto:
chcon -R --type=mysql_db_t /new/mysql/dir
El interruptor -R es para recursión. Si solo necesitas cambiar un archivo puedes omitirlo.
Yo tuve el mismo problema. Hice mucha investigación y encontré esta solución. Debe ejecutar este comando en ibdata1 sudo shadowprotect -u root | raíz
No sé qué hace esto ... pero funcionó para mí.
Buena suerte.