los - drop tablespace mysql

InnoDB: Intento abrir un tablespace previamente abierto (10)

"Intento abrir un tablespace previamente abierto". - Huele a uno de estos:

Hay dos copias de MySQL y ambas intentan ejecutarse.
Windows no pudo lanzar un ''abierto'' en uno de los archivos de MySQL. Solía ver ese problema. Fue curado al reiniciar Windows; más tarde al actualizar Windows.

He estado trabajando en un problema por unos días. Nuestra página de mediawiki local que se encuentra en nuestra cuenta de caja, se destruyó a sí misma y hemos estado trabajando para ponerla en línea. Usando XAMPP Control Panel v3.2.1, los errores fueron numerosos, así que decidimos actualizar XAMPP (v3.2.2) y mover los archivos ''htdocs'' y ''mysql / data'' a la nueva base de datos.

Primer error:

9:50:21 AM [mysql] Attempting to start MySQL app... 9:50:22 AM [mysql] Status change detected: running 9:50:22 AM [mysql] Status change detected: stopped 9:50:22 AM [mysql] Error: MySQL shutdown unexpectedly. 9:50:22 AM [mysql] This may be due to a blocked port, missing dependencies, 9:50:22 AM [mysql] improper privileges, a crash, or a shutdown by another method. 9:50:22 AM [mysql] Press the Logs button to view error logs and check 9:50:22 AM [mysql] the Windows Event Viewer for more clues 9:50:22 AM [mysql] If you need more help, copy and post this 9:50:22 AM [mysql] entire log window on the forums

Como dice, luego fui a los registros y encontré esto:

2015-11-20 09:50:22 11f8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB''s internal memory allocator. 2015-11-20 9:50:22 4600 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2015-11-20 9:50:22 4600 [Note] InnoDB: The InnoDB memory heap is disabled 2015-11-20 9:50:22 4600 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2015-11-20 9:50:22 4600 [Note] InnoDB: Memory barrier is not used 2015-11-20 9:50:22 4600 [Note] InnoDB: Compressed tables use zlib 1.2.3 2015-11-20 9:50:22 4600 [Note] InnoDB: Not using CPU crc32 instructions 2015-11-20 9:50:22 4600 [Note] InnoDB: Initializing buffer pool, size = 16.0M 2015-11-20 9:50:22 4600 [Note] InnoDB: Completed initialization of buffer pool 2015-11-20 9:50:22 4600 [Note] InnoDB: Highest supported file format is Barracuda. 2015-11-20 9:50:22 4600 [Note] InnoDB: The log sequence numbers 1665234 and 1665234 in ibdata files do not match the log sequence number 50125498 in the ib_logfiles! 2015-11-20 9:50:22 4600 [Note] InnoDB: Database was not shutdown normally! 2015-11-20 9:50:22 4600 [Note] InnoDB: Starting crash recovery. 2015-11-20 9:50:22 4600 [Note] InnoDB: Reading tablespace information from the .ibd files... 2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: ./phpmyadmin/pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: ./wiki/archive.ibd InnoDB: Error: could not open single-table tablespace file ./wiki/archive.ibd InnoDB: We do not continue the crash recovery, because the table may become InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it. InnoDB: To fix the problem and start mysqld: InnoDB: 1) If there is a permission problem in the file and mysqld cannot InnoDB: open the file, you should modify the permissions. InnoDB: 2) If the table is not needed, or you can restore it from a backup, InnoDB: then you can remove the .ibd file, and InnoDB will do a normal InnoDB: crash recovery and ignore that table. InnoDB: 3) If the file system or the disk is broken, and you cannot remove InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf InnoDB: and force InnoDB to continue crash recovery here.

Ahora esto parece un error estándar que he visto con muchas sugerencias diferentes en toda la web sobre cómo solucionarlo. Los revisaré brevemente.

Lo primero que intenté fue seguir las sugerencias en el registro.

No hubo problemas de permiso
No está claro si necesito la tabla o no, O si me deshago de phpmyadmin / pma__tracking o archive.ibd. Cuando me deshice de archive.ibd, el error simplemente pasó a otro archivo .ibd.
''innodb_force_recovery = 1'' fue agregado a my.cnf y esto causa un montón de errores.

Lo siguiente que noté es que cuando construimos la nueva base de datos, obtuve este error en mi error phpMyAdmin (localhost / phpMyAdmin): phpMyAdmin

