保证半小时恢复

最新推荐文章于 2023-04-25 16:55:20 发布

jerry-89

最新推荐文章于 2023-04-25 16:55:20 发布

阅读量249

点赞数

分类专栏：备份与恢复

本文链接：https://blog.csdn.net/eagle89/article/details/107382413

版权

备份与恢复专栏收录该内容

27 篇文章 1 订阅

订阅专栏

【1小时延时从】

使用1小时延时从库，可大大加速“删全库”恢复时间。

什么是1小时延时从？

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

当“删全库”事故发生时，只需要：

（1）应用1小时延时从

（2）将1小时延时从最近一次同步时间到，将执行“删全库”之前的binlog找到，重放

快速恢复完毕。

方案优点：能够快速找回数据

潜在不足：万一，万一，万一，1小时延时从正在连上主库进行同步的一小段时间内，发生了“删全库”事故，那怎么办咧？

【双份1小时延时从】

使用双份1小时延时从库，可以避免上述“万一，万一，万一”的事故发生。

什么是双份1小时延时从？

如图所示，两个1小时延时从，他们连主库同步数据的时间“岔开半小时”。

这样，即使一个延时从连上主库进行同步的一小段时间内，发生了“删全库”事故，依然有另一个延时从保有半小时之前的数据，可以实施快速恢复。

方案优点：没有万一，都能快速恢复数据

潜在不足：资源利用率有点低，为了保证数据的安全性，多了2台延时从，降低了从库利用率

【提高从库效率】

1小时延时从也不是完全没有用，对于一些“允许延时”的业务，可以使用1小时延时从，例如：

（1）运营后台，产品后台

（2）BI进行数据同步

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

但需要注意的是，毕竟这是从库，只能够提供“只读”服务哟。

【总结】

保证数据的安全性是DBA第一要务，需要进行：

（1）全量备份+增量备份，并定期进行恢复演练，但该方案恢复时间较久，对系统可用性影响大

（2）1小时延时从，双份1小时延时从能极大加速数据库恢复时间

（3）个人建议1小时延时从足够，后台只读服务可以连1小时延时从，提高资源利用率

高可用数据库架构

一般来说数据库集群会是主从架构：

或者主主架构：

如果此时主库宕机，可以：

一个从库顶上，重建集群
流量迁移到另一个主库

来保证数据的安全性与服务的可用性。

但是，如果人为不小心执行了“删全库”操作，命令会同步给其他从（主）库，导致所有库上的数据全部丢失，这下怎么办呢？
可以问问自己，当这种情况发生的时候：

能不能恢复数据？（应该没有公司不能）
多久能够恢复数据？
保证数据的安全性是DBA第一要务。

全量备份+增量备份

常见的数据库安全性策略是：全量备份+增量备份。

全量备份：定期（例如一个月）将库文件全量备份

增量备份：定期（例如每天）将binlog增量备份

如果不小心误删了全库，可以这么恢复：
（1）将最近一次全量备份的全库找到，拷贝回来（文件一般比较大），解压，应用
（2）将最近一次全量备份后，每一天的增量binlog找到，拷贝回来（文件较多），依次重放
（3）将最近一次增量备份后，到执行“删全库”之前的binlog找到，重放
恢复完毕。
为了保证方案的可靠性，建议定期进行恢复演练。

方案优点：能够找回数据
方案缺点：恢复时间非常长
有没有更优，更快恢复的方案呢？

1小时延时从

使用1小时延时从库，可大大加速“删全库”恢复时间。

什么是1小时延时从？
增加一个从库，这个从库不是实时与主库保持同步的，而是每隔1个小时同步一次主库，同步完之后立马断开1小时，这个从库会与主库保持1个小时的数据差距。
当“删全库”事故发生时，只需要：
（1）应用1小时延时从
（2）将1小时延时从最近一次同步时间到，将执行“删全库”之前的binlog找到，重放
快速恢复完毕。

方案优点：能够快速找回数据
潜在不足：万一，万一，万一，1小时延时从正在连上主库进行同步的一小段时间内，发生了“删全库”事故，那怎么办咧？

双份1小时延时从

使用双份1小时延时从库，可以避免上述“万一，万一，万一”的事故发生。

什么是双份1小时延时从？
如图所示，两个1小时延时从，他们连主库同步数据的时间“岔开半小时”。
这样，即使一个延时从连上主库进行同步的一小段时间内，发生了“删全库”事故，依然有另一个延时从保有半小时之前的数据，可以实施快速恢复。