MySQL误删数据救命指南Ｆ尕保藏
|
起首看下MySQL误删数据排名最前的几种是： 1.误删文件 2.误删库、表 3.错误全表删除 / 更新 4.进级操纵失误 都来看看你掷中过几个，hoho。 简朴说下我亲手造的一个大事情吧。 那或许是一个春暖花开的季候，我的心田是感动汹涌的，由于已经布置了休假打算。在这前几天，已经把一个新项目标数据库情形都陈设好了，包罗自动化备份。 等我美美的出去玩的时辰，悲剧产生了，营业要求举办数据回滚，但发明备份文件不行用，缘故起因是 备份时指定的字符集和表字符集纷歧致。我勒个擦，原本该项目回收新的字符集，可是我没有当真搜查确认并修改备份剧本，功效导致备份失效。最后，由于这个事，当季度绩效功效被降档，boss也为此背锅～ 好吧，回到正题，先说几点我平常提防误操纵导致文件/数据丢失不成熟的提议： 1.欲删除文件时，将rm呼吁改成mv，可在体系层面将rm呼吁做个alias(或参考 Windows / Mac OSX做法，删除文件时先辈接纳站)。 删除数据库、表时，不要用drop呼吁，而是rename到一个专用归档库里; 2.删除表中数据时，不要直接用delete或truncate呼吁，尤其是truncate呼吁，今朝不支持事宜，无法回滚。 3.用delete呼吁删除数据时，该当先显式开启事宜，这样误操纵时，尚有机遇举办回滚。 4.要大批量删除数据时，可以将这些数据insert...select到一个新表，确认无误后再删除。可能反其道行之，把要保存的数据写到新表，然后将表重定名对掉。 5.执行重要呼吁之前，先筹备好相干呼吁，再三确认无误才之行，，对付新鸟而言，最好请你的boss坐你旁边镇场屡次，不然极有也许会牵连各人～ 以上几条，也是我本身履行的原则。总之，要时候保持对线上出产情形的敬畏之心。虽说此刻大部门操纵可以靠平台来完成了，但平台也不是全能的，不也产生过平台自己的缺陷造成数据丢失、代码回滚、陈设失误等事情嘛，我就不点名了。 做好备份，不管是物理备份照旧逻辑备份! 做好备份，不管是物理备份照旧逻辑备份! 做好备份，不管是物理备份照旧逻辑备份! 重要的工作说三遍都不嫌多。 说完提防法子，我们再说万一产生误操纵时，怎么以最快速率举办调停。 我们别离罗列几种常见的环境： 1.执行DROP DATABASE / DROP TABLE呼吁误删库表，假如可巧回收共享表空间模式的话，尚有规复的机遇。假如没有，请直接从备份文件规复吧。神马，你连备份文件都没有?那贫困退出DBA届吧，一个连备份都懒得做的人，不配成为DBA的。 2.接上，回收共享表空间模式下，误删后立即杀掉(kill -9)mysql相干历程(mysqld_safe、mysqld)，然后实行从ibdataX文件中规复数据。 3.误删除正在运行中的MySQL表ibd或ibdataX文件。请当即申请对该实例举办维护，虽然，不是指把实例封锁，而是把营业停息，可能把该实例从线上情形摘除，不再写入新数据，然后操作linux体系的proc文件特点，把该ibd文件从内存中拷出来，再举办规复，由于此时mysqld实例在内存中是保持打开该文件的，牢记这时不要把mysqld实例封锁了。 4.接上，把复制出来的ibdataX或ibd文件拷贝回datadir后，重启mysqld进入recovery模式，innodb_force_recovery 选项从 0 - 6 逐级测试，直至能备份出(整个实例或单表的)全部数据后，再重建实例(或单表)，规复数据。 5.未开启事宜模式下，执行delete误删数据。意识到后当即将mysqld(以及mysqld_safe)历程杀掉(kill -9)，不要任何踌躇，然后再用器材将表空间数据读取出来。由于执行delete删除后，现实数据并没被物理破除，只是先打上deleted-mark标签，后续再同一整理，因此尚偶然刻差。 5.执行truncate误清整表。假如没行使共享表空间模式的话，根基别想了，走备份规复+binlog吧。 6.执行不带where前提的update，可能update错数据。也别费劲了，走备份规复+binlog吧。 【编辑保举】
点赞 0 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
