一个技术人员如果经常在线操作DB，长期顺水推舟，难免会出错：update错误的数据，delete错误的数据，丢错数据，怎么办？找个DBA恢复数据，就算恢复不了也得有人背锅。画外音：我把数据都删了，怎么办，怎么办？零，哪种解决方案不能实现数据恢复？从“从库”恢复数据。一般来说，数据库集群是主从架构：如果手动执行“删除数据库”操作，该命令会同步到其他从数据库，导致所有数据库上的数据全部删除，无法恢复，所以这种解决方案是不可接受的。第一，如果DBA没有完成他们的作业，最常见的做法是什么？如果没有数据安全预案，应对“删库”最常见的操作就是跑路。公司最重要的资产被删除了，没有快闪族。二、如果DBA每天都做全量备份+增量备份，应该怎么办？DBA最常用的技能是：全量备份+增量备份。全量备份：定期（如一个月）对库文件进行全量备份。增量备份：定时（比如每天）增量备份binlog。如果不小心“删除了数据库”，可以这样恢复：(1)找到最新的全量备份的全量数据库，复制回来（文件通常比较大），解压，应用；(2)最新一次全量备份后，每天把增量binlog找出来，复制回来（文件比较多），依次重放；(3)最新一次增量备份后，找到“删除整个数据库”执行前的binlog，并重放；恢复完成。为保证方案的可靠性，需要定期进行演练。嘿，为什么我好像没听说过DBA会定期进行这种训练？很有可能只是理论上的解决方案。如果出了问题，只能在理论上恢复效果。这时候回到计划一，逃跑。全量备份+增量备份的恢复周期也很长，可能是天级别。画外音：传输数TB的数据需要很长时间。三、如果DBA做了“离库1小时延迟”，应该怎么办？什么是延迟1小时从库？如上图所示，添加一个从库。这个从库并没有和主库实时同步，而是每隔1小时和主库同步一次。同步完成后，会立即断线1小时。这个从库会和主库同步。保持1小时的数据间隔。当“删除整个数据库”事故发生时，如何利用“1小时延迟从数据库”快速恢复数据？(1)延迟1小时；(2)设置从最近同步时间到延迟1小时，在执行“删除整个数据库”前找到binlog，replay很快恢复。这种解决方案的优点是可以快速检索数据。潜在的缺点是，如果在“1小时延迟从库”连接主库同步时，短时间内发生“删库”事故，无法恢复。四、DBA做了“1小时延迟从库双副本”怎么办？什么是double1hourdelayslave？如上图所示，两个延迟1小时的从库，它们与主库同步数据的时间是“相隔半小时”。这样即使延迟slave连接主库同步时短时间内发生“删库”事故，仍然有另一个延迟slave保留了半小时前的数据，可以快速恢复.此解决方案的优点是可以快速恢复数据，而不会发生任何意外。潜在的缺点是资源利用率有点低。为了保证数据的安全，多加了两个延时从库，降低了从库的利用率。如何提高从库利用效率？对于一些“允许延迟”的业务，可以使用1小时的延迟，例如：（1）运营后台、产品后台；(2)BI用于数据同步；(3)数据抽样研究的研发；但要注意遗憾的是，毕竟这是一个从库，只能提供“只读”服务。5、综上所述，确保数据安全是DBA们的头等大事：（0）理论上可恢复+跑路；（1）全量备份+增量备份+定时演练；(2)数据库延迟1小时；(3)双倍1小时从库延迟+提高资源利用率；
