线上数据错删，错更，如何快速回滚和恢复？

常在河边走哪能不湿鞋。。

• update 错数据

• delete 错数据

• drop 错数据

咋办？找 dba 恢复数据，恢复不了咋办，重要数据的丢失，会导致难以估量的损失，这个锅你背定了。

有人会说，从 从库 恢复不就行了，一般数据库集群的主从架构如下：

如果说有人执行了 删库操作，命令会同步给其他从库，导致线上所有库的数据都会被删除，无法恢复，所以说这种方案行不通。

这就需要 DBA 指定一套应对这种场景的恢复方案，下面说一说我所知道的常见方案：

方案一：全量备份 + 增量备份

这是 DBA 最常用的技能：

上面是全量备份，dba 定期（如一个月）将库文件全量备份一份。

上面是增量备份，dba 定期（如每天）将 binlog 增量备份。

倘若不小心删库了，恢复方案如下：

• 1.将最近一次全量备份的全库找到，解压，应用；

• 2.将最近一次全量备份的数据应用后，再将这个全量备份后的每一天的增量数据 binlog 找到，依次重放，直到删库操作之前的 binlog；

至此，恢复完毕 (DBA 需要对这种方案做定期演练，而不是理论上的方案，直到真出了问题，才做)！

Note: 全量备份 + 增量备份的恢复周期也非常长，可能是天级别的。

方案二：一小时延时从库

什么是一小时延时从库？

如上图所示，增加一个延时从库，这个从库不需要实时与主库保持同步，而是每隔一个小时同步一次主库，这个从库会与主库保持一个小时的数据差。

这样，当删库操作发生时，我们可以利用这一个小时的时间差来快速回复数据：

将一个小时延时从库最近一次同步时间到，执行删库之前的 binlog 找到，重放。快速恢复数据！

这个方案的优点是，能够快速找回数据，潜在的风险是，万一延时从库正在连上主库进行数据同步的这段时间内，发生了删库操作，也是无法恢复。

方案三：双份一小时延时从库

什么是双份一小时延时从库？

如图所示，两个一小时延时从库，他们连主库同步的时间差开半个小时。这样，如果说执行删库操作时，有一个延时从库在执行同步数据的操作，也能保证另一个延时从库数据的安全性，从而保证另一个延时从库保有半个小时前的数据，从而实施快速恢复。

这个方案的有点是没有意外的情况发生，但是缺点是资源利用率较低。

如何提高从库的资源利用率？

为了提高资源利用率，我们对某些业务场景下，对数据实时性没有那么太高要求的，走延时从库，例如：

• 1.运营后台，产品后台

• 2.BI 进行数据统计，同步

• 3.研发进行数据抽样，调研等

总结：

保证数据的安全性是 DBA 第一要务：

1.全量备份 + 增量备份 + 定期演练；

2.一小时延时从库；

3.双份一小时延时从库 + 提高资源利用率