InnoDB: Tentative d'ouvrir un tablespace précédemment ouvert
Je travaille sur un problème depuis quelques jours maintenant. Notre page mediawiki locale située sur notre compte Box s’est détruite et nous travaillons à la mettre en ligne. En utilisant XAMPP Control Panel v3.2.1, les erreurs étaient nombreuses et nous avons donc décidé de mettre à jour XAMPP (v3.2.2) et de déplacer les fichiers 'htdocs' et 'mysql/data' vers la nouvelle base de données.
Première erreur:
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
Comme il est dit, je suis ensuite allé dans les journaux et j'ai trouvé ceci:
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.
À présent, cela ressemble à une erreur standard que j'ai constatée avec de nombreuses suggestions sur le Web pour y remédier. Je vais les passer brièvement en revue.
La première chose que j'ai essayée a été de suivre les suggestions du journal.
- Il n'y avait pas de problèmes de permission
- Il n'est pas clair si j'ai besoin de la table ou non, OR s'il faut supprimer phpmyadmin/pma__tracking ou archive.ibd. Lorsque je me suis débarrassé de archive.ibd, l'erreur est simplement passée à un autre fichier .ibd.
- 'innodb_force_recovery = 1' a été ajouté à my.cnf et entraîne de nombreuses erreurs.
La chose suivante que j'ai remarquée est que, lorsque nous avons construit la nouvelle base de données, j'ai eu cette erreur dans mon phpMyAdmin (localhost/phpMyAdmin): erreur phpMyAdmin
Je ne suis pas sûr si cela cause tous mes problèmes ou pas. J'ai trouvé que les gens disaient de changer un mot de passe pour = ''. Cette erreur peut se produire car j'entre d'anciens dossiers de données dans une nouvelle base de données. Je ne suis pas sûr.
La première suggestion sur le Web consistait à supprimer les fichiers suivants 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
Le 2ème:
J'ai essayé de supprimer 'ibdata1'
Aucun d'entre eux n'a fonctionné.
J'ai eu le même problème. J'ai essayé toutes les solutions proposées par d'autres et malheureusement rien n'a fonctionné.
Après avoir passé des heures à chercher la solution dans Google, j'ai finalement trouvé ce
- Ouvrez my.ini (my.cnf sur des systèmes Linux et Mac)
- Cherchez [mysqld]
- Juste en dessous de [mysqld] insert innodb_force_recovery = 1
- Démarrer le service MySQL
- Arrêtez le service MySQL
- Supprimez la ligne de my.ini (innodb_force_recovery = 1)
- Démarrer le service MySQL
A travaillé parfaitement dans mon cas.
J'espère que cela résoudra votre problème.
J'ai eu la même erreur. Ce sont les étapes que j'ai suivies.
A effectué la sauvegarde de\xampp\mysql\data
Suppression de tous les fichiers et dossiers du dossier de données sauf
mysqlQuittez et redémarrez XAMPP.
Déplacez les bases de données du dossier
dataune par une.
essayez de renommer /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0 en /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0.bkp
et /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1 à /Applications/XAMPP/xamppfiles/var/mysql/ib_logfile1.bkp
Pour utiliser ce qui précède ( solution Nesar ) dans MAMP (version> = 4), vous devez d’abord copier le fichier my.cnf situé dans MAMP/tmp/mysql dans le dossier MAMP/conf. Alors seulement, ça marchera.
La solution est pour MAC 10.11.3 El Capitan
- Supprimer tous les fichiers aléatoires (sauf les dossiers de la base de données réelle)
- Redémarrez Apache et MySQL.
- Cela a fonctionné pour moi.
This worked for me.
J'ai eu un problème similaire avec Mamp Pro. Pour moi, il s'est avéré que les fichiers .idb corrects ne se trouvaient pas dans "Applications/Mamp ...". En regardant de plus près le journal des erreurs, il m’a montré que les fichiers se trouvaient dans "/ Bibliothèque/Application Support/appsolute/MAMP PRO/db". Comme j'avais des problèmes avec une base de données que je n'utilisais plus, j'ai juste essayé de supprimer le dossier correspondant et cela a fonctionné. La prochaine étape aurait été de supprimer les fichiers déjà mentionnés par l'auteur.
- 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
Mais comme mentionné précédemment, supprimer la base de données a très bien fonctionné.
La réponse de Tgr semble appropriée. Le message sur les autorisations, etc. est générique; le message d'erreur réel est
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
Votre base de données wiki et votre base de données phpmyadmin se sont en quelque sorte retrouvées avec le même ID de tablespace. Chacun fonctionnerait bien si l'autre n'était pas présent; dans l’état actuel, vous devrez en renuméroter un.
"Tentative d’ouvrir un tablespace précédemment ouvert." - Ça sent comme ça:
- Il existe deux copies de MySQL et les deux essaient de fonctionner.
- Windows n'a pas réussi à libérer un 'open' sur l'un des fichiers de MySQL. J'avais l'habitude de voir ce problème. Il a été guéri en redémarrant Windows; plus tard en mettant à niveau Windows.
J'ai eu le même problème, après l'utilisation de la structure de base de données de récupération ( http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html Je supprime le fichier archive.ibm et lance mysql . Puis crée une table archive dans la base de données.
Une autre solution au problème décrit ci-dessus pour MAMP Pro, car j’ai trouvé impossible d’éditer correctement le fichier my.cnf:
Lorsque InnoDB se bloque, identifiez dans le message d'erreur la base de données à l'origine du problème. Ici, c'est phpmyadmin/pma__tracking et la table est celle avec l'extension pma_.
Ensuite, allez à /Library/Application Support/appsolute/MAMP PRO/db/mysql et supprimez le dossier nommé d'après le problème à l'origine de la base de données.
Redémarrez votre serveur MAMP . Une fois que vous avez redémarré avec succès, vous pouvez arrêter à nouveau les serveurs, remettre le dossier de la base de données à sa place et redémarrer les serveurs. Tout devrait bien se passer à nouveau.