在想清楚解决方案、做好全部备份、逐个相关文件关系查验之前,尽量不要做任何文件的写入、覆盖操作。

记一段辛酸但好歹不用跳天台的数据库恢复笔记

能写一个自动备份脚本,为什么要偷几十秒的懒呢?

主要也是参考下面链接最终成功恢复。 这篇文章的步骤稍微有点多。有些是恢复不必要的,这里做一下自己的整理。

如何在删除ibdata1的情况下恢复

数据库宕机恢复数据或迁移数据,几个重要节点。

1 检查数据库目录配置是否正确

数据库目录配置错误时,MySQL是不能正常启动的,报错可能与此无关。 比如说,找不到 user_table这样的报错,都可能是目录配置错误。

2 拷贝每一个数据库数据文件夹内的文件到安全位置

在进行迁移,覆盖、写入等操作的时候,一定要提前把相关文件夹的内容做好备份。 譬如说,我在修改数据库目录的时候,点击了宝塔面板的迁移按钮,导致ibdata1文件被覆盖,以及随之而来的崩溃恢复之旅。 如果提前做好了备份,可能几秒钟就可以顺利恢复了。

3 检查ibdata1的最后更新日期,以及是否可用

MySQL在运行以及关闭时会更新ibdata1文件,我们通过ibdata1的最后更新时间可以判断这个文件大概是什么时候的。 如果是比较新的,一定要备份好,因为可能会在关键的时候救一命。

4 丢失ibdata1或 ibdata1文件损坏,与数据库数据文件不匹配时的数据恢复。

由于innoDB将表数据字典存储在ibdata1中,当ibdata1改变时,ID就无法对应上,所以就会找不到表

解决方案概括来说就是

CREATE TABLE table_name ...; # 这里的表格式 必须和之前的严格一致,否则会造成数据乱码 
ALTER TABLE table_name DISCARD TABLESPACE; # 去除表空间( 会删除 table_name.idb )
# 复制原数据 table_name.idb 到数据目录下  ( 这一步建议先停止MySQL服务器,复制完成再开启 )
ALTER TABLE table_name IMPORT TABLESPACE; # 导入表空间

# DISCARD TABLESPACE 相当于清空新表数据
# IMPORT TABLESPACE 相当于从文件导入数据

小技巧和经验

在没有有效ibdata1的时候,其实可以放弃一键恢复的想法了,这时候要做的就是在数据库正常建立数据库、数据表。

建立完数据表的时候,使用discard...命令删除表空间

这时候即可批量进行,也可以单个表进行,(不用再理会ibdata1文件了)

譬如说,批量恢复了20张表,其中有2个有乱码。 那么可以使用DROP命令删除这个表,(换一下字段格式)重新建立这个表,然后重复 DISCARD, 复制table.idb文件,IMPORT 命令,测试是否找到正确格式。

这里需要跳过MySQL输密码的步骤,所以需要在mysql设置里面 为root用户设置好密码,这样可以直接登录。

DROP TABLE item_unit;
CREATE TABLE IF NOT EXISTS item_unit (
    id INT(15) NOT NULL AUTO_INCREMENT COMMENT '序列ID' ,
    PRIMARY KEY (id) 
) ENGINE  InnoDB CHARSET utf8mb4 COLLATE utf8mb4_general_ci;
ALTER TABLE item_unit DISCARD TABLESPACE;

exit;

cp /mnt/mysql_backup/traper/item_unit.ibd /mnt/mysql/traper/item_unit.ibd

chown mysql /mnt/mysql/traper/item_unit.ibd

mysql;
use traper;

ALTER TABLE item_unit IMPORT TABLESPACE;


标签: mysql, 数据恢复, innoDB

添加新评论