mysql>USE sakila
mysql>CREATE TABLE actor (
actor_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
first_name VARCHAR(45) NOT NULL,
last_name VARCHAR(45) NOT NULL,
last_update TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (actor_id),
KEY idx_actor_last_name (last_name)
)ENGINE=InnoDB DEFAULT CHARSET=utf8
ALTER TABLE {库名}.{表名} DISCARD TABLESPACE
例:
mysql>ALTER TABLE sakila.actor DISCARD TABLESPACE
cp /backup_directory/actor.ibd path/to/mysql-5.7/data/sakila/
ALTER TABLE {库名}.{表名} IMPORT TABLESPACESHOW WARNINGS
例:
mysql>ALTER TABLE sakila.actor IMPORT TABLESPACESHOW WARNINGS
Query OK, 0 rows affected, 1 warning (0.15 sec)
Warning | 1810 | InnoDB: IO Read error: (2, No such file or directory)
Error opening './sakila/actor.cfg', will attempt to import
without schema verification
mysql>SELECT COUNT(*) FROM sakila.actor
+----------+
| count(*) |
+----------+
| 200 |
+----------+
在解决的过程中,以下几种尝试:1.如果开启了日志,直接mysqlbinlog 使用日志恢复即可。2.如果不是删除了一个表的部分数据,而是删除整个表,那么可以在删除后马上用磁盘数据恢复软件尝试恢复。(因为删除表后会有文件被删除,而删除表的部分数据,文件还是存在)3.找数据恢复的公司,使用工具分析ibdata1(分析过程参考一页一页查看有没有历史记录存在,使用ibdata1恢复数据,应该是在了解数据表结构的前提下,数据库除ibdata1外其他数据受损不能正常使用数据库时尝试,而不是删了表数据后恢复什么的。(事实上,这个文件是存储现有表数据的,其实也可以设置成每个表一个文件。)4.mysql下有ib_logfile0和ib_logfile1两个文件,其实这两个文件里,记录了Mysql的一些事物日志,用于事务的前滚后滚,是Mysql自身使用的,这个文件用文本工具打开后,有很多乱码,但却可以查找到被删除的少量数据的insert记录,极少数的乱码通过前后语句找出了原文,最终通过事物日志恢复了删除的文件。注:用事物日志恢复,需要几个前提。1:知道被删除数据的大概位置,不要这边查找,那边又不断有新数据插入。2:因为有很多乱码,适用于查找少量数据,而不是用作大量数据的恢复,浪费体力。3:如果二进制日志没开,没有备份,那么只能用这种方法恢复了。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)