欢迎您的访问
专注于分享最有价值的互联网技术干货

即使删了全库,保证半小时恢复

几个T的资料等你来白嫖
双倍快乐
资源帮找!!!

近期一篇《就这样把根目录删了!!!》引发了广泛的讨论,《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈 “不小心把库删了”,如何快速恢复删掉的数据库,是今天要讨论的话题。

【高可用数据库架构】

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

20201125222931079.png
或者 主主架构:
20201125222931302.png

如果此时主库宕机,可以:

(1)一个从库顶上,重建集群

(2)流量迁移到另一个主库

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

但是,如果人为不小心执行了“删全库”操作,命令会同步给其他从(主)库,导致所有库上的数据全部丢失,这下怎么办呢?

可以问问自己,当这种情况发生的时候:

(1)能不能恢复数据?(应该没有公司不能)

(2)多久能够恢复数据?

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

【全量备份+增量备份】

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

20201125222931401.png
全量备份:定期(例如一个月)将 库文件全量备份

20201125222931638.png
增量备份:定期(例如每天)将 binlog增量备份

如果不小心误删了全库,可以这么恢复

(1)将最近一次全量备份的全库找到,拷贝回来(文件一般比较大),解压,应用

(2)将最近一次全量备份后,每一天的增量binlog找到,拷贝回来(文件较多),依次重放

(3)将最近一次增量备份后,到执行“删全库”之前的binlog找到,重放

恢复完毕。

为了保证方案的可靠性,建议定期进行恢复演练。

方案优点:能够找回数据

方案缺点:恢复时间非常长

有没有更优,更快恢复的方案呢?

【1小时延时从】

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

20201125222931722.png

什么是1小时延时从?

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

当“删全库”事故发生时,只需要:

(1)应用1小时延时从

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

快速恢复完毕。

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

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

【双份1小时延时从】

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

20201125222931792.png

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

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

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

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

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

【提高从库效率】

20201125222931880.png

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

(1)运营后台,产品后台

(2)BI进行数据同步

(3)研发进行数据抽样,调研

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

【总结】

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

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

(2)1小时延时从,双份1小时延时从能极大加速数据库恢复时间

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

赞(0) 打赏
版权归原创作者所有,任何形式转载请联系我们:大白菜博客 » 即使删了全库,保证半小时恢复

评论 抢沙发

2 + 2 =
  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