手贱删了DB，如何快速恢复？（第24讲）

《架构师之路：架构设计中的100个知识点》

24.数据库高可用，安全性架构设计

数据库最基本的防灾怎么设计？

做主从架构：

或者主主架构：

加上探活与故障转移，能够防：

1. 数据库挂掉；

2. 机器挂掉；

画外音：keepalived+Virtual IP。

有什么潜在问题？

不能防止人员恶意或者无意误删数据：一个不加where条件的delete下去，SQL会立刻同步到从库，一瞬间主从的所有数据都会被删除。

如何防止数据删除？

常见的安全策略是：定期全量与增量的备份。

例如：

一周备份一次全量，一般是db文件。

每天备份一次增量，一般是binlog。

如果误删数据，可以：

1. 应用最近一次的全量备份db；

2. 重放最近一次全量备份之后每天的增量binlog；

3. 重放最近一次增量备份之后，到删除操作之前的当天binlog；

为了保证方案的可靠性，需要定期进行恢复演练。

这个方案，还存在什么不足吗？

方案没问题，但恢复时间较长。

全量备份db+增量备份的binlog，一般都压缩保存在专门的备份服务器上，数据恢复的过程：

1. scp到本地；

2. tar解压；

3. 应用db；

4. 重放binlog；

往往需要几个小时的时间。

还能如何优化，缩短恢复时间？

可以使用1小时延时从的架构方案，能大大缩短误删数据的恢复时间。

如上图所示，增加一个从库，这个从库不是实时与主库保持同步的，而是每隔1个小时同步一次主库，同步完之后立马断开1小时，这个从库会与主库保持1个小时的数据差距。

如果误删全库，只需要：

1. 应用1小时延时从；

2. 重放1小时延时从到删除操作之前当天的binlog；

这些binlog都在本地，且不用解压缩，恢复速度非常快。

这个方案，还存在什么不足吗？

极限情况下，在1小时延时从连上主库后，立刻发生了“误删数据”事故，则无法快速恢复。

还能如何优化，确保极限情况下方案的完备性？

可以使用【双份】1小时延时从。

如上图所示，使用两个1小时延时从，他们连主库同步数据的时间“岔开半小时”，以确保极限情况下，至少有一个1小时延时从可用。

这样数据库的资源太浪费了吧？

1小时延时从，可以对一些“允许延时”的业务提供读服务，例如：

（1）运营后台，产品后台查询；

（2）BI进行数据同步；

（3）RD进行数据抽样，调研；

以提高资源的利用率。

稍作总结

数据库防灾架构设计：

1. 防数据库与机器挂掉：主从or主主高可用；

2. 防数据误删：全量+增量备份架构；

3. 误删快速恢复：用1小时延时从架构；

4. 防小概率事件：双份1小时延时从架构；

5. 提高资源利用率：1小时延时从对“允许延时”的业务提供读服务；

知其然，知其所以然。

==全文完==

宝藏号，置顶标星，日更好文。