服务器数据恢复工程师对客户的服务器进行了初步检查,检查结果与客户描述及故障推测一致,服务器数据丢失的原因确实与异常断电有关,由于突然断电导致了启动信息丢失,另外客户服务器上的数据库也受到了破坏。想要恢复数据除了修复linux *** 作系统外还需要整理数据库碎片,修复数据库。
服务器数据恢复过程
服务器数据恢复工程师将客户服务器内的所有数据都按扇区备份到专用服务器上,将客户原始服务器状态复原,开始在专用服务器上进行数据分析和恢复。
linux系统修复后尝试启动服务器,服务器成功启动,但数据库无法启动,印证了之前工程师推测的数据库数据遭受破坏的推断。
数据恢复工程师继续分析数据库碎片数据,修改数据库错误数据,尝试修复并挂起数据库,最终成功恢复服务器内的数据库数据。交由客户对所有数据进行验证。
服务器数据恢复结论
经过客户对恢复数据进行验证,确认服务器及服务器上的数据库数据恢复完整、准确,本次数据恢复圆满成功。
服务器数据恢复后记
1、服务器故障后应避免随意拔插硬盘,避免硬盘盘序混乱。
2、避免对需要恢复数据的服务器进行写入和修改 *** 作。
3、求助专业服务器数据恢复公司的专业服务器数据恢复工程师,切忌在未备份的情况对服务器进行 *** 作。
例如 方法A支持事务
方法B不支持事务。
方法A调用方法B。
在方法A开始运行时,系统为它建立Transaction,方法A中对于数据库的处理 *** 作,会在该Transaction的控制之下。
这时,方法A调用方法B,方法A打开的 Transaction将挂起,方法B中任何数据库 *** 作,都不在该Transaction的管理之下。
当方法B返回,方法A继续运行,之前的Transaction回复,后面的数据库 *** 作继续在该Transaction的控制之下 提交或回滚。
最近遇到个比较有意思的问题,服务器宕掉后无法启动,想了好多办法,虽然解决了问题,数据没有丢失,但是没有按照自已的思路来,未免还是有些不甘。遇到问题不能慌,尤其是线上的环境,更不能紧张,心理素质对DBA来说也是一项挑战,可能你的手一抖就会导致多少人无法正常使用业务,如果你没有把握,请先把现场环境备份后再进行 *** 作,避免数据的二次损坏,下面壹基比小喻说一下大概的思路吧。
1检查是否有备份,如果备份存在,binlog存在,那么万事大吉,一切都有挽回的余地,慢慢来搞,只要你基础扎实,数据还原只是时间的问题。
2对于没有备份的,那处理这个问题就有些棘手了,还得一步一步的来。
在mycnf中[mysqld]下加上以下配置,采用强制恢复机制,看是否能够启动
[mysqld]
innodb_force_recovery=1
如果设置成1不能启动,可以逐渐的将数据增大到6,下文会详细说下1-6是什么意思,如果在1-6之间启动成功了,那么你运气还不错,这时候不要恢复业务,赶紧把数据用逻辑方式导出来,再启个新的实例把数据还原,有人会问,为什么mysql已经启动了,还要导出数据呢,原因在这:
当innodb_force_recovery被设置为大于0的时候 ,会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务,类似于windows系统下的安全模式。以下这段引于其它地方,具体地址不太清楚了,也可以从官方文档中找到。
innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表,那么你是比较安全的,只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张,因为数据库页被留在一个陈旧的状态,这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页,也让服务器运行着;试着让SELECT FROM tbl_name 跳过损坏的索引记录和页,这样有助于转储表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行,如果崩溃可能在净化 *** 作过程中发生,这将阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并 *** 作。如果你可能会导致一个崩溃。最好不要做这些 *** 作,不要计算表统计表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志:InnoDB把未完成的事务视为已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施,当innodb_force_recovery被设置为大于0的值时,InnoDB阻止用户执行INSERT, UPDATE或DELETE *** 作
即使强制恢复被使用,你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃,你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程,然后设置innodb_force_recovery为3,使得数据库被挂起而不需要回滚,然后舍弃导致失控回滚的表。
关于上面进行逻辑备份也可能会遇到问题,可能会备份失败,如果出错,建议先按库一个一个的备份,到哪个库出错后,再按照当前库的表一个一个备份,表出错根据表中主键一点一点备份,最终将大部分数据导出。如果你的数据不重要,可以容忍丢失,那么可以当我说的都是废话了。
3如果还是不可以启动,那么恭喜你,你遇到挑战了。
查看错误日志,看没有提示因为某个表的原因而导致启动不了,可以先把损坏的表的ibd文件先从数据目录mv走,再试着启动,在数据已经恢复后,我把当时错误的文件拿到本地,做了测试,把几个报错的ibd文件mv走后,数据库就可以正常启动了,但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢,曾想过用在线表空间传输,但是cfg文件却没有,这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复,关于这个工具的介绍与 *** 作,网上一大堆,我就不详细说明了。
以上就是关于服务器崩溃了进不去了怎么办全部的内容,包括:服务器崩溃了进不去了怎么办、请问事务挂起什么意思啊,出自下面,谢谢、网站宕机 服务器宕机 数据库宕机 宕机怎么办等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)