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吧。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 黑客攻击基础设施建设之弱点扫描

• 分享到：