跪求极佳 MYSQL ibdata1文件丢失恢复工具 V9.2 绿色版软件百度云资源

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了跪求极佳 MYSQL ibdata1文件丢失恢复工具 V9.2 绿色版软件百度云资源相关的知识,希望对你有一定的参考价值。

参考技术A

链接:

提取码:st35 

软件名称:极佳mysqlibdata1文件丢失恢复工具V9.2绿色版

语言:简体中文

大小:11.4MB

类别:系统工具

介绍:MYSQLibdata1ibd数据库碎片恢复工具,专门针对MYSQL的ibdata1ibdinnodb引擎编写,支持MYSQL3456版本,任意系统平台的ibdata1ibd文件恢复。支持误删除,所在分区被格式化,支持黑客故意破坏等情况,自动侦测半页,提取合成。

仅从 ibdata1 文件中恢复数据

【中文标题】仅从 ibdata1 文件中恢复数据【英文标题】:Recover data from ibdata1 file only 【发布时间】:2018-03-06 04:50:08 【问题描述】:

如题所示,很明显我想从 ibdata1 文件中恢复数据。我在 ubuntu 系统中安装了 mysql 并损坏了大约 189GB 的数据库。现在数据库不会启动并触发数百万个 innodb 日志序列号错误。

错误

70925 14:14:34 InnoDB:错误:第 220865 页日志序列号 2848448969864 InnoDB:是在未来!当前系统日志序列号 2840085856559。 InnoDB:您的数据库可能已损坏,或者您可能复制了 InnoDB InnoDB:表空间,但不是 InnoDB 日志文件。看 InnoDB:http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB:了解更多信息。 170925 14:14:34 InnoDB:错误:第 220866 页日志序列号 2842327184689 InnoDB:是在未来!当前系统日志序列号 2840085856620。 InnoDB:您的数据库可能已损坏,或者您可能复制了 InnoDB InnoDB:表空间,但不是 InnoDB 日志文件。看 InnoDB:链接 InnoDB:了解更多信息。 170925 14:14:34 InnoDB:错误:第 220867 页日志序列号 2848550606948 InnoDB:是在未来!当前系统日志序列号 2840085856711。 InnoDB:您的数据库可能已损坏,或者您可能复制了 InnoDB InnoDB:表空间,但不是 InnoDB 日志文件。看 InnoDB:链接 InnoDB:了解更多信息。

我用谷歌搜索了很多方法,并一一尝试了许多方法,例如 -innodb_force_recovery=N (1 到 6) 以及其他更改。但是 DB 不会启动以恢复数据。

我已经清除了数据库并恢复了旧备份,并且服务器现在已启动并运行。但是很少有数据非常重要,我想从 ibdata1 文件中恢复它。

有人可以指导我如何从 ibdata1 文件中恢复数据吗?

此处的错误日志可能会有所帮助。

        170925 14:14:34  InnoDB: Error: page 2804483 log sequence number 2846912445106
        InnoDB: is in the future! Current system log sequence number 2840085857093.
        InnoDB: Your database may be corrupt or you may have copied the InnoDB
        InnoDB: tablespace but not the InnoDB log files. See
        InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
        InnoDB: for more information.
        170925 14:14:34  InnoDB: Assertion failure in thread 140499101235072 in file trx0rseg.c line 144
        InnoDB: Failing assertion: UT_LIST_GET_LEN(rseg->update_undo_list) == 0
        InnoDB: We intentionally generate a memory trap.
        InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
        InnoDB: If you get repeated assertion failures or crashes, even
        InnoDB: immediately after the mysqld startup, there may be
        InnoDB: corruption in the InnoDB tablespace. Please refer to
        InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
        InnoDB: about forcing recovery.
        08:44:34 UTC - mysqld got signal 6 ;
        This could be because you hit a bug. It is also possible that this binary
        or one of the libraries it was linked against is corrupt, improperly built,
        or misconfigured. This error can also be caused by malfunctioning hardware.
        We will try our best to scrape up some info that will hopefully help
        diagnose the problem, but since we have already crashed,
        something is definitely wrong and this may fail.
        key_buffer_size=16777216
        read_buffer_size=131072
        max_used_connections=0
        max_threads=500
        thread_count=0
        connection_count=0
        It is possible that mysqld could use up to
        key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1110145 K  bytes of memory
        Hope that's ok; if not, decrease some variables in the equation.
        Thread pointer: 0x0
        Attempting backtrace. You can use the following information to find out
        where mysqld died. If you see no messages after this, something went
        terribly wrong...
        stack_bottom = 0 thread_stack 0x30000
        /usr/sbin/mysqld(my_print_stacktrace+0x20)[0x7fc87f558400]
        /usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x7fc87f442a35]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fc87e1d3340]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7fc87d829bb9]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fc87d82cfc8]
        /usr/sbin/mysqld(+0x5a0e0f)[0x7fc87f608e0f]
        /usr/sbin/mysqld(+0x5a3d00)[0x7fc87f60bd00]
        /usr/sbin/mysqld(+0x590f2a)[0x7fc87f5f8f2a]
        /usr/sbin/mysqld(+0x55c036)[0x7fc87f5c4036]
        /usr/sbin/mysqld(_Z22ha_finalize_handlertonP13st_plugin_int+0x2b)[0x7fc87f4449bb]
        /usr/sbin/mysqld(+0x2ffa29)[0x7fc87f367a29]
        /usr/sbin/mysqld(+0x303a71)[0x7fc87f36ba71]
        /usr/sbin/mysqld(_Z15plugin_shutdownv+0x1cd)[0x7fc87f36cbed]
        /usr/sbin/mysqld(+0x289cf1)[0x7fc87f2f1cf1]
        /usr/sbin/mysqld(unireg_abort+0x1c3)[0x7fc87f2f27f3]
        /usr/sbin/mysqld(+0x28b2e8)[0x7fc87f2f32e8]
        /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x7fc87f2f751b]
        /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fc87d814ec5]
        /usr/sbin/mysqld(+0x286a78)[0x7fc87f2eea78]
        The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
        information that should help you find out what is causing the crash.

非常感谢您的帮助。

【问题讨论】:

【参考方案1】:

通过 /usr/bin/mysqld_safe & 启动数据库解决了

【讨论】:

这是什么意思?

以上是关于跪求极佳 MYSQL ibdata1文件丢失恢复工具 V9.2 绿色版软件百度云资源的主要内容,如果未能解决你的问题,请参考以下文章

ibdata1数据库如何恢复?

MySQL Innodb数据库误删ibdata1后MySQL数据库的恢复案例

仅从 ibdata1 文件中恢复数据

如何防止 MySQL 的 ibdata1 文件过大

如何防止 MySQL 的 ibdata1 文件过大

mysql数据库删除恢复 mysql drop数据库恢复 mysql drop表数据恢复