mysql服务器硬盘损坏后的数据恢复

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 摘要:      在实际工作中遇到了mysql服务器硬盘挂掉的情况,并且无slave无备份。此时就只能去恢复硬盘的数据了。本文根据一次实战操作整理,分别用4种办法尝试修复数据。

摘要:

     在实际工作中遇到了mysql服务器硬盘挂掉的情况,并且无slave无备份。此时就只能去恢复硬盘的数据了。本文根据一次实战操作整理,分别用4种办法尝试修复数据。我们首先拿到了坏硬盘上的文件,在新服务器上安装同样版本的mysql准备恢复。

普通恢复:

此方式是把mysql的数据目录与my.cnf文件拷贝到新数据库目录,正常启动数据库。如果数据目录没有损坏,正常启动后应能正常读写数据,error日志无报错。
但是我们恢复时报了大量的错误,由此可见ibdata文件或redo日志已经被损坏,继续使用其他方式恢复。

附部分error信息:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: space id in fsp header 3221244024, but in the page header 268454008
InnoDB: Error: tablespace id 4294967295 in file .\game\area_element_table.ibd is not sensible
InnoDB: Cannot continue operation.
InnoDB: You can try to recover the database with the my.cnf
InnoDB: option:
InnoDB: innodb_force_recovery=6

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.

innodb_force_recovery方式:

我们根据上面的error日志提供的信息,在my.cnf的[mysqld]里面加入参数innodb_force_recovery,使用1-6级逐步尝试恢复。参考链接:http://who0168.blog.51cto.com/253401/551068
这种方式对于常规的数据库崩溃或服务器崩溃是奏效的,可以绕过损坏的redo log。但我们实际操作时将级别提升至6仍无法启动,说明ibdata可能有损坏。继续下面的修复方式。

附部分error信息:

error日志和上面的差不多,这里仅贴出有差异的部分
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.

InnoDB: Error: trying to access page number 16766859 in space 0,
InnoDB: space name .\ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.

修复ibdata方式:

独立表空间模式下,ibdata的作用是存放内部数据字典和重作日志。 在ibdata文件丢失或损坏的情况下,利用frm和ibd文件,以及数据库的表结构,也可以尝试恢复数据。

1、DISCARD、IMPORT TABLESPACE方式:

    注:此方式未修复成功,仅供参考
   1)新建数据库,创建需要恢复的数据库的表结构。
   2)service mysqld stop,将需要恢复的frm文件覆盖刚刚新建的frm,并设置权限为mysql。service mysqld start,启动时加上参数innodb_force_recovery=6。
   3)ALTER TABLE xx DISCARD TABLESPACE; 复制ibd文件到数据目录。 service mysqld stop
   4)service mysqld start,启动时加上参数innodb_force_recovery=6。再ALTER TABLE xx IMPORT TABLESPACE;

2、修改ibd文件方式:

    注:此方式亲测可用
    1)新建数据库,创建需要恢复的数据库的表结构。
   2)
使用vim打开此表的ibd文件,16进制查看
        [root@localhost test]# vim -b tmp.ibd 
         :%!xxd 
        
    3)使用vim打开要恢复的ibd文件,16进制查看
        

     4)修改要恢复的ibd文件,将红方框中的值修改的和刚刚创建的新表的ibd文件一致。看到后面0000没,我们只需要修改文件头就可以了。00000c0以后的不用修改。
        [root@localhost test]# vim -b tmp.ibd 
         :%!xxd -r     #一定要先执行这一步
        :wq
     5)拿需要恢复的ibd文件覆盖刚刚创建的新表的ibd文件。修改文件权限为mysql用户。
     6)重启mysql,重启时加上参数innodb_force_recovery = 6。
    7)执行select操作,读取正常,但无法执行更新操作。将数据dump出来,重建表。找回数据成功。

mysqlbinlog方式:    

      在沟通的过程中我们了解到,在此前他们对数据库进行过一次清空操作。如果能找到当时清空数据库的时间点,利用mysqlbinlog进行一次日志回放,也是可行的。
     实际操作过程中对方无法提供清空数据库的准确时间点,回放binlog时错误不断,数据的准确性无法保证,最终作罢。
     此方式的适用场景:
     1)有此前的数据库备份及备份后的binlog
     2)能查到清空数据库的时间点
     

参考资料:

1.http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
2.http://who0168.blog.51cto.com/253401/551068
3.Mysql ibdata 丢失或损坏如何通过frm&ibd 恢复数据 http://www.lanceyan.com/tech/mysql/lost-ibdata-recover-data.html
4.MySQL:如何从ibd文件中恢复数据  http://www.dedecms.com/knowledge/data-base/mysql/2012/0819/7558.html



