关于mysql:InnoDB:尝试打开以前打开的表空间

InnoDB: Attempted to open a previously opened tablespace

我已经研究了几天问题了。我们位于Box帐户上的本地mediawiki页面已销毁,我们一直在努力使其联机。使用XAMPP控制面板v3.2.1时,错误很多,因此我们决定更新XAMPP(v3.2.2),并将" htdocs"和" mysql / data"文件移至新数据库。

第一个错误:

1
2
3
4
5
6
7
8
9
10
    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

如它所说,然后我去了日志,发现了这一点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
    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.

现在,这看起来像是一个标准错误,我在网上看到了很多关于如何解决它的建议。我将简要介绍它们。

我尝试的第一件事是遵循日志中的建议。

  • 没有权限问题
  • 目前尚不清楚我是否需??要该表,或者是否要摆脱phpmyadmin / pma__tracking或archive.ibd。当我删除了archive.ibd时,该错误刚刚传递到另一个.ibd文件。
  • " innodb_force_recovery = 1"已添加到my.cnf中,这会导致许多错误。
  • 我注意到的下一件事是,当我们构建新数据库时,我的phpMyAdmin(localhost / phpMyAdmin)中出现此错误:
    phpMyAdmin错误

    我不确定这是否引起我所有的问题。我发现有人说要将密码切换为=''。因为我要在新数据库中输入旧数据文件夹,所以可能发生此错误。我不

    网络上的第一个建议是从以下位置删除以下文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    \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

    第二:

    我试着删除'ibdata1'

    这些都不起作用。


    我有同样的问题。我尝试了其他人提出的所有解决方案,但不幸的是没有任何效果。

    花了几个小时在Google中寻找解决方案后,我终于找到了

  • 打开my.ini(在基于Linux的系统和Mac上为my.cnf)
  • 寻找[mysqld]
  • 在[mysqld]下方插入innodb_force_recovery = 1
  • 启动MySQL服务
  • 停止MySQL服务
  • 从my.ini中删除该行(innodb_force_recovery = 1)
  • 启动MySQL服务
  • 在我的情况下工作完美。

    我希望这能解决您的问题。


    我遇到了同样的错误。这些是我遵循的步骤。

  • 备份 xampp mysql data

  • 从数据文件夹中删除了除mysql之外的所有文件和文件夹

  • 退出并再次启动XAMPP。

  • 分别从data文件夹移动数据库。


  • 尝试将/Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0重命名为/Applications/XAMPP/xamppfiles/var/mysql/ib_logfile0.bkp

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


    要在MAMP(版本> = 4)中使用以上(Nesar解决方案),必须首先将MAMP / tmp / mysql内的my.cnf文件复制到MAMP / conf文件夹。只有这样,它才能起作用。


    解决方案适用于MAC 10.11.3 El Captian

    • 转到/ Applications / XAMPP / xamppfiles / var / mysql /
    • 删除所有随机文件(实际数据库文件夹除外)
    • 重新启动Apache和MySQL。

    这对我有用。


    我在Mamp Pro中遇到了类似的问题。对我来说,原来正确的.idb文件不在" Applications / Mamp ..."中。因此,仔细查看错误日志,它显示出文件位于" / Library / Application Support / appsolute / MAMP PRO / db"。由于我在使用数据库时遇到了问题,我只是尝试删除相应的文件夹,然后解决了。下一步将是删除作者已经提到的文件。

    • 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

    但是如前所述,删除databasefolder非常有效。


    使用恢复数据库结构后,我遇到了同样的问题(http://zadpen.com/20-restore-lost-data-in-mysql-using-innodb-engine-without-file-ibdata1.html)
    我删除archive.ibm文件并启动mysql。
    然后在数据库中创建存档表。


    我发现无法正确编辑my.cnf,因此是上述针对MAMP Pro的问题的另一种解决方案:

    当InnoDB崩溃时,在错误消息中找出引起麻烦的DB。这是phpmyadmin/pma__tracking,因此该表是带有pma_扩展名的表。

    然后转到/Library/Application Support/appsolute/MAMP PRO/db/mysql,并删除导致DB的问题后命名的文件夹。

    重新启动您的MAMP服务器。
    成功重启后,可以再次停止服务器,放回它所属的DB文件夹,然后重新启动服务器。一切都应该再好的。


    "试图打开以前打开的表空间。" -闻起来像其中之一:

    • 有两个MySQL副本,两个都试图运行。
    • Windows无法释放其中一个MySQL文件的"打开"状态。我曾经看到过这个问题。通过重新启动Windows可以解决此问题。稍后通过升级Windows。

    Tgr的答案似乎合适。有关权限等的消息是通用消息。实际的错误信息是

    1
    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

    您的Wiki数据库和phpmyadmin数据库最终以相同的表空间ID结束了。如果没有对方,每个人都可以正常工作。现在,您必须以某种方式重新编号其中之一。