No estoy seguro de si esto está causando todos mis problemas o no. Descubrí que la gente decía que cambiasen una contraseña a = ''''. Este error podría estar sucediendo porque estoy ingresando carpetas de datos antiguas en una nueva base de datos. No estoy seguro.

La primera sugerencia en la web fue eliminar los siguientes archivos de

/mysql/data: innodb_index_stats.frm innodb_index_stats.ibd innodb_table_stats.frm innodb_table_stats.ibd slave_master_info.ibd slave_relay_log_info.frm slave_relay_log_info.ibd slave_worker_info.frm slave_worker_info.ibd

El segundo:

He intentado eliminar ''ibdata1''

Ninguno de estos ha funcionado.

La respuesta de Tgr parece apropiada. El mensaje sobre permisos, etc. es genérico; el mensaje de error real es

2015-11-20 9:50:22 4600 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace phpmyadmin/pma__tracking uses space ID: 21 at filepath: ./phpmyadmin/pma__tracking.ibd. Cannot open tablespace wiki/archive which uses space ID: 21 at filepath: ./wiki/archive.ibd

Su base de datos wiki y su base de datos phpmyadmin de alguna manera terminaron con la misma ID de tablespace. Cada uno funcionaría bien si el otro no estuviera presente; como es ahora, tendrá que volver a numerar uno de ellos de alguna manera.

La solución es para MAC 10.11.3 El Captian

Vaya a / Aplicaciones / XAMPP / xamppfiles / var / mysql /
Eliminar todos los archivos aleatorios (excepto las carpetas de bases de datos reales)
Reinicie Apache y MySQL.

Esto funcionó para mí.

Otra solución para el problema descrito anteriormente para MAMP Pro, ya que me resultó imposible editar my.cnf correctamente:

Cuando InnoDB se cuelga, identifica en el mensaje de error el DB que está causando problemas. Aquí está phpmyadmin/pma__tracking por lo que la tabla es la que tiene la extensión pma_.

Luego vaya a /Library/Application Support/appsolute/MAMP PRO/db/mysql y elimine la carpeta nombrada después del problema que causa DB.

Reinicia tu servidor MAMP. Una vez que haya reiniciado con éxito, puede detener servidores nuevamente, volver a colocar la carpeta de DB donde pertenece y volver a iniciar los servidores. Todo debería estar bien de nuevo.

Para usar lo anterior ( solución Nesar ) en MAMP (versión> = 4), primero debe copiar el archivo my.cnf que está dentro de MAMP / tmp / mysql a la carpeta MAMP / conf. Solo entonces funcionará.

Tengo el mismo error. Estos son los pasos que seguí.

Tomó la copia de seguridad de / xampp / mysql / data
Se eliminaron todos los archivos y carpetas de la carpeta de datos, excepto mysql
Salga e inicie el XAMPP nuevamente.
Mueva las bases de data carpeta de data uno por uno.

Tuve el mismo problema, después de utilizar la estructura de la base de datos de recuperación ( http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html ) http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html el archivo archivo .ibm y comienza mysql. luego crea una tabla de archivo en la base de datos.

Tuve un problema similar con Mamp Pro. Para mí resultó que los archivos .idb correctos no se encontraban en "Aplicaciones / Mamp ...". Así que al mirar más de cerca el registro de errores me mostró que los archivos estaban ubicados en "/ Library / Application Support / appsolute / MAMP PRO / db". Como tenía problemas con una base de datos que ya no usaba, intenté eliminar la carpeta correspondiente y funcionó. El siguiente paso habría sido eliminar los archivos ya mencionados por el autor.

innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd

Pero como se mencionó, borrar la carpeta de la base de datos funcionó muy bien.

Yo tuve el mismo problema. Probé con todas las soluciones que otros propusieron y, desafortunadamente, nada funcionó.

Después de pasar horas buscando la solución en Google, finalmente encontré esto

Abra my.ini (my.cnf en sistemas basados en Linux y Mac)
Busque [mysqld]
Justo debajo de [mysqld] inserta innodb_force_recovery = 1
Comience el servicio de MySQL
Detener el servicio de MySQL
Elimina la línea de my.ini (innodb_force_recovery = 1)
Comience el servicio de MySQL

Funcionó perfecto en mi caso.

Espero que esto resuelva tu problema.

intente cambiar el nombre de /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0 a /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0.bkp

y /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1 a /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1.bkp