相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
存储 数据挖掘 索引
服务器数据恢复—LeftHand存储结构和P4500存储数据恢复案例
LeftHand存储支持RAID5、RAID6、RAID10磁盘阵列,同时还支持卷快照,卷动态扩容等。下面简单聊一下LeftHand存储的结构和一个LeftHand p4500存储中磁盘阵列数据恢复案例。
服务器数据恢复—LeftHand存储结构和P4500存储数据恢复案例
|
2月前
|
存储 运维 Oracle
服务器数据恢复—光纤共享存储互斥出现问题的数据恢复案例
两台SOLARIS系统(SPARC平台)的服务器通过光纤交换机共享同一个存储作为CLUSTER使用。正常情况下只有A服务器工作。如果A服务器发生故障宕机,可将A服务器关机,开启B服务器接管。但由于配置不当导致共享存储互斥出现问题。 管理员进行运维检查时发现B服务器连接了一块未知磁盘。由于B服务器并未启用,处于闲置状态,所以管理员也将这块磁盘当作闲置的,于是在B服务器上将磁盘的某个分区做了newfs。没想到这块磁盘就是那个共享存储,执行操作没有多长时间A服务器就开始报警并宕机。
|
15天前
|
运维 数据挖掘 开发工具
服务器数据恢复—硬盘离线导致raid5阵列热备盘上线失败的数据恢复案例
服务器磁盘阵列数据恢复环境: 服务器中有两组分别由4块SAS硬盘组建的raid5磁盘阵列,两组raid5阵列划分LUN,组成LVM结构,格式化为EXT3文件系统。 服务器磁盘阵列故障: 服务器中一组raid5阵列中有一块硬盘离线,热备盘自动上线替换离线硬盘。热备盘上线同步数据过程中又有一块硬盘离线,热备盘同步失败,该组raid5阵列崩溃,LVM结构变得不完整,文件系统无法使用。 硬件工程师对两块离线硬盘进行硬件故障检测,发现先离线硬盘无法识别,初步判断该硬盘存在硬件故障,需要进行开盘修复。后离线硬盘可以正常识别。
服务器数据恢复—硬盘离线导致raid5阵列热备盘上线失败的数据恢复案例
|
5天前
|
存储 数据挖掘 数据库
服务器数据恢复—raid磁盘故障导致数据库数据损坏的数据恢复案例
存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区,数据库存放在D分区,备份存放在E分区。 RAID中一块硬盘的指示灯亮红色,D分区无法识别;E分区可识别,但是拷贝文件报错。管理员重启服务器,导致离线的硬盘上线开始同步数据,同步还没有完成就直接强制关机了,之后就没有动过服务器。
|
23天前
|
SQL 数据挖掘 数据库
服务器数据恢复—意外断电导致XenServer虚拟机不可用的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由4块STAT硬盘通过RAID卡组建的RAID10阵列,上层是XenServer虚拟化平台,虚拟机安装Windows Server操作系统,作为Web服务器使用。 服务器故障: 因机房异常断电导致服务器中一台VPS(Xen Server虚拟机)不可用,虚拟磁盘文件丢失。
服务器数据恢复—意外断电导致XenServer虚拟机不可用的数据恢复案例
|
1月前
|
存储 关系型数据库 MySQL
使用Docker快速部署Mysql服务器
本文介绍了如何使用Docker快速部署MySQL服务器,包括下载官方MySQL镜像、启动容器、设置密码、连接MySQL服务器以及注意事项。
141 18
|
22天前
|
存储 数据挖掘 Linux
服务器数据恢复—Linux操作系统网站服务器数据恢复案例
服务器数据恢复环境: 一台linux操作系统服务器上跑了几十个网站,服务器上只有一块SATA硬盘。 服务器故障: 服务器突然宕机,尝试再次启动失败。将硬盘拆下检测,发现存在坏扇区
|
28天前
|
存储 安全 算法
服务器数据恢复—Raid磁盘阵列的安全性分析及常见故障
出于尽可能避免数据灾难的设计初衷,RAID解决了3个问题:容量问题、IO性能问题、存储安全(冗余)问题。从数据恢复的角度讨论RAID的存储安全问题。 常见的起到存储安全作用的RAID方案有RAID1、RAID5及其变形。基本设计思路是相似的:当部分数据异常时,可通过特定算法将数据还原出来。以RAID5为例:如果要记录两个数字,可以通过再多记录这两个数字的和来达到记录冗余性的目的。例如记录3和5,同时再记录这2个数字的和8。在不记得到底是几和5的情况下,只需要用8-5就可以算出这个丢失的数字了,其余情况依此类推。
|
6天前
|
存储 Oracle 关系型数据库
服务器数据恢复—存储硬盘故障导致映射到服务器上的卷挂载不上的数据恢复案例
一台存储上有一组由16块FC硬盘组建了一组raid。存储前面板上的对应10号和13号硬盘的故障灯亮起,存储映射到redhat linux操作系统服务器上的卷挂载不上,业务中断。
|
7天前
|
存储 Unix 数据挖掘
服务器数据恢复—SAN环境下LUN Mapping出错导致文件系统共享冲突的数据恢复案例
服务器数据恢复环境: SAN环境下一台存储设备中有一组由6块硬盘组建的RAID6磁盘阵列,划分若干LUN,MAP到不同业务的SOLARIS操作系统服务器上。 服务器故障: 用户新增了一台服务器,将存储中的某个LUN映射到新增加的这台服务器上。这个映射的LUN其实之前已经MAP到其他SOLARIS操作系统的服务器上了。由于没有及时发现问题,新增加的这台服务器已经对此LUN做了初始化操作,磁盘报错,重启后发现卷无法挂载。
下一篇
无影云桌面