Question

我在Mac上工作时崩溃，硬盘损坏，无法修复，除非格式化，所以我从OS X恢复了我的数据库数据，我得到了所有的文件夹，现在我试图在Windows中恢复它电脑，而我修复Mac。我在这里尝试了几个帖子，说我只需要将所有文件复制到Windows上的新MySQL安装中的数据文件夹，我已经尝试使用frm文件和ind文件复制db文件夹，然后我复制了ibdata1文件并重新启动服务，但即便如此它也不起作用，我读到我必须复制ib_logfile0和ib_logfile1，所以我做了，但后来服务不想运行。当我恢复原始日志它的工作，但我只能看到mysqlworkbench中的表，但是我无法向它们查询，因为日志表示即使我能看到它们，表也不存在。

我在Windows 7和mysqlworkbench上使用mysql 5.6。

目前我有* .frm文件，* .ibd文件，ibdata1，ib_logfiles0和1，我从我的os x hdd救出，我将它们全部复制到windows mysql安装程序，所以mysql服务不会开始。当我尝试启动服务时，这是当前的日志。

 FROM CARLOSDESKTOP.err:

    2014-02-11 13:27:10  7108  Note  Plugin 'FEDERATED' is disabled.

          2014-02-11 13:27:10 3a8 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.

    2014-02-11 13:27:10  7108  Note  InnoDB: Using atomics to ref count buffer pool pages

    2014-02-11 13:27:10  7108  Note  InnoDB: The InnoDB memory heap is disabled

    2014-02-11 13:27:10  7108  Note  InnoDB: Mutexes and rw_locks use Windows interlocked functions

    2014-02-11 13:27:10  7108  Note  InnoDB: Compressed tables use zlib 1.2.3

    2014-02-11 13:27:10  7108  Note  InnoDB: Not using CPU crc32 instructions

    2014-02-11 13:27:10  7108  Note  InnoDB: Initializing buffer pool, size = 8.0M

    2014-02-11 13:27:10  7108  Note  InnoDB: Completed initialization of buffer pool

    2014-02-11 13:27:10  7108  Note  InnoDB: Highest supported file format is Barracuda.

2014-02-11 13:27:12 - Server start done.

2014-02-11 13:27:12 - Status check of service 'MySQL56' returned start pending

2014-02-11 13:47:27 - Status check of service 'MySQL56' returned stopped



FROM CARLOSDESKTOP.err:

    2014-02-11 13:27:12  7108  Note  InnoDB: The log sequence numbers 8610473 and 8610473 in ibdata files do not match the log sequence number 13883013 in the ib_logfiles!

    2014-02-11 13:27:12  7108  Note  InnoDB: Database was not shutdown normally!

    2014-02-11 13:27:12  7108  Note  InnoDB: Starting crash recovery.

    2014-02-11 13:27:12  7108  Note  InnoDB: Reading tablespace information from the .ibd files...

    2014-02-11 13:27:13  7108  ERROR  InnoDB: space header page consists of zero bytes in tablespace .\demo\record.ibd (table demo/record)

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size:1024 Pages to analyze:64

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size: 1024, Possible space_id count:0

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size:2048 Pages to analyze:64

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size: 2048, Possible space_id count:0

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size:4096 Pages to analyze:32

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size: 4096, Possible space_id count:0

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size:8192 Pages to analyze:16

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size: 8192, Possible space_id count:0

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size:16384 Pages to analyze:8

    2014-02-11 13:27:13  7108  Note  InnoDB: Page size: 16384, Possible space_id count:0

          InnoDB: Error: could not open single-table tablespace file .\demo\record.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.

2014-02-11 13:47:28 - Status check of service 'MySQL56' returned stopped

2014-02-11 13:47:28 - Starting server...

2014-02-11 13:48:29 - Status check of service 'MySQL56' returned start pending

2014-02-11 13:48:29 - Server start done.

2014-02-11 13:48:30 - Status check of service 'MySQL56' returned start pending

Answer 1

要从备份恢复数据库（我希望备份已正确完成），您至少需要这些文件

ibdata1（如果定义了ibdata2，ibdataX）
包含* .ibd和* .frm文件的数据库目录

如果在Workbench中看到表，则只复制.ibd和.frm文件。 ibdata1看起来是空的，因为这是InnoDB保存表字典的地方。

Answer 2

过程1

尝试安装相同版本的mysql，如果崩溃的mysql版本为5.6，请安装mysql 5.6。 brew install mysql@5.6
如果以下项目失败，请使用mariadb尝试相同的操作。（就我而言，通过mariadb，我取回了所有数据库）
在启动星号之前，必须停止mysql或mariadb。使用此命令 brew services stop mysql或brew services stop mariadb
ibdata1文件，并将其粘贴并替换到新安装的mysql文件夹的ibdata1（usr / local / var / mysql）或mamp / xampp mysql文件夹位置中。
ib_logfile0和ib_logfile1不需要先替换。如果上述过程不起作用，请从备份mysql文件夹复制此文件并替换。（就我而言，我没有更换）
现在从备份的mysql文件夹中复制1个数据库进行测试（例如：testdb），并将其粘贴到新安装的mysql文件夹中。在testdb中必须具有.frm和.ibd文件。
重新启动mysql / mariadb（brew服务启动mysql）或（brew服务启动mariadb）
登录MySQL-> mysql -u root -p
如果一切顺利，则mysql登录成功。
现在检查数据库，SHOW DATABASES；
使用testdb;
展示表；
SELECT * FROM testdbtable;
如果没有任何按摩，则按摩成功恢复；

过程2

如果它不起作用，则必须安装mysqlfrm（https://downloads.mysql.com/archives/utilities/）
查找数据库表架构。使用备份的mysql文件夹mysqlfrm --diagnostic /BACKUP/mysql/testdb > /RESTORE/testdb.sql
在记事本/ sublime中打开testdb.sql，您将看到所有数据库表模式，而不仅仅是表:(无论如何，请仔细执行以下步骤。
添加引擎= InnoDB默认字符集= utf8 ROW_FORMAT =动态;每个CREATE TABLE .... ENGINE = InnoDB的末尾，否则可能不会创建表。
创建新数据库“ newtestdb”并运行命令>> mysqldump -uroot -p --databases newtestdb> testdb.sql
它将创建所有数据库表，现在，如果在“ newtestdb”中进行检查，您将看到.frm和.ibd文件。
现在再次登录mysql >> mysql -u root -p
SHOW DATABASES; USE newtestdb;
为所有表一个一个运行此命令，ALTER TABLE tablename DISCARD TABLESPACE;如果您检查newtestbd .ibd文件将消失。
现在仅从备份数据库testdb文件夹中复制.ibd文件，并将其粘贴到newtestdb中。
现在运行ALTER TABLE表名IMPORT TABLESPACE;
希望现在您将取回数据。

从* .frm文件恢复MySQL InnoDb

2 个答案: