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

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

Primero compare el antiguo dir y el nuevo dir usando

ls -Z /var/lib/mysql

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